Seagate Non-Proprietary
Seagate Non-proprietary
Seagate Secure®
TCG SSC Self-Encrypting Drives
Security Target
Version 1.0
April 4, 2018
Prepared for:
Seagate Technology, LLC
389 Disc Drive
Longmont, CO 80503
Prepared by:
Common Criteria Testing Laboratory
6841 Benjamin Franklin Drive, Columbia, Maryland 21046
Seagate Non-proprietary
2
Seagate Non-proprietary
TABLE OF CONTENTS
1. Security Target Introduction 5
1.1 Security Target, TOE and CC Identification 5
1.2 Conformance Claims 6
1.3 Conventions 7
1.3.1 Abbreviations and Acronyms 7
2. TOE Description 9
2.1 TOE Overview 9
2.2 TOE Architecture 9
2.2.1 Physical Boundaries 9
2.2.2 Logical Boundaries 15
2.2.2.1 Cryptographic Support 15
2.2.2.2 User Data Protection 15
2.2.2.3 Security Management 16
2.2.2.4 Protection of the TSF 16
2.3 TOE Documentation 16
3. Security Problem Definition 17
4. Security Objectives 18
4.1 Security Objectives for the Operational Environment 18
5. IT Security Requirements 19
5.1 Extended Requirements 19
5.2 TOE Security Functional Requirements 20
5.2.1 Cryptographic Support (FCS) 20
5.2.1.1 Cryptographic Key Generation (Symmetric Keys) (FCS_CKM.1(b)) 20
5.2.1.2 Cryptographic Key Generation (Symmetric Keys) (FCS_CKM.1(c)) 21
5.2.1.3 Cryptographic Key Destruction (Power Management) (FCS_CKM.4(a)) 21
5.2.1.4 Cryptographic Key Destruction (TOE-Controlled Hardware) (FCS_CKM.4(b)) 21
5.2.1.5 Cryptographic Key Destruction (General Hardware) (FCS_CKM.4(c)(1) HDD) 21
5.2.1.6 Cryptographic Key Destruction (General Hardware) (FCS_CKM.4(c)(2) SSD and Hybrid) 21
5.2.1.7 Cryptographic Key Destruction (Key Cryptographic Erase) (FCS_CKM.4(e)) 21
5.2.1.8 Cryptographic Key and Key Material Destruction (Destruction Timing) (FCS_CKM_EXT.4(a))
21
5.2.1.9 Cryptographic Key and Key Material Destruction (Power Management) (FCS_CKM_EXT.4(b))
22
5.2.1.10 5.2.1.10 Cryptographic Key Destruction Types (FCS_CKM_EXT.6) 22
5.2.1.11 Cryptographic Operation (Signature Verification) (FCS_COP.1(a)) 22
5.2.1.12 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(b)) 22
Seagate Non-proprietary
3
Seagate Non-proprietary
5.2.1.13 Cryptographic Operation (Message Authentication) (FCS_COP.1(c)) 22
5.2.1.14 Cryptographic Operation (Key Wrapping) (FCS_COP.1(d)) 22
5.2.1.15 Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(f)) 22
5.2.1.16 Cryptographic Key Derivation (FCS_KDF_EXT.1) 22
5.2.1.17 Key Chaining (Recipient) (FCS_KYC_EXT.2) 23
5.2.1.18 Random Bit Generation (FCS_RBG_EXT.1) 23
5.2.1.19 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation) (FCS_SNI_EXT.1)
23
5.2.1.20 Validation (for SATA) (FCS_VAL_EXT.1(a)) 23
5.2.1.21 Validation (for SAS) (FCS_VAL_EXT.1(b)) 24
5.2.2 User Data Protection (FDP) 24
5.2.2.1 Protection of Data on Disk (FDP_DSK_EXT.1) 24
5.2.3 Security Management (FMT) 24
5.2.3.1 Specification of Management Functions (FMT_SMF.1) 24
5.2.4 Protection of the TSF (FPT) 24
5.2.4.1 Firmware Access Control (FPT_FAC_EXT.1) 24
5.2.4.2 Failure with preservation of secure state (FPT_FUA_EXT.1) 24
5.2.4.3 Protection of Key and Key Material (FPT_KYP_EXT.1) 25
5.2.4.3 Timing of Power Saving States (FPT_PWR_EXT.1) 25
5.2.4.4 Power Saving States (FPT_PWR_EXT.2) 25
5.2.4.5 Rollback Protection (FPT_RBP_EXT.1) 25
5.2.4.6 TSF Testing (FPT_TST_EXT.1) 25
5.2.4.7 Trusted Update (FPT_TUD_EXT.1) 26
5.3 TOE Security Assurance Requirements 26
6. TOE Summary Specification 27
6.1 Overview of TOE Operations 27
6.2 Cryptographic Support 28
6.2.1 Cryptographic Key Generation (FCS_CKM.1(b), FCS_CKM.1(c)) 29
6.2.2 Cryptographic Key Destruction (FCS_CKM.4(a), FCS_CKM.4(b), FCS_CKM.4(c)(1) HDD,
FCS_CKM.4(c)(2) SSH and Hybrid FCS_CKM.4(e), FCS_CKM_EXT.4(a), FCS_CKM_EXT.4(b),
FCS_CKM_EXT.6) 29
6.2.3 Cryptographic Operation (FCS_COP.1(a), FCS_COP.1(b), FCS_COP.1(c), FCS_COP.1(d),
FCS_COP.1(f)) 30
6.2.4 Cryptographic Key Derivation (FCS_KDF_EXT.1) 31
6.2.5 Key Chaining (Recipient) (FCS_KYC_EXT.2) 31
6.2.6 Random Bit Generation (FCS_RBG_EXT.1) 31
6.2.7 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation) (FCS_SNI_EXT.1) 31
6.2.8 Validation (FCS_VAL_EXT.1(a), FCS_VAL_EXT.1(b)) 32
Seagate Non-proprietary
4
Seagate Non-proprietary
6.3 Security Management 33
6.3.1 Specification of Management Functions (FMT_SMF.1) 33
6.4 User Data Protection 34
6.4.1 Protection of Data on Disk (FDP_DSK_EXT.1) 34
6.5 Protection of the TSF 34
6.5.1 Firmware Access Control and Update Authentication (FPT_FAC_EXT.1, FPT_FUA_EXT.1) 35
6.5.2 Protection of Key and Key Material (FPT_KYP_EXT.1) 35
6.5.3 Power Saving States and Timing (FPT_PWR_EXT.1, FPT_PWR_EXT.2) 35
6.5.4 RollBack Protection (FPT_RBP_EXT.1) 36
6.5.5 TST Testing (FPT_TST_EXT.1) 36
6.5.6 Trusted Update (FPT_TUD_EXT.1) 37
7. Protection Profile Claims 37
8. Rationale 39
8.1 TOE Summary Specification Rationale 39
LIST OF TABLES
Table 1: TOE Models and Firmware Versions .........................................................................................................6
Table 2: TOE Hardware and Firmware..................................................................................................................14
Table 3: TOE Hardware and CAVs.........................................................................................................................15
Table 4: TOE Security Functional Components.....................................................................................................20
Table 5: Assurance Components.............................................................................................................................26
Table 6: Cryptographic Functions ..........................................................................................................................28
Table 7: Try Limits Summary..................................................................................................................................33
Table 8: SFR Protection Profile Sources .................................................................................................................38
Table 9: Security Functions vs. Requirements Mapping .......................................................................................40
Seagate Non-proprietary
5
Seagate Non-proprietary
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE comprises the Seagate Secure®
TCG Opal and Enterprise
SSC Self-Encrypting Drives provided by Seagate Technology, LLC.
The Security Target contains the following additional sections:
● TOE Description (Section 2)
● Security Problem Definition (Section 3)
● Security Objectives (Section 4)
● IT Security Requirements (Section 5)
● TOE Summary Specification (Section 6)
● Protection Profile Claims (Section 7)
● Rationale (Section 8).
1.1 Security Target, TOE and CC Identification
ST Title – Seagate Secure®
TCG SSC Self-Encrypting Drives Security Target
ST Version – Version 0.9
ST Date – March 7, 2018
TOE Identification –
● Seagate Secure®
TCG Opal SSC Self-Encrypting Drive Series
● Seagate Secure®
TCG Enterprise SSC Self-Encrypting Drive Series
The specific TOE products and models include:
Product Name Model # Standard Firmware
Nytro 3730 SSD, 7mm, SAS Interface XS1600ME10023
XS800ME10023
XS400ME10023
Enterprise SSC 7539
Nytro 3530 SSD, 7mm, SAS Interface XS6400LE70023
XS1600LE10023
Enterprise SSC 7539
Nytro 3330 SSD, 7mm, SAS Interface XS1920SE10123 Enterprise SSC 7539
Nytro 3130 SSD, 7mm, SAS Interface XS3840TE10023 Enterprise SSC 7539
Nytro 3730 SSD, 15mm, SAS Interface XS3200ME70023 Enterprise SSC 7539
Nytro 3330 SSD, 15mm, SAS Interface XS15360SE70123 Enterprise SSC 7539
Seagate Non-proprietary
6
Seagate Non-proprietary
Product Name Model # Standard Firmware
Nytro 3130 SSD, 15mm, SAS Interface XS15360TE70023
XS7680TE70023
Enterprise SSC 7539
Exos 15E900, 2.5-Inch, 15K-RPM, SAS
Interface
ST900MP0166
ST600MP0156
Enterprise SSC CK10
Exos 15E900, 2.5-Inch, 15K-RPM, SAS
Interface
ST900MP0126
ST600MP0026
Enterprise SSC CKF1
FireCuda 2.5", SATA Interface (Hybrid) ST2000LX003
ST1000LX017
Opal SSC
ATA Security
SSM1
BarraCuda 2.5", SATA Interface ST2000LM010
ST1000LM038
ST500LM033
Opal SSC
ATA Security
SDM2
RSE3 (1D)
RDE3 (2D)
BarraCuda Pro 2.5", SATA Interface ST1000LM050
ST500LM035
Opal SSC
ATA Security
SDM2
RXE2
Exos 10E2400, 2.5-Inch, 10K-RPM, SAS
Interface
ST1200MM0069 Enterprise SSC CSF2
Exos 10E2400, 2.5-Inch, 10K-RPM, SAS
Interface
ST2400MM0149
ST1800MM0149
ST1200MM0149
Enterprise SSC CS10
Exos X10, 3.5-inch, 7K-RPM, SAS Interface ST10000NM0246 Enterprise SSC CT10
Exos X10, 3.5-inch, 7K-RPM, SAS Interface ST10000NM0236 Enterprise SSC CT12
Exos X10, 3.5-inch, 7K-RPM, SATA Interface ST10000NM0186 Enterprise SSC
ATA Security
CT14
Exos X10, 3.5-inch, 7K-RPM, SATA Interface ST10000NM0176 Enterprise SSC
ATA Security
CTF1
BarraCuda 3.5", SATA Interface ST2000DM011 Opal SSC
ATA Security
0001
Table 1: TOE Models and Firmware Versions
TOE Developer – Seagate Technology, LLC
Evaluation Sponsor – Seagate Technology, LLC
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4,
September 2012
1.2 Conformance Claims
This ST and the TOE it describes are conformant to the following CC specifications:
● collaborative Protection Profile for Full Drive Encryption – Encryption Engine Version 2.0, 9 September
2016, [CPPFDE_EE] and including the following optional and selection-based SFRs: FCS_CKM.1(b),
FCS_CKM.4(b), FCS_CKM.4(c)(1) HDD, FCS_CKM.4(c)(2) SSD and Hybrid, FCS_COP.1(a),
Seagate Non-proprietary
7
Seagate Non-proprietary
FCS_COP.1(b), FCS_COP.1(c), FCS_COP.1(d), FCS_COP.1(f), FCS_KDF_EXT.1, FCS_RBG_EXT.1,
FCS_CKM.4(e), FPT_FAC_EXT.1, FPT_FUA_EXT.1, and FPT_RBP_EXT.1. The following NIAP
Technical Decision applies to this PP:
● TD0233: FIT Technical Decision for Contents in Selected Long Message Test – Bit-oriented
Mode.
● Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 4, September 2012
● Part 2 Extended
● Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1 Revision 4, September 2012
● Part 3 Conformant
1.3 Conventions
The following conventions have been applied in this document:
● Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by appending the SFR with parentheses that contain a letter that is unique for
each iteration, e.g. (a), (b), (c) and a descriptive string for the SFR’s purpose, e.g. Server. For a
component that has already been iterated in the PP, and is iterated again (double iteration) in the
ST, the convention above is used for the PP iteration. An additional identifier is added after the
first identifying parentheses, containing additional parenthesis with a number that is unique for
each iteration, e.g. (1), (2), (3). The descriptive string goes after this set of parenthesis identifiers
and identifies the SFR’s purpose, e.g. Server. An example of a double iteration would be “(a) (1)
descriptive string”.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a
selection would be identified in italics and with embedded bold brackets (e.g., [[selected-
assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”). Note that
‘cases’ that are not applicable in a given SFR have simply been removed without any explicit
identification.
o The SFRs have all been drawn from the Protection Profile (PP): collaborative Protection Profile
for Full Drive Encryption – Encryption Engine Version 2.0, 9 September 2016, [CPPFDE_EE].
As a result, refinements and operations already performed in that PP are not identified (e.g.,
highlighted) here, rather the requirements have been copied from that PP and any residual
operations have been completed herein.
● Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.3.1 Abbreviations and Acronyms
AES Advanced Encryption Standard
Seagate Non-proprietary
8
Seagate Non-proprietary
ASIC Application-Specific Integrated Circuit
ATA Advanced Technology Attachment
BEV Border Encryption Value
CBC Cipher-Block Chaining
CC Common Criteria for Information Technology Security Evaluation
CLI Command Line Interface
CPP Collaborative Protection Profile
CPPFDE_EE Collaborative Protection Profile for Full Drive Encryption – Encryption Engine
DEK Data Encryption Key
DRBG Deterministic Random Bit Generator
DSS Digital Signature Standard
EE Encryption Engine
FDE Full Drive Encryption
FIPS Federal Information Processing Standard
FW Firmware
GCM Galois Counter Mode
HDD Hard Disk Drive
HMAC Hashed Message Authentication Code
ISE Instant Secure Erase
IT Information Technology
IV Initialization Vector
KEK Key Encryption Key
KMD Key Management Description
LBA Logical Block Addressing
MEK Media Encryption Key
PP Protection Profile
PSID Physical SID (public drive-unique value)
RBG Random Bit Generator
RNG Random Number Generator
ROM
RSA
Read Only Memory
Rivest, Shamir and Adleman (algorithm for public-key cryptography)
RTU
SAR
Root of Trust for Update
Security Assurance Requirement
SAS Serial Attached SCSI
SATA Serial ATA (Serial AT Attachment)
SCSI Small Computer Systems Interface
SED Self Encrypting Drive
SHA Secure Hash Algorithm
SID Security Identifier, (aka Drive Owner PIN)
SFR Security Functional Requirement
SPD Security Problem Definition
SPI Serial Peripheral Interface
SSC Security Subsystem Class
SSD Solid State Drive
ST Security Target
TCG Trusted Computer Group
TOE Target of Evaluation
TSF TOE Security Functions
XOR Exclusive or
XTS XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing
Seagate Non-proprietary
9
Seagate Non-proprietary
2. TOE Description
The TOE comprises the Seagate Secure®
TCG Opal and Enterprise SSC Self-Encrypting Drives (SEDs) provided
by Seagate Technology, LLC. The TOE model numbers and firmware versions are identified in Section 1.1.
The Seagate SEDs implement FIPS-approved and NIST-recommended cryptographic algorithms. The CAVP
certificates are identified in Section 6.2. The SEDs provide an Instant Secure Erase (ISE) function and full
protection of customer data-at-rest with self-encrypting drive locking. The Seagate Secure Drives are designed in
accordance with Trusted Computing Group (TCG) specifications.
The TOE provides the Full Disk Encryption (FDE) Encryption Engine functionality as defined by [CPPFDE_EE]. In
particular, the TOE provides data encryption, policy enforcement, and key management functions. The TOE
provides for the generation, update, protection, and destruction of the data encryption key (DEK) and other
intermediate keys under its control. Seagate terminology refers to the DEK as the Media Encryption Key (MEK).
2.1 TOE Overview
The Seagate Secure®
TCG Opal and Enterprise SSC SEDs communicate with a host system using the standard
protocol defined by the TCG, an organization sponsored and operated by companies in the computer, storage and
digital communications industry. The Storage Work Group of the Trusted Computing Group (TCG) defines Opal
and Enterprise storage Security Subsystem Classes (SSCes). The initial SEDs represent each SSC.
The Opal SSC supports Serial ATA (SATA). Enterprise SSC supports both SATA and SAS (Serial Attached SCSI).
The distinction between SATA and SAS generally is not significant. The drives behave the same independent of
interface type except for handling failed authentication attempts (see Section 6.2.8). While the physical form factor
of the drives differ, all models included in the TOE support the requirements defined in [CPPFDE_EE].
Seagate SEDs are passive devices that respond to commands but do not initiate actions. A SED does not support
remote or out-of-band management (although a host platform may have such capabilities that invoke SED
commands).
Each SED encrypts stored data in the out-of-the-box (default) configuration. Access to data is not restricted until a
user takes ownership via a TCG controller. After a user takes ownership, an authentication key is needed to unlock
the drive.
2.2 TOE Architecture
2.2.1 Physical Boundaries
The TOE model series includes SSC Opal and SSC Enterprise. The Opal SSC series supports SATA interfaces;
whereas the Enterprise SSC series supports both SATA and SAS. SEDs can be a hard-disk drive (HDD) or a solid-
state drive (SSD). All models are HDD except the Nytro models (SSD) and some of the 2.5" SATA models which
are hybrid models (see Table 2). Hybrid models provide both HDD and SSD; and behave like a SSD. All SEDs
meet the requirements set forth in this document and behave the same except regarding the following functions:
 Destruction of cryptographic keys (See Section 6.2.2)
 Random number generation (See Section 6.2.6)
 Validation of BEV (See Section 6.2.8)
The following table identifies each TOE model along with its capacity, firmware, firmware as identified by CAVP
certificate, ASIC and interface type.
Seagate Non-proprietary
10
Seagate Non-proprietary
Product Name Model # ASIC Standard Capacity
(GB)
Firmware Firmware implementations (
for each model) as identified
by CAVP
Nytro 3730 SSD,
7mm, SAS
Interface
XS1600ME10023
XS800ME10023
XS400ME10023
Balto Enterprise SSC 1600, 800,
400
7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Nytro 3530 SSD,
7mm, SAS
Interface
XS6400LE70023
XS1600LE10023
Balto Enterprise SSC 6400,
1600
7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Nytro 3330 SSD,
7mm, SAS
Interface
XS1920SE10123 Balto Enterprise SSC 1920 7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Nytro 3130 SSD,
7mm, SAS
Interface
XS3840TE10023 Balto Enterprise SSC 3840 7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Nytro 3730 SSD,
15mm, SAS
Interface
XS3200ME70023 Balto Enterprise SSC 3200 7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Seagate Non-proprietary
11
Seagate Non-proprietary
Product Name Model # ASIC Standard Capacity
(GB)
Firmware Firmware implementations (
for each model) as identified
by CAVP
Nytro 3330 SSD,
15mm, SAS
Interface
XS15360SE70123 Balto Enterprise SSC 15360 7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Nytro 3130 SSD,
15mm, SAS
Interface
XS15360TE70023
XS7680TE70023
Balto Enterprise SSC 15360,
7680
7539 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos 15E900, 2.5-
Inch, 15K-RPM,
SAS Interface
ST900MP0166
ST600MP0156
Myna Enterprise SSC 900, 600 CK10 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos 15E900, 2.5-
Inch, 15K-RPM,
SAS Interface
ST900MP0126
ST600MP0026
Myna Enterprise SSC 900, 600 CKF1 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
FireCuda 2.5",
SATA Interface
ST2000LX003
ST1000LX017
Cheops Opal SSC
ATA Security
2000,
1000
SSM1 ARMv7 GCM in Firmware 1.0
ARMv7 SHS in Firmware 3.0
Seagate Non-proprietary
12
Seagate Non-proprietary
Product Name Model # ASIC Standard Capacity
(GB)
Firmware Firmware implementations (
for each model) as identified
by CAVP
(Hybrid)
ARMv7 RSA in Firmware 5.0
800-90 DRBG 1.0 (Firmware)
ARMv7 HMAC in Firmware
4.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
BarraCuda 2.5",
SATA Interface
ST2000LM010
ST1000LM038
ST500LM033
Cheops Opal SSC
ATA Security
2000,
1000, 500
SDM2
RSE3 (1D)
RDE3 (2D)
ARMv7 GCM in Firmware 1.0
ARMv7 SHS in Firmware 3.0
ARMv7 RSA in Firmware 5.0
800-90 DRBG 1.0 (Firmware)
ARMv7 HMAC in Firmware
4.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
BarraCuda Pro
2.5", SATA
Interface
ST1000LM050
ST500LM035
Cheops Opal SSC
ATA Security
100, 500 SDM2
RXE2
ARMv7 GCM in Firmware 1.0
ARMv7 SHS in Firmware 3.0
ARMv7 RSA in Firmware 5.0
800-90 DRBG 1.0 (Firmware)
ARMv7 HMAC in Firmware
4.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos 10E2400, 2.5-
Inch, 10K-RPM SAS
Interface
ST1200MM0069 Myna Enterprise SSC 1200 CSF2 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos 10E2400, 2.5-
Inch, 10K-RPM SAS
ST2400MM0149
ST1800MM0149
Myna Enterprise SSC 2400,
1800,
CS10 ARMv7 GCM in Firmware 2.0
Seagate Non-proprietary
13
Seagate Non-proprietary
Product Name Model # ASIC Standard Capacity
(GB)
Firmware Firmware implementations (
for each model) as identified
by CAVP
Interface ST1200MM0149 1200 ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos X10, 3.5-inch,
7K-RPM, SAS
Interface
ST10000NM0246 Myna Enterprise SSC 10000 CT10 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos X10, 3.5-inch,
7K-RPM, SAS
Interface
ST10000NM0236 Myna Enterprise SSC 10000 CT12 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos X10, 3.5-inch,
7K-RPM, SAS
Interface
ST10000NM0186 Cheops Enterprise SSC
ATA Security
10000 CT14 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Exos X10, 3.5-inch,
7K-RPM, SAS
ST10000NM0176 Cheops Enterprise SSC 10000 CTF1 ARMv7 GCM in Firmware 2.0
ARMv7 SHS in Firmware 5.0
Seagate Non-proprietary
14
Seagate Non-proprietary
Product Name Model # ASIC Standard Capacity
(GB)
Firmware Firmware implementations (
for each model) as identified
by CAVP
Interface ATA Security ARMv7 RSA in Firmware 5.1
Hash_Based DRBG 2.0
(Firmware)
ARMv7 HMAC in Firmware
5.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
BarraCuda 3.5",
SATA Interface
ST2000DM011 Cheops Opal SSC
ATA Security
2000 0001
ARMv7 GCM in Firmware 1.0
ARMv7 SHS in Firmware 3.0
ARMv7 RSA in Firmware 5.0
800-90 DRBG 1.0 (Firmware)
ARMv7 HMAC in Firmware
4.0
ARMv7 AES Key Wrap in
Firmware
1.0
ARMv7 AES in Firmware 3.0
(Firmware)
Table 2: TOE Hardware and Firmware
Firmware
CAVP
XS1600ME10023
XS800ME10023
XS400ME10023
XS6400LE70023
XS1600LE10023
XS1920SE10123
XS3840TE10023
XS3200ME70023
XS15360SE70123
XS15360TE70023
XS7680TE70023
ST900MP0166
ST600MP0156
ST900MP0126
ST600MP0026
ST2000LX003
ST1000LX017
ST2000LM010
ST1000LM038
ST500LM033
ST1000LM050
ST500LM035
ST1200MM0069
ST2400MM0149
ST1800MM0149
ST1200MM0149
ST10000NM0246
ST10000NM0236
ST10000NM0186
ST10000NM0176 ST2000DM011
800-90 DRBG 1.0 (Firmware)
DRBG
#62
X X X
ARMv7 AES in Firmware 3.0 (Firmware)
AES
#1343
X X X X X X
ARMv7 AES Key Wrap in Firmware 1.0
(Firmware)
AES
#2947
X X X X X X
ARMv7 GCM in Firmware 1.0 (Firmware)
AES
#2804
X X X
ARMv7 GCM in Firmware 2.0 (Firmware)
AES
#2841
X X X
ARMv7 HMAC in Firmware 4.0 (Firmware)
HMAC
#1597
X X X
ARMv7 HMAC in Firmware 5.0 (Firmware)
HMAC
#2613
X X X
ARMv7 RSA in Firmware 5.0 (Firmware)
RSA
#1934
X X X
ARMv7 RSA in Firmware 5.1 (Firmware)
RSA
#2056
X X X
ARMv7 SHS in Firmware 3.0 (Firmware) SHS X X X
Seagate Non-proprietary
15
Seagate Non-proprietary
#1225
ARMv7 SHS in Firmware 5.0 (Firmware)
SHS
#3304
X X X
Hash_Based DRBG 2.0 (Firmware)
DRBG
#1146
X X X
Balto AES in Hardware
AES
#4843
X
Balto HMAC in Hardware
HMAC
#3243
X
Balto RSA in Hardware
RSA
#2662
X
Balto SHA in Hardware
SHS
#3984
X
Cheops AES in Hardware (cert #4279)
AES
#4279
X X X
Cheops AES in Hardware (cert #3758)
AES
#3758
X X X
Cheops HMAC in Hardware (cert #2815)
HMAC
#2815
X X X
Cheops HMAC in Hardware (cert #2460)
HMAC
#2460
X X X
Cheops RSA in Hardware
RSA
#1933
X X X
Cheops SHA in Hardware (cert #3515)
SHS
#3515
X X X
Cheops SHA in Hardware (cert #3128)
SHS
#3128
X X X
Myna AES in Hardware
AES
#3940
X X
Myna HMAC in Hardware
HMAC
#2565
X X
Myna RSA in Hardware
RSA
#2013
X X
Myna SHA in Hardware
SHS
#3250
X X
Table 3: TOE Hardware and CAVs
The TOE models and firmware all provide the same basic set of security functionality, differing mainly in capacity
and hardware as identified in Table 2.
A host system using the standard protocol defined by the Trusted Computing Group (TCG) is required in the
operational environment.
2.2.2 Logical Boundaries
This section summarizes the security functions provided by the Seagate Secure®
TCG Opal and Enterprise SSC
Self-Encrypting Drives:
● Cryptographic support
● User Data Protection
● Security Management
● Protection of the TSF
2.2.2.1 Cryptographic Support
The TOE includes NIST-validated cryptographic algorithms supporting cryptographic functions. The TOE provides
Key Wrapping, Key Derivation, and BEV Validation.
2.2.2.2 User Data Protection
The TOE performs Full Drive Encryption such that the drive contains no plaintext user data. The TOE performs user
data encryption by default in the out-of-the-box configuration using XTS-AES-256 mode.
Seagate Non-proprietary
16
Seagate Non-proprietary
2.2.2.3 Security Management
The TOE supports management functions for changing and erasing the DEK, for initiating the TOE firmware
updates, and for configuring the number of failed validation attempts required to trigger corrective action.
2.2.2.4 Protection of the TSF
The TOE provides trusted firmware update and access control functions; protects Key and Key Material; and
supports power saving states. The TOE runs a suite of self-tests during initial start-up (on power on), before the
function is first invoked.
2.3 TOE Documentation
There are numerous documents that provide information and guidance for the deployment of the TOE. In particular,
the following Common Criteria specific guides reference the security-related guidance material for all devices in the
evaluated configuration:
Guidance Documentation:
 Seagate Secure® TCG Enterprise and TCG Opal SSC Self-Encrypting Drive Common Criteria
Configuration Guide, Version 1.0 Dated: February 14, 2018
Seagate Non-proprietary
17
Seagate Non-proprietary
3. Security Problem Definition
This security target includes by reference the Security Problem Definition (composed of organizational policies,
threat statements, and assumptions) from the collaborative Protection Profile for Full Drive Encryption –
Encryption Engine Version 2.0, 9 September 2016, [CPPFDE_EE] excluding A.STRONG_CRYPTO. The
[CPPFDE_EE] offers additional information about the identified threats, but that has not been reproduced here and
the [CPPFDE_EE] should be consulted if there is interest in that material.
In general, the [CPPFDE_EE] has presented a Security Problem Definition appropriate for Full Drive Encryption -
Encryption Engines and as such is applicable to the Seagate Secure®
TCG Opal and Enterprise SSC Self-Encrypting
Drives.
Seagate Non-proprietary
18
Seagate Non-proprietary
4. Security Objectives
Like the Security Problem Definition, this security target includes by reference the Security Objectives from the
[CPPFDE_EE]. The [CPPFDE_EE] security objectives for the operational environment are reproduced below, since
these objectives characterize technical and procedural measures each consumer must implement in their operational
environment.
In general, the [CPPFDE_EE] has presented a Security Objectives statement appropriate for Full Drive Encryption -
Encryption Engines and as such is applicable to the Seagate Secure®
TCG Opal and Enterprise SSC Self-Encrypting
Drives.
4.1 Security Objectives for the Operational Environment
OE.TRUSTED_CHANNEL Communication among and between product components
(e.g., AA and EE) is sufficiently protected to prevent
information disclosure.
OE.INITIAL_DRIVE_STATE The OE provides a newly provisioned or initialized storage
device free of protected data in areas not targeted for
encryption.
OE.PASSPHRASE_STRENGTH An authorized administrator will be responsible for ensuring
that the passphrase authorization factor conforms to guidance
from the Enterprise using the TOE.
OE.POWER_DOWN Volatile memory is cleared after entering a Compliant power
saving state or turned off so memory remnant attacks are
infeasible.
OE.SINGLE_USE_ET External tokens that contain authorization factors will be used
for no other purpose than to store the external token
authorization factor.
OE.PHYSICAL The Operational Environment will provide a secure physical
computing space such that an adversary is not able to make
modifications to the environment or to the TOE itself.
OE.TRAINED_USERS Authorized users will be properly trained and follow all
guidance for securing the TOE and authorization factors.
Note:
All of the cryptographic functionality is implemented by the TOE and the TOE does not rely on its Operational
Environment to provide any cryptographic services. Therefore OE.STRONG_ENVIRONMENT_CRYPTO is not
included in the ST.
Seagate Non-proprietary
19
Seagate Non-proprietary
5. IT Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs)
that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation
effort.
The SFRs have all been drawn from the Protection Profile (PP): collaborative Protection Profile for Full Drive
Encryption – Encryption Engine Version 2.0, 9 September 2016, [CPPFDE_EE]. As a result, refinements and
operations already performed in that PP are not identified (e.g., highlighted) here, rather the requirements have been
copied from that PP and any residual operations have been completed herein. Of particular note, the [CPPFDE_EE]
made a number of refinements and completed some of the SFR operations defined in the CC and that PP should be
consulted to identify those changes if necessary.
The SARs are the set of SARs specified in [CPPFDE_EE] with the required selection made for ASE_TSS as
identified in Section 5.3.
5.1 Extended Requirements
All of the extended requirements in this ST have been drawn from the [CPPFDE_EE]. The [CPPFDE_EE] defines
the following extended SFRs and since they are not redefined in this ST, the [CPPFDE_EE] should be consulted for
more information in regard to those CC extensions.
● FCS_CKM_EXT.4(a): Cryptographic Key and Key Material Destruction (Destruction Timing)
● FCS_CKM_EXT.4(b): Cryptographic Key and Key Material Destruction (Power Management)
● FCS_CKM_EXT.6: Cryptographic Key Destruction Types
● FCS_KDF_EXT.1: Cryptographic Key Derivation
● FCS_KYC_EXT.2: Key Chaining (Recipient)
● FCS_RBG_EXT.1: Random Bit Generation
● FCS_SNI_EXT.1: Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)
● FCS_VAL_EXT.1(a): Validation of Cryptographic Elements (SATA)
● FCS_VAL_EXT.1(b): Validation of Cryptographic Elements (SAS)
● FDP_DSK_EXT.1: Protection of Data on Disk
● FPT_FAC_EXT.1: Firmware Access Control
● FPT_FUA_EXT.1: Firmware Update Authentication
● FPT_KYP_EXT.1: Key and Material Protection
● FPT_PWR_EXT.1: Power Saving States
● FPT_PWR_EXT.2: Timing of Power Saving States
● FPT_RBP_EXT.1: Rollback Protection
● FPT_TST_EXT.1: TSF Testing
● FPT_TUD_EXT.1: Trusted Update
Seagate Non-proprietary
20
Seagate Non-proprietary
5.2 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by the TOE.
Requirement Class Requirement Component
FCS: Cryptographic support FCS_CKM.1(b): Cryptographic Key Generation (Symmetric Keys)
FCS_CKM.1(c): Cryptographic Key Generation (Data Encryption Key)
FCS_CKM.4(a): Cryptographic Key Destruction (Power Management)
FCS_CKM.4(b): Cryptographic Key Destruction (TOE-Controlled Hardware)
FCS_CKM.4(c)(1) HDD: Cryptographic Key Destruction (General Hardware)
FCS_CKM.4(c)(2) SSD and Hybrid: Cryptographic Key Destruction (General
Hardware)
FCS_CKM.4(e): Cryptographic Key Destruction (Key Cryptographic Erase)
FCS_CKM_EXT.4(a): Cryptographic Key and Key Material Destruction
(Destruction Timing)
FCS_CKM_EXT.4(b): Cryptographic Key and Key Material Destruction (Power
Management)
FCS_CKM_EXT.6: Cryptographic Key Destruction Types
FCS_COP.1(a): Cryptographic Operation (Signature Verification)
FCS_COP.1(b): Cryptographic Operation (Hash Algorithm)
FCS_COP.1(c): Cryptographic Operation (Message Authentication)
FCS_COP.1(d): Cryptographic Operation (Key Wrapping)
FCS_COP.1(f): Cryptographic Operation (AES Data Encryption/Decryption)
FCS_KDF_EXT.1: Cryptographic Key Derivation
FCS_KYC_EXT.2: Key Chaining (Recipient)
FCS_RBG_EXT.1: Random Bit Generation
FCS_SNI_EXT.1: Cryptographic Operation (Salt, Nonce, and Initialization
Vector Generation)
FCS_VAL_EXT.1(a): Validation (SATA)
FCS_VAL_EXT.1(b): Validation (SAS)
FDP: User Data Protection FDP_DSK_EXT.1: Protection of Data on Disk
FMT: Security Management FMT_SMF.1: Specification of Management Functions
FPT: Protection of the TSF FPT_FAC_EXT.1: Firmware Access Control
FPT_FUA_EXT.1 Firmware Update Authentication
FPT_KYP_EXT.1: Protection of Key and Key Material
FPT_PWR_EXT.1: Power Saving States
FPT_PWR_EXT.2: Timing of Power Saving States
FPT_RBP_EXT.1: Rollback Protection
FPT_TST_EXT.1: TSF Testing
FPT_TUD_EXT.1: Trusted Update
Table 4: TOE Security Functional Components
5.2.1 Cryptographic Support (FCS)
5.2.1.1 Cryptographic Key Generation (Symmetric Keys) (FCS_CKM.1(b))
FCS_CKM.1.1(b) The TSF shall generate symmetric cryptographic keys using a Random Bit Generator as
specified in FCS_RBG_EXT.1 and specified cryptographic key sizes [256 bit] that meet
the following: [no standard].
Seagate Non-proprietary
21
Seagate Non-proprietary
5.2.1.2 Cryptographic Key Generation (Symmetric Keys) (FCS_CKM.1(c))
FCS_CKM.1.1(c) Refinement: The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation method [
● generate a DEK using the RBG as specified in FCS_RBG_EXT.1]
and specified cryptographic key sizes [256 bits].
5.2.1.3 Cryptographic Key Destruction (Power Management) (FCS_CKM.4(a))
FCS_CKM.4.1(a) The TSF shall [erase] cryptographic keys and key material from volatile memory when
transitioning to a Compliant power saving state as defined by FPT_PWR_EXT.1 that
meets the following: [a key destruction method specified in FCS_CKM_EXT.6].
5.2.1.4 Cryptographic Key Destruction (TOE-Controlled Hardware)
(FCS_CKM.4(b))
FCS_CKM.4.1(b) Refinement: The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [
 For volatile memory, the destruction shall be executed by a [
o single overwrite consisting of [
 zeroes,
 a new value of a key],
o removal of power to the memory]
] that meets the following: [no standard].
5.2.1.5 Cryptographic Key Destruction (General Hardware) (FCS_CKM.4(c)(1) HDD)
FCS_CKM.4.1(c)(1) Refinement: The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [
o For non-volatile memory the destruction shall be executed by a
[single] overwrite consisting of [
▪ a new value of a key of the same size]
]
] that meets the following: [no standard].
5.2.1.6 Cryptographic Key Destruction (General Hardware) (FCS_CKM.4(c)(2) SSD and Hybrid)
FCS_CKM.4.1(c)(2) Refinement: The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [
o For non-volatile memory the destruction shall be executed by a
[single] overwrite consisting of [
▪ a new value of a key of the same size,
▪ block erase]
] that meets the following: [no standard].
5.2.1.7 Cryptographic Key Destruction (Key Cryptographic Erase) (FCS_CKM.4(e))
FCS_CKM.4.1(e) The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method [by using the appropriate method to destroy all encryption keys
encrypting the key intended for destruction] that meets the following: [no standard].
5.2.1.8 Cryptographic Key and Key Material Destruction (Destruction Timing) (FCS_CKM_EXT.4(a))
FCS_CKM_EXT.4.1(a) The TSF shall destroy all keys and keying material when no longer needed.
Seagate Non-proprietary
22
Seagate Non-proprietary
5.2.1.9 Cryptographic Key and Key Material Destruction (Power Management) (FCS_CKM_EXT.4(b))
FCS_CKM_EXT.4.1(b) The TSF shall destroy all key material, BEV, and authentication factors stored in
plaintext when transitioning to a Compliant power saving state as defined by
FPT_PWR_EXT.1.
5.2.1.10 5.2.1.10 Cryptographic Key Destruction Types (FCS_CKM_EXT.6)
FCS_CKM_EXT.6.1 The TSF shall use [FCS_CKM.4(b), FCS_CKM.4(c)(1) HDD, FCS_CKM.4(c)(2) SSD
and Hybrid] key destruction methods.
5.2.1.11 Cryptographic Operation (Signature Verification) (FCS_COP.1(a))
FCS_COP.1.1(a) Refinement: The TSF shall perform [cryptographic signature services (verification)] in
accordance with a [
● RSA Digital Signature Algorithm with a key size (modulus)of 2048 bits or
greater,
]
that meet the following: [
● FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using
PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1-
v1_5; ISO/IEC 28 9796-2, Digital signature scheme 2 or Digital Signature
scheme 3, for RSA schemes
].
5.2.1.12 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(b))
FCS_COP.1.1(b) Refinement: The TSF shall perform [cryptographic hashing services] in accordance with
a specified cryptographic algorithm [SHA-256] that meet the following: [ISO/IEC 10118-
3:2004].
5.2.1.13 Cryptographic Operation (Message Authentication) (FCS_COP.1(c))
FCS_COP.1.1(c): Refinement: The TSF shall perform [message authentication] in accordance with a
specified cryptographic algorithm [HMAC-SHA-256] and cryptographic key sizes
[256 bit used in [HMAC]] that meet the following: [ISO/IEC 9797-2:2011, Section 7
“MAC Algorithm 2”].
5.2.1.14 Cryptographic Operation (Key Wrapping) (FCS_COP.1(d))
FCS_COP.1.1(d) Refinement: The TSF shall perform [key wrapping] in accordance with a specified
cryptographic algorithm [AES] in the following modes [KW, GCM] and the
cryptographic key size [256 bits] that meet the following: [AES as specified in ISO/IEC
18033-3, [NIST SP 800-38F, ISO/IEC 19772]].
5.2.1.15 Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(f))
FCS_COP.1.1(f): Refinement: The TSF shall perform [data encryption and decryption] in accordance with
a specified cryptographic algorithm [AES used in [GCM, XTS] mode] and cryptographic
key sizes [256 bits] that meet the following: [AES as specified in ISO /IEC 18033-3,
[GCM as specified in ISO/IEC 19772, XTS as specified in IEEE 1619]].
5.2.1.16 Cryptographic Key Derivation (FCS_KDF_EXT.1)
FCS_KDF_EXT.1.1 The TSF shall accept [imported submask] to derive an intermediate key, as defined
in [
● NIST SP 800-132],
Seagate Non-proprietary
23
Seagate Non-proprietary
using the keyed-hash functions specified in FCS_COP.1(c), such that the output
is at least of equivalent security strength (in number of bits) to the BEV.
5.2.1.17 Key Chaining (Recipient) (FCS_KYC_EXT.2)
FCS_KYC_EXT.2.1 The TSF shall accept a BEV of at least [256 bits] from [the AA].
FCS_KYC_EXT.2.2 The TSF shall maintain a chain of intermediary keys originating from the BEV to the
DEK using the following method(s): [
● key derivation as specified in FCS_KDF_EXT.1,
● key wrapping as specified in FCS_COP.1(d)]
]
while maintaining an effective strength of [256 bits] for symmetric keys and an effective
strength of [not applicable] for asymmetric keys.
5.2.1.18 Random Bit Generation (FCS_RBG_EXT.1)
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance
with [SP 800-90A] using [Hash_DRBG (any)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates
entropy from [
● [At least one] hardware-based noise source(s)]
with a minimum of [256 bits] of entropy at least equal to the greatest security strength,
according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash
Functions”, of the keys and hashes that it will generate.
5.2.1.19 Cryptographic Operation (Salt, Nonce, and Initialization Vector
Generation) (FCS_SNI_EXT.1)
FCS_SNI_EXT.1.1 The TSF shall use [use salts that are generated by a [DRBG as specified in
FCS_RBG_EXT.1].
FCS_SNI_EXT.1.2 The TSF shall use [no nonces].
FCS_SNI_EXT.1.3 The TSF shall create IVs in the following manner [
 XTS: No IV. Tweak values shall be non-negative integers, assigned
consecutively, and starting at an arbitrary non-negative integer;
 GCM: IV shall be non-repeating. The number of invocations of GCM
shall not exceed 2^32 for a given secret key].
5.2.1.20 Validation (for SATA) (FCS_VAL_EXT.1(a))
FCS_VAL_EXT.1.1(a) The TSF shall perform validation of the [BEV] using the following method(s): [
● decrypt a known value using the [intermediate key] as specified in
FCS_COP.1(f) and compare it against a stored known value]
FCS_VAL_EXT.1.2(a) The TSF shall require the validation of the [BEV] prior to [allowing access to TSF
data after exiting a Compliant power saving state].
FCS_VAL_EXT.1.3(a) The TSF shall [
● require power cycle/reset the TOE after [5 (see Table 7: Try Limits
Summary for details)] consecutive failed validation attempts.
Seagate Non-proprietary
24
Seagate Non-proprietary
5.2.1.21 Validation (for SAS) (FCS_VAL_EXT.1(b))
FCS_VAL_EXT.1.1(b) The TSF shall perform validation of the [BEV] using the following method(s): [
● decrypt a known value using the [intermediate key] as specified in
FCS_COP.1(f) and compare it against a stored known value]].
FCS_VAL_EXT.1.2(b) The TSF shall require the validation of the [BEV] prior to [allowing access to TSF
data after exiting a Compliant power saving state].
FCS_VAL_EXT.1.3(b) The TSF shall [
● block validation after [
o 5 retries for Common PSID credentials,
o 1024 retries for all other credentials.
(see Table 7: Try Limits Summary for details)]
of consecutive failed validation attempts
].
5.2.2 User Data Protection (FDP)
5.2.2.1 Protection of Data on Disk (FDP_DSK_EXT.1)
FDP_DSK_EXT.1.1 The TSF shall perform Full Drive Encryption in accordance with FCS_COP.1(f), such
that the drive contains no plaintext protected data.
FDP_DSK_EXT.1.2 The TSF shall encrypt all protected data without user intervention.
.
5.2.3 Security Management (FMT)
5.2.3.1 Specification of Management Functions (FMT_SMF.1)
FMT_SMF.1.1 Refinement: The TSF shall be capable of performing the following management functions: [
a) change the DEK, as specified in FCS_CKM.1, when re-provisioning or when
commanded,
b) erase the DEK, as specified in FCS_CKM.4(a),
c) initiate TOE firmware/software updates,
d) [configure a password for firmware update, configure the number of failed validation
attempts required to trigger corrective behavior (TCG Opal only)]
].
5.2.4 Protection of the TSF (FPT)
5.2.4.1 Firmware Access Control (FPT_FAC_EXT.1)
FPT_FAC_EXT.1.1 The TSF shall require [a password] before the firmware update proceeds.
5.2.4.2 Failure with preservation of secure state (FPT_FUA_EXT.1)
FPT_FUA_EXT.1.1 The TSF shall authenticate the source of the firmware update using the digital
signature algorithm specified in FCS_COP.1(a) using the RTU that contains [the
public key].
FPT_FUA_EXT.1.2 The TSF shall only allow installation of update if the digital signature has been
successfully verified as specified in FCS_COP.1(a).
Seagate Non-proprietary
25
Seagate Non-proprietary
FPT_FUA_EXT.1.3 The TSF shall only allow modification of the existing firmware after the successful
validation of the digital signature, using a mechanism as described in
FPT_TUD_EXT.1.2.
FPT_FUA_EXT.1.4 The TSF shall return an error code if any part of the firmware update process fails.
NOTE: RTU stands for Root of Trust for Update. The RTU in this case is the RSA public key in ROM
5.2.4.3 Protection of Key and Key Material (FPT_KYP_EXT.1)
FPT_KYP_EXT.1.1 The TSF shall [only store keys in non-volatile memory when wrapped, as specified
in FCS_COP.1(d)] unless the key meets any one of following criteria [The plaintext
key is [used to wrap a key as specified in FCS_COP.1(d)] that is already [wrapped
as specified in FCS_COP.1(d)]].
5.2.4.3 Timing of Power Saving States (FPT_PWR_EXT.1)
FPT_PWR_EXT.1.1 The TSF shall define the following Compliant power saving states: [D0, D3].
5.2.4.4 Power Saving States (FPT_PWR_EXT.2)
FPT_PWR_EXT.2.1 For each Compliant power saving state defined in FPT_PWR_EXT.1.1, the TSF
shall enter the Compliant power saving state when the following conditions occur:
user-initiated request, [system shutdown].
5.2.4.5 Rollback Protection (FPT_RBP_EXT.1)
FPT_RBP_EXT.1.1 The TSF shall verify that the new firmware package is not downgrading to a lower
security version number by [the internal block point mechanism].
FPT_RBP_EXT.1.2 The TSF shall generate and return an error code if the attempted firmware update
package is detected to be an invalid version.
5.2.4.6 TSF Testing (FPT_TST_EXT.1)
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power
on), at the conditions [before the function is first invoked]] to demonstrate the correct
operation of the TSF: [
 Power on Self-Tests:
 Hardware/ASIC AES: Encrypt and Decrypt KATs performed
 ASIC SHA: Digest KAT performed
 ASIC RSA: Verify KAT performed
 ASIC/Firmware HMAC: HMAC KAT performed
 Firmware AES: Encrypt and Decrypt KATs performed
 Firmware AES-GCM: Encrypt and Decrypt KATs performed
 Firmware RSA: Verify KAT performed
 Firmware 800-90 DRBG: DRBG KAT performed
 Firmware 800-132 PBKDF: PBKDF KAT performed
 Firmware Integrity Check: Signature Verification
 Firmware 800-38F Key Wrap: AES Key Wrap and Unwrap KATs
performed
 Firmware SHA-512: SHA-512 KAT performed
Seagate Non-proprietary
26
Seagate Non-proprietary
 Firmware FFC Diffie-Hellman Ephemeral Mode: Diffie-Hellman
KAT performed
 Firmware 800-135 KDF: KDF KAT performed, and
 Firmware AES-GCM (large block size): Encrypt and Decrypt KAT
performed
 Secure boot process
 Conditional tests:
 Firmware Load Check,
 Firmware 800-90 DRBG (CRNGT), and
 Firmware 800-90 DRBG Entropy (CRNGT)].
5.2.4.7 Trusted Update (FPT_TUD_EXT.1)
FPT_TUD_EXT.1.1 Refinement: The TSF shall provide [authorized users] the ability to query the current
version of the TOE [firmware].
FPT_TUD_EXT.1.2 Refinement: The TSF shall provide [authorized users] the ability to initiate updates
to TOE [firmware].
FPT_TUD_EXT.1.3 Refinement: The TSF shall verify updates to the TOE [firmware] using a
[authenticated firmware update mechanism as described in FPT_FUA_EXT.1] by
the manufacturer prior to installing those updates.
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are included by reference from the [CPPFDE_EE].
Requirement Class Requirement Component
ASE: Security Target ASE_CCL.1 Conformance Claims
ASE_ECD.1 Extended Components Definition
ASE_INT.1 ST Introduction
ASE_OBJ.1 Security Objectives for the Operational
Environment
ASE_REQ.1 Stated Security Requirements
ASE_SPD.1 Security Problem Definition
ASE_TSS.1 TOE Summary Specification
ADV: Development ADV_FSP.1 Basic functional specification
AGD: Guidance documents AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-cycle support ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM coverage
ATE: Tests ATE_IND.1 Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.1 Vulnerability survey
Table 5: Assurance Components
Consequently, the assurance activities specified in the [CPPFDE_EE] apply to the TOE evaluation. This ST
completes ASE_TSS.1.1C as follows:
Seagate Non-proprietary
27
Seagate Non-proprietary
ASE_TSS.1.1C Refinement: The TOE summary specification shall describe how the TOE meets each SFR,
including a proprietary Key Management Description (Appendix E of the [CPPFDE_EE]), and [Entropy Essay].
6. TOE Summary Specification
This chapter provides an overview of the TOE operations and describes the security functions:
● Cryptographic support
● User Data Protection
● Security Management
● Protection of the TSF
6.1 Overview of TOE Operations
Seagate SEDs (TOEs) use logical block addressing (LBA) to supports the user addressable non-volatile memory
space from (LBA0 to LBAMax). The TOE accepts SATA or SCSI commands to read or write user data in this
memory space. All user data in the user addressable non-volatile memory space is encrypted.
The TOEs support a non-volatile memory space that is only available to the TOE. It is referred to as the system area.
The system area is used to store keys, key material and CSPs. There is no logical or physical access to the system
area from outside of the TOE. The TOE accepts TCG commands to indirectly access or modify values in the system
area.
The TOEs also support a non-volatile memory space known as the TCG Data Store Tables. This area is not available
to the user but is accessible by an administrator through access-controlled TCG commands. Data in the TCG Data
Store tables is unencrypted. The TOE places no restriction on what data is stored in this area. Guidance provides a
warning that directs administrators not to store protected data in the tables.
Seagate SEDs support subdividing user storage. The storage ranges are called bands. Each band is secured with its
own authentication key and media encryption key. Each Band has its own key chain. The key chain begins with a
drive lock PIN-also known as a TCG PIN or authentication key. The drive lock PIN is used as an input to the
PBKDF function to generate an intermediate key. This intermediate key is used as an input to the AES GCM mode
function to generate an intermediate wrap key. This wrap key and a second plain text intermediate wrap key are used
as inputs in a two step AES KW function process to wrap the media encryption key (MEK).
The SEDs use PINs, passwords, and authentication keys as BEVs. This ST and Seagate uses these terms
interchangeably. The SED receives an authentication PIN from the host Authorization Acquisition (AA)
component, which could be whatever form or content the AA allows. The Seagate SEDs support authentication
PINs with length up to 32 bytes. Multiple PINs are required to control different functionality/resources within the
SED. All Seagate SEDs are shipped with a default set of PIN values that allow for open-access of the SED until new
PINs and locking settings are established.
The minimum pin length requirement for FIPS 140-2 is 4 bytes. Some CC environments may require the
use of full 32 byte PIN values. Seagate supports this and it can be enforced by setting the minimum PIN
length value ‘_MinPINLength’ to 32. The ‘_MinPINLength’ is not part of the TCG specification. There is
a ‘_MinPINLength’ value associated with each credential and they must be set independently.
For TCG Enterprise there are four authentication PINs needed in order to gain access to all of the drive’s operational
resources. These are 32-byte passwords which are identified by the credential names SID, PSID, BandMaster and
EraseMaster.
For TCG Opal there are five authentication PINs needed in order to gain access to all of the drive’s operational
resources. These are up to 32-byte passwords which are identified by the credential names SID, PSID, AdminSP
Admins, LockingSP Admins and Users. In addition, for ATA security mode, there are also the User and Master
passwords.
Seagate Non-proprietary
28
Seagate Non-proprietary
The following PINs are BEVs and provide access to encrypted user data: SATA Master Password, SATA User
Password, Band Masters 1-32, Erase Master, Locking SP Admin 1-4 Passwords, and User 1-16 Passwords. The
following PINs are management passwords, which provide access to SED management functions: SID, PSID and
Admin SP Admin 1-4 Passwords. Further details regarding these PINs are provided in Table 7.
PIN values are never stored directly on the SED. Instead an entered PIN value is passed to the process that unwraps
an intermediate key. If this process is successful then the entered PIN value is valid.
Names of PINs are tied to Enterprise and Opal SSC. This applies to all user PINs (admins and users (Opal) and
bandmaster (Enterprise)). PSIDs (Physical Security IDs) and SIDs (User's Security Identifier) are never going to be
a BEV. The PSID corresponds to the selection known unique value printed on device.
6.2 Cryptographic Support
The TOE includes NIST-validated cryptographic algorithms providing supporting cryptographic functions. The
following functions have been certified in accordance with the identified standards.
Functions Standards Certificates Security
Functional
Requirement
Cryptographic signature services
● RSA: 2048 bits RSASSA-PKCS1-v1_5 #2013, #2056,
#2662, #1933,
#1934
FCS_COP.1(a),
FPT_FUA_EXT.1,
FPT_TUD_EXT.1
Cryptographic hashing
● SHA-256 ISO/IEC 10118-3:2004 #3250, #3515,
#3304, #3984,
#3128, #1225
FCS_COP.1(b)
Message authentication
● HMAC-SHA-256: 256 bit used in
HMAC
ISO/IEC 9797-2:2011,
Section 7 “MAC Algorithm
2”
#2565, # 2815,
#2613, #1597,
#2460, #3243
FCS_COP.1(c)
Key Wrapping
● AES in KW mode: 256 bits NIST SP 800-38F #2947 FCS_COP.1(d)
● AES in GCM mode: 256 bits ISO/IEC 19772 #2841, #2804,
#4843
FCS_COP.1(d)
FCS_COP.1(f)
Encryption/Decryption
● AES prerequisite certificate for
Key Wrapping certs:#2947, 2841,
2804
FIPS Pub 197, Advanced
Encryption Standard
#1343 FCS_COP.1(f)
● AES in GCM Mode: 256 bits ISO/IEC 19772 #2841, #2804,
#4843
FCS_COP.1(f)
● AES in XTS Mode: 256 bits IEEE 1619 #4279, #3940,
#3758, #4843
FCS_COP.1(f)
Random-bit Generation
● Hash_DRBG (any): 256 bits
entropy
NIST SP 800-90A #1146, #62 FCS_RBG_EXT.1,
FCS_SNI_EXT.1
Table 6: Cryptographic Functions
Seagate Non-proprietary
29
Seagate Non-proprietary
6.2.1 Cryptographic Key Generation (FCS_CKM.1(b), FCS_CKM.1(c))
The TOE generates symmetric cryptographic keys using a Random Bit Generator (Hash_DRBG (any)). The
specified symmetric cryptographic key size is always 512 bits for media encryption keys (FCS_CKM.1(c)). The
specified cryptographic key size for all other symmetric keys is 256 bits (FCS_CKM_1(b)).
The TOE uses AES GCM mode to encrypt/decrypt intermediate key wrap keys. The AES GCM mode decrypt tag
value is also used to validate entered PIN values (FCS_VAL_EXT.1 Validation). The TOE uses AES XTS AES 256
mode for data encryption. AES XTS AES 256 mode requires 512 bit media encryption keys. The media encryption
keys are protected with a two step AES KW process with intermediate input keys.
6.2.2 Cryptographic Key Destruction (FCS_CKM.4(a), FCS_CKM.4(b),
FCS_CKM.4(c)(1) HDD, FCS_CKM.4(c)(2) SSH and Hybrid
FCS_CKM.4(e), FCS_CKM_EXT.4(a), FCS_CKM_EXT.4(b),
FCS_CKM_EXT.6)
The TSF destroys cryptographic keys in accordance with a specified cryptographic key destruction method by using
the appropriate method to destroy all encryption keys encrypting the key intended for destruction. (FCS_CKM.4(e))
There are two key destruction scenarios, one for volatile memory and one for non-volatile memory. For volatile
memory the TOE uses key destruction methods as specified in FCS_CKM.4.1(b).
For the volatile memory scenario, a SED will destroy keys when power is removed, the drive is locked, or the SED
generates a new key to erase a band. The TOE contains two types of volatile memory: static RAM and dynamic
RAM. In both cases the volatile memory is accessed using standard micro-controller memory interface controllers
and addressing schemes. The volatile memory is 8, 16 or 32 bit addressable. There is no built in redundancy for
volatile memory in the TOE. When the SEDs are powered off: all keys are destroyed. When the device is Locked
all keys are overwritten with zeros. When the SED generates a new key to erase a band, the existing key is
overwritten with a new value of a key. Unlocked band keys are stored in plaintext form for use by the FDE engine
as needed. All other plaintext keys are temporarily stored in volatile memory in DRAM on the stack for a short time
after being generated and during the operations (Take Ownership Function, Verify PIN Function) as described
below. The keys are removed immediately after they are used or when they are no longer needed, using a single
overwrite of zeroes. Keys are permanently stored by the firmware in the following manner. All keys are stored in
non-volatile memory are wrapped except for the second intermediate AES KW key. It is stored in non-volatile
memory in plaintext form.
The TOE destroys all key material, BEV, and authentication factors stored in plaintext when transitioning to a
Compliant power saving state. The TOE supports device full off and device full on states (or modes), D0 and D3
respectively. When power is removed from the drive, the device goes off and keys are removed.
(FCS_CKM_EXT.4(b))
For non-volatile memory the TOE uses key destruction methods as specified in FCS_CKM.4.1(c). The non-volatile
memory scenario further depends on whether the SED is a hard-disk drive (HDD) or a solid-state drive
(SSD)/hybrid. This is described in more detail below.
For the non-volatile memory key destruction on HDD scenario, the TOE always writes a new value of the key. All
keys and key material are stored in the system area on the media. If the TOE commands the HDD sequencer to write
a block in the system area, it can rely on the status bits returned by the sequencer to know that the data was written
correctly. The TOE does not have to read the block back to verify that it was written correctly.
For the non-volatile memory key destruction on solid state flash drives and hybrid drives scenario NOR flash is used
only for system data and there are separate areas for system data and user data in NAND flash. For NOR flash the
TOE performs a block erase (which writes all ones) followed by a write of a new value of a key to the wear-leveled
areas used for key storage. For NAND flash the TOE performs a write of a new value of a key to the system areas
used for key storage. The NAND flash system performs any erase or wear leveling functions as necessary. All keys
and key material are stored in the non-volatile memory. If the TOE commands the serial NOR flash controller to
Seagate Non-proprietary
30
Seagate Non-proprietary
write a page, it can rely on the status bits returned by the serial flash controller to know that the data was written
correctly. The same is true for NAND flash controller. The TOE does not have to read the page back to verify that
the page is written correctly.
TCG Enterprise SED drives use the BandMaster 1-32 or EraseMaster passwords to lock and unlock user bands.
TCG Opal SED drives use the Locking SP Admin 1-4 or User passwords 1-16 to lock and unlock user bands.
6.2.3 Cryptographic Operation (FCS_COP.1(a), FCS_COP.1(b),
FCS_COP.1(c), FCS_COP.1(d), FCS_COP.1(f))
The TOE performs RSA Digital Signature Algorithm verification with a key size (modulus) of 2048 bits or greater.
The function complies with FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 27
v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1-v1_5; ISO/IEC 28 9796-2, Digital signature
scheme 2 or Digital Signature scheme 3, for RSA schemes. Seagate uses RSASSA-PKCS1-v1_5. SEDs do not
generate RSA keys. RSA Digital Signature Algorithm verification is used to perform updates to the TOE firmware.
The TOE performs SHA-256 cryptographic hashing services that meet the following: ISO/IEC 10118-3:2004. The
hash function is used with HMAC-SHA-256 message authentication and Hash_DRBG(any) functions. The TOE
also uses the SHA-256 hash functions as part of the RSA signature verification function.
The TOE performs HMAC-SHA-256 message authentication using cryptographic key sizes 256 bit that meet the
following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. The block size is 64 bytes and the output MAC
length size is 32 bytes.
The TOE performs AES GCM mode encryption and decryption using cryptographic key size 256 bits that meet the
following: AES as specified in ISO/IEC 18033-3 and NIST SP 800-38F, ISO/IEC 19772 (see also Section 6.1.8
Validation).
The TOE performs AES KeyWrap per SP 800-38F. The inputs to the AES-256 KeyWrap function are a plaintext
media encryption key (payload) or an intermediate key, the integrity check value ICV and a plaintext intermediate
key. All values are passed on the stack in DRAM. The output of the AES-256 KeyWrap function is a wrapped key
or an intermediate key and an integrity check value. Both are returned on the stack in DRAM.
The TOE performs AES KeyUnwrap per SP 800-38F. The inputs to the AES-256 KeyUnwrap function are a
wrapped media encryption key (payload) or an intermediate key, the integrity check value ICV and a plaintext
intermediate key. All values are passed on the stack in DRAM. The output of the AES-256 KeyUnwrap function is a
plaintext key or an intermediate key-if the integrity check PASSES. The media encryption key is returned on the
stack in DRAM and then finally programmed into the FDE hardware as the XTS-AES-256 mode encryption key for
data encryption/decryption.
The TOE supports both secure FW download and a secure boot procedure. These require PKCS #1, v1.5 RSA
signed firmware (FW) packages. The modulus and key size is 2048 bits.
Firmware packages are signed using a secure server using the appropriate RSA private key.
Access to firmware download is controlled by the Firmware Download Port. The Firmware Download
Port is a non-standard TCG port that has been added by Seagate to control access to the firmware
Seagate Non-proprietary
31
Seagate Non-proprietary
download function and to prevent unauthorized firmware updates. All Seagate drives ship with the
Firmware Download port in the default unlocked state, which allows firmware updates. The Firmware
Download port is set to the locked state and set to lock on reset as part of FIPS/CC configuration.
For secure FW download, the TOE receives a signed FW update package from the host and stores it in DRAM. The
TOE then verifies the RSA signature of the FW update package using FW routines and the public key in ROM. If
the signature is verified to be correct then the new FW package is accepted and stored from DRAM into flash. If the
signature does not verify then the FW download is aborted with an error.
For the secure boot process, the TOE first loads the FW from flash into DRAM using FW routines in ROM. The
TOE then verifies the RSA signature of the FW in DRAM using FW routines and the public key in ROM. If the
signature is verified to be correct then the ROM FW code transfers control to the FW in DRAM. If the signature
does not verify then a fatal error is indicated by the TOE.
6.2.4 Cryptographic Key Derivation (FCS_KDF_EXT.1)
TOE SEDs obtain an Authentication PIN from a host Authorization Acquisition (AA) component, which could be
any form or content the AA allows. Seagate SEDs support Authentication PINs with length up to 256 bits.
The TOE accepts the imported submask (the Authentication PIN) to derive an intermediate key as defined in NIST
SP 800-132 and uses the keyed-hash function HMAC-SHA-256. The output is at least of equivalent security
strength (in number of bits) to the BEV.
6.2.5 Key Chaining (Recipient) (FCS_KYC_EXT.2)
The TOE accepts BEVs of at least 256 bits from the AA, maintaining a chain of intermediary keys originating from
the BEV to the DEK and using the following methods:
● key derivation as specified in FCS_KDF_EXT.1: The TOE derives an intermediate key with PBKDF and
Authentication PIN,
● key wrapping as specified in FCS_COP.1(d): The TOE Decrypts an intermediate key with AES GCM
mode. The TOE Unwraps the media encryption key with a two-step AES KW process.
● theTOE Decrypts disk data with XTS-AES-256 mode and MEK.
The TOE maintains an effective strength of 256 bits for symmetric keys.
6.2.6 Random Bit Generation (FCS_RBG_EXT.1)
The TOE performs all deterministic random bit generation services in accordance with NIST SP 800-90A using
Hash_DRBG (any) and SHA-256 cryptographic hashing services.
For HDD SEDs, the deterministic RBG is seeded by two hardware entropy sources that accumulate a minimum of
256 bits of entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1
“Security Strength Table for Hash Functions”, of the keys and hashes that it will generate. SSD and Hybrid SEDs
use one hardware entropy source to seed the RBG.
6.2.7 Cryptographic Operation (Salt, Nonce, and Initialization Vector
Generation) (FCS_SNI_EXT.1)
The TOE uses randomly generated 128 bit salt values as inputs to the Password Based Key Derivation (PBKDF)
function. There is a 128 bit salt value associated with each PIN value in the drive.
The tweak values used for XTS are non-negative integers, assigned consecutively, and starting at an arbitrary non-
negative integer. The TOE uses DRBG randomly generated 96 bit IV values as inputs to the AES GCM Key
Wrap/Unwrap function (FCS_COP.1(d)). There is a 96 bit IV value associated with each PIN value in the drive.
Seagate Non-proprietary
32
Seagate Non-proprietary
6.2.8 Validation (FCS_VAL_EXT.1(a), FCS_VAL_EXT.1(b))
PINs (BEVs) are used as authentication factors or authorization factors by the TOE. The PINs are not stored in the
TOE. Instead for each PIN (BEV), the PIN is validated by first calling the PBKDF function with the PIN and the
associated plaintext salt value as inputs. The output of the PBKDF function is the intermediate key associated with
that PIN. Next call the AES GCM Key decrypt function with the intermediate key, Additional Authenticated Data
(AD) and IV, TAG and Wrapped wrap key associated with that PIN. If the AES GCM function returns PASS then
the PIN is valid and authentication is successful else the PIN is invalid and authentication is unsuccessful. There are
many PINs that do not have an associated wrap keys in these cases a null wrap key is used. The complete list of
PINs (authorization factors), otherwise known as credentials is in Table 7 below.
The TOE requires the validation of the BEV prior to allowing access to TSF data after exiting a compliant power
saving state.
The TOE maintains a separate failure count for each PIN that keeps track of the number of failed authentication
attempts. The counter is reset to zero after a successful authentication. In some cases, the maximum allowed failure
count is settable and can be any value from 1to 1024. The failure counters either reset to zero on power cycle or to
be persistent across power cycles. The persistence settings are set in the factory and are not configurable. For SATA
credentials, the TOE requires a power cycle/reset the TOE after 5 of consecutive failed validation attempts. For all
other credentials, the TOE is required to block validation after a number of consecutive failed validation attempts.
The following table identifies the failure count maximum values, persistence and configuration options for each PIN
type.
Credential Name Credential Type Try Limit Try Limit Settable Persistent
SID ATA 5 retries NO NO
PSID ATA 5 retries NO NO
ATA Master Password (BEV) ATA 5 retries NO NO
ATA User Password (BEV) ATA 5 retries NO NO
SID TCG Enterprise (SAS) 1024 retries NO YES
SID TCG Enterprise (SATA) 5 retries NO NO
PSID TCG Enterprise 5 retries NO NO
Band Masters 1-32 (BEV) TCG Enterprise (SAS) 1024 retries NO YES
Seagate Non-proprietary
33
Seagate Non-proprietary
Band Masters 1-32 (BEV) TCG Enterprise (SATA) 5 retries NO NO
Erase Master (BEV) TCG Enterprise (SAS) 1024 retries NO YES
Erase Master (BEV) TCG Enterprise (SATA) 5 retries NO NO
SID TCG Opal 5 retries YES NO
PSID TCG Opal 5 retries NO NO
Locking SP Admin 1-4 Passwords
(BEV)
TCG Opal 5 retries YES NO
Admin SP Admin 1-4 Passwords
(BEV)
TCG Opal 5 retries YES NO
User 1-16 Passwords (BEV) TCG Opal 5 retries YES NO
Table 7: Try Limits Summary
6.3 Security Management
The TOE supports management functions for changing and erasing the DEK and for initiating the TOE firmware
updates.
6.3.1 Specification of Management Functions (FMT_SMF.1)
The TOE is capable of performing the following management functions:
a) change the DEK, as specified in FCS_CKM.1, when re-provisioning or when commanded
b) erase the DEK, as specified in FCS_CKM.4(a)
c) initiate TOE firmware/software update
d) configure a password for firmware update
e) configure the number of failed validation attempts required to trigger corrective behavior.
The TOE changes a DEK when re-provisioning or when commanded. The Seagate SEDs generate each MEK (the
DEK) on the drive by using the drive’s SP 800-90A Hash Based DRBG (256 bits).
MEK destruction is described in Section 6.2.2: Cryptographic Key Destruction.
Firmware updates are initiated using either the ATA Download Micro Code command (for SATA); or the Write
Buffer command (for SAS (SCSI)).
To perform a firmware download, an administrator performs the following steps:
Seagate Non-proprietary
34
Seagate Non-proprietary
1) Unlock firmware download port.
2) Obtain a genuine Seagate Secure firmware update package from:
https://www.seagate.com/support-home
3) The signed firmware package is downloaded to the drive. It is received by the drive firmware and
placed into DRAM.
4) The signature is verified using PKCS #1, v1.5 RSA signature algorithm and public key in ROM. If
the verification fails an error is returned and the update is not performed. The RSA key/modulus
size for all current generation Seagate products is 2048 bits.
5) The firmware update package is written to flash. This overwrites the original firmware.
6) The FW performs a soft reset which loads and runs the new firmware.
7) At this point the firmware download port is unlocked. It can be locked by either performing a
power on reset or by resetting the _PortLocking Object PortLocked Column to TRUE.
The password required for firmware updates is the SID. The initial value for SID is a 32-byte manufactured SID
(MSID), public drive-unique value that is used as the default PIN. The drive must be “personalized” to change the
initial value of the SID to private values. Once the administrator takes ownership of the drive, the SID value is set
to the administrator configured value. The commands to configure the SID value are ATA SECURITY SET
PASSWORD, and TCG Set Method.
The TOE provides functions to configure the number of failed validation attempts required to trigger corrective
behavior. Try limits can be configured for Common SID and TCG Opal credentials only using the Try Limit
command.
6.4 User Data Protection
The TOE performs Full Drive Encryption such that the drive contains no plaintext protected data. The TOE is
encrypted by default and without user intervention using XTS-AES-256 mode.
6.4.1 Protection of Data on Disk (FDP_DSK_EXT.1)
The TOE is encrypted by default without user intervention using AES:XTS (as described in Section 6.2). There is
no restriction on reading or writing data to the SED until a user takes ownership using a TCG controller. Taking
ownership locks a drive and constitutes the initialization process providing data-at-rest protection. A locked drive
restricts data reads and writes based on the settings of the BandMasters (TCG Enterprise), Locking SP Users (TCG
Opal) and User or Master (ATA security mode).
There are three categories of storage: unencrypted for OS use, unencrypted for drive use, and encrypted. On Opal
SEDs, unencrypted for OS use includes shadow MBR, which is used for boot. On both Opal and Enterprise SEDs,
the system area of disk is not encrypted.
There is no host access to the system area. TCG Data Store tables are available unencrypted in the system area.
Administrators can store data in these tables through access-controlled TCG commands. An SED places no
restriction on what data is stored. Guidance documentation instructs administrators not to store protected data in the
tables.
6.5 Protection of the TSF
The TOE provides trusted firmware update and access control functions; protects Key and Key Material; and
supports power saving states. The TOE runs a suite of self-tests during initial start-up (on power on), before the
function is first invoked.
Seagate Non-proprietary
35
Seagate Non-proprietary
6.5.1 Firmware Access Control and Update Authentication
(FPT_FAC_EXT.1, FPT_FUA_EXT.1)
This section assumes that the firmware download port is in the locked state. Seagate drives all ship with the
firmware download port in the unlocked state. The firmware download port is placed into the locked state as part of
the steps to enable the CC operating mode.
The TOEs Firmware Access Control requires the administrator to unlock the firmware download port. This requires
authentication with the SID credential (password) in order for the firmware update to proceed. To enable firmware
download an administrator performs the following steps:
1) Open session to Admin SP.
2) Authenticate with SID credential (password).
3) Set FW download _PortLocking Object PortLocked Column to FALSE.
4) Close Session.
To perform a firmware download, an administrator performs the following steps:
1) Unlock firmware download port.
2) Obtain a genuine Seagate Secure firmware update package from:
https://www.seagate.com/support-home
3) The signed firmware package is downloaded to the drive. It is received by the drive firmware and
placed into DRAM.
4) The signature is verified using PKCS #1, v1.5 RSA signature algorithm and public key in ROM. If
the verification fails an error is returned and the update is not performed. The RSA key/modulus
size for all current generation Seagate products is 2048 bits.
5) The firmware update package is written to flash. This overwrites the original firmware.
6) The FW performs a soft reset which loads and runs the new firmware.
7) At this point the firmware download port is unlocked. It can be locked by either performing a
power on reset or by resetting the _PortLocking Object PortLocked Column to TRUE.
An error code is returned if any part of the firmware update process fails. The TOE only allows installation of an
update if the digital signature has been successfully verified.
The firmware key store and the signature verification algorithm is stored in a write protected area on the TOE. The
firmware can only be updated using the authenticated update mechanism by an authorized user where the authorized
source that signs TOE updates is Seagate. The TOE authenticates the source of the firmware update using the RSA
digital signature algorithm: with a key size (modulus) of 2048 bits. The mechanism uses the Root of Trust for
Update RTU key stored in ROM that contains the public key to verify the signature on an update image. An error
code is returned if any part of the firmware update process fails. The TOE only allows installation of an update if
the digital signature has been successfully verified.
6.5.2 Protection of Key and Key Material (FPT_KYP_EXT.1)
The TOE stores all wrapped keys in non-volatile memory only after they have been wrapped. Key wrapping is
performed using AES KW and AES GCM, as specified in FCS_COP.1(d).
Intermediate keys are not generated using submask combining.
6.5.3 Power Saving States and Timing (FPT_PWR_EXT.1,
FPT_PWR_EXT.2)
The TOE supports two states: device full off (D0) and device full on (D3). The TOE SEDs have two possible
transitions: power off to on and on to off. Only the transition from on to off applies to this requirement. The device
changes to off when the system removes power to the drive.
“A user-initiated request” is removing the power in the context of a SED.
Seagate Non-proprietary
36
Seagate Non-proprietary
Separately, the drive can be locked, but remains in a power on state. The requirement does not apply in this case.
6.5.4 RollBack Protection (FPT_RBP_EXT.1)
The TOE supports the functional capability to assure that downgrading to a lower security version number is not
possible. With this mechanism if a flaw in FW 1 is found then FW 2 is generated and downloaded to the drive.
Using the internal block point mechanism, FW 1 will no longer be compatible with the drive and cannot be
downloaded.
If a firmware update package is downloaded to the drive with an invalid firmware revision number, the RollBack
protection firmware in the TOE generates and returns an error code and the firmware update package is rejected
with one of the following error codes.
Roll back Error Message:
Error Number Message
0x0B740800 “Invalid Field Parameter”
0x05269920 “Trying to download older firmware over newer firmware”
6.5.5 TST Testing (FPT_TST_EXT.1)
The TOE runs a suite of self-tests during initial start-up (on power on), and/or before the function is first invoked.
The TOE runs the following Power on Self-Tests:
● Hardware/ASIC AES: Encrypt and Decrypt KATs performed
● ASIC SHA: Digest KAT performed
● ASIC RSA: Verify KAT performed
● ASIC/Firmware HMAC: HMAC KAT performed
● Firmware AES: Encrypt and Decrypt KATs performed
● Firmware AES-GCM: Encrypt and Decrypt KATs performed
● Firmware RSA: Verify KAT performed
● Firmware 800-90 DRBG: DRBG KAT performed
● Firmware 800-132 PBKDF: PBKDF KAT performed
● Firmware Integrity Check: Signature Verification
● Firmware 800-38F Key Wrap: AES Key Wrap and Unwrap KATs performed
● Firmware SHA-512: SHA-512 KAT performed
● Firmware FFC Diffie-Hellman Ephemeral Mode: Diffie-Hellman KAT performed
● Firmware 800-135 KDF: KFD KAT performed
● Firmware AES-GCM (large block size): Encrypt and Decrypt KAT performed
● Secure boot process
Additionally, the following Conditional tests are run:
● Firmware Load Check: RSA PKCS#1, v1.5 signature verification of new firmware image is performed
before it can be loaded. The new firmware is accepted only if the signature is verified. This test is run
when new firmware is downloaded.
Seagate Non-proprietary
37
Seagate Non-proprietary
● Firmware 800-90 DRBG (CRNGT): Newly generated random number is compared to the previously
generated random number. Test fails if they are equal. This test is run when a random number is generated.
● Firmware 800-90 DRBG Entropy (CRNGT): Newly retrieved entropy value is compared to previously
retrieved entropy value. Test fails if they are equal. This test is run when entropy is retrieved from entropy
pool.
Health test as described above (the conditional DRBG tests) are run for by all deterministic random bit generation
services consistent with section 11.3 NIST SP 800-90A. All tests are run in accordance with FIPS 140-2
requirements and described in further detail in the TOEs security policies. The self-tests demonstrate the correct
operation of the TSF. The relevant Seagate FIPS security policies can be found on the Cryptographic Module
Validation Program website at:
https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules
The relevant FIPS certification numbers are #2886, #2796 and #2695
For the secure boot process, the TOE first loads the FW from flash into DRAM using FW routines in ROM. The
TOE then verifies the RSA signature of the FW in DRAM using FW routines and the public key in ROM. If the
signature is verified to be correct then the ROM FW code transfers control to the FW in DRAM. If the signature
does not verify then a fatal error is indicated by the TOE. This test uses cryptography but is not a test of
cryptography per se and is considered a non-cryptographic test. .
6.5.6 Trusted Update (FPT_TUD_EXT.1)
The TOE provides authorized users with the ability to query the current version of the TOE firmware, the ability to
initiate the TOE firmware updates, and the ability to verify updates (prior to installing those updates) using the RSA
digital signature algorithm (with a key size (modulus) of 2048 bits) provided by Seagate.
For SATA SED drives the TOE firmware version is queried with the SATA Identify command. For SAS SED
drives the TOE firmware version is queried with the SAS Inquiry command.
See Section 6.5.1 for more details.
7. Protection Profile Claims
This ST is conformant to the collaborative Protection Profile for Full Drive Encryption – Encryption Engine
Version 2.0, 9 September 2016, [CPPFDE_EE] including the following optional and selection-based SFRs:
FCS_CKM.1(b), FCS_CKM.4(b), FCS_CKM.4(c)(1) HDD, FCS_CKM.4(c)(2) SSD and Hybrid, FCS_COP.1(a),
FCS_COP.1(b), FCS_COP.1(c), FCS_COP.1(d), FCS_COP.1(f), FCS_KDF_EXT.1, FCS_RBG_EXT.1,
FCS_CKM.4(e), FPT_FAC_EXT.1, FPT_FUA_EXT.1, and FPT_RBP_EXT.1.
As explained in Section 3, Security Problem Definition, the Security Problem Definition of the [CPPFDE_EE] has
been included by reference into this ST, and excludes A.STRONG_CRYPTO.
As explained in Section 4, Security Objectives, the Security Objectives of the [CPPFDE_EE] has been included by
reference into this ST.
The following table identifies all the Security Functional Requirements (SFRs) in this ST. Each SFR is drawn from
the [CPPFDE_EE]. The only operations performed on the SFRs drawn from the [CPPFDE_EE] are assignment and
selection operations.
Requirement Class Requirement Component Source
FCS: Cryptographic
support
FCS_CKM.1(b): Cryptographic Key Generation
(Symmetric Keys)
CPPFDE_EE
FCS_CKM.1(c): Cryptographic Key Generation
(Data Encryption Key)
CPPFDE_EE
FCS_CKM.4(a): Cryptographic Key Destruction CPPFDE_EE
Seagate Non-proprietary
38
Seagate Non-proprietary
(Power Management)
FCS_CKM.4(b): Cryptographic Key Destruction
(TOE-Controlled Hardware)
CPPFDE_EE
FCS_CKM.4(c)(1) HDD: Cryptographic Key
Destruction (General Hardware)
CPPFDE_EE
FCS_CKM.4(c)(2) SSD and Hybrid:
Cryptographic Key Destruction (General
Hardware)
CPPFDE_EE
FCS_CKM.4(e): Cryptographic Key Destruction
(Key Cryptographic Erase)
CPPFDE_EE
FCS_CKM_EXT.4(a): Cryptographic Key and
Key Material Destruction (Destruction Timing)
CPPFDE_EE
FCS_CKM_EXT.4(b): Cryptographic Key and
Key Material Destruction (Power Management)
CPPFDE_EE
FCS_CKM_EXT.6: Cryptographic Key
Destruction Types
CPPFDE_EE
FCS_COP.1(a): Cryptographic Operation
(Signature Verification)
CPPFDE_EE
FCS_COP.1(b): Cryptographic Operation (Hash
Algorithm)
CPPFDE_EE
FCS_COP.1(c): Cryptographic Operation
(Message Authentication)
CPPFDE_EE
FCS_COP.1(d): Cryptographic Operation (Key
Wrapping)
CPPFDE_EE
FCS_COP.1(f): Cryptographic Operation (AES
Data Encryption/Decryption)
CPPFDE_EE
FCS_KDF_EXT.1: Cryptographic Key Derivation CPPFDE_EE
FCS_KYC_EXT.2: Key Chaining (Recipient) CPPFDE_EE
FCS_RBG_EXT.1: Random Bit Generation CPPFDE_EE
FCS_SNI_EXT.1: Cryptographic Operation (Salt,
Nonce, and Initialization Vector Generation)
CPPFDE_EE
FCS_VAL_EXT.1(a): Validation (SATA) CPPFDE_EE
FCS_VAL_EXT.1(b): Validation (SAS) CPPFDE_EE
FDP: User Data
Protection
FDP_DSK_EXT.1: Protection of Data on Disk CPPFDE_EE
FMT: Security
Management
FMT_SMF.1: Specification of Management
Functions
CPPFDE_EE
FPT: Protection of
the TSF
FPT_FAC_EXT.1: Firmware Access Control CPPFDE_EE
FPT_FUA_EXT.1 Firmware Update
Authentication
CPPFDE_EE
FPT_KYP_EXT.1: Protection of Key and Key
Material
CPPFDE_EE
FPT_PWR_EXT.1: Power Saving States CPPFDE_EE
FPT_PWR_EXT.2: Timing of Power Saving
States
CPPFDE_EE
FPT_RBP_EXT.1: Rollback Protection CPPFDE_EE
FPT_TST_EXT.1: TSF Testing CPPFDE_EE
FPT_TUD_EXT.1: Trusted Update CPPFDE_EE
Table 8: SFR Protection Profile Sources
Seagate Non-proprietary
39
Seagate Non-proprietary
8. Rationale
This security target includes by reference the [CPPFDE_EE] Security Problem Definition, Security Objectives, and
Security Assurance Requirements. The security target makes no additions to the [CPPFDE_EE] assumptions and
excludes A.STRONG_CRYPTO. [CPPFDE_EE] security functional requirements have been reproduced with the
Protection Profile operations completed. Operations on the security requirements follow [CPPFDE_EE] application
notes and assurance activities. Consequently, [CPPFDE_EE] rationale applies but is incomplete. The TOE Summary
Specification rationale below serves to complete the rationale required for the security target.
8.1 TOE Summary Specification Rationale
Each subsection in Section 6, the TOE Summary Specification, describes a security function of the TOE. Each
description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding
security function. The set of security functions work together to satisfy all of the security functions and assurance
requirements. Furthermore, all of the security functions are necessary in order for the TSF to provide the required
security functionality.
This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that the security
functions are suitable to meet the TOE security requirements. The collection of security functions work together to
provide all of the security requirements. The security functions described in the TOE summary specification are all
necessary for the required security functionality in the TSF. Table 9 Security Functions vs. Requirements
Mapping demonstrates the relationship between security requirements and security functions.
C
r
y
p
t
o
g
r
a
p
h
i
c
s
u
p
p
o
r
t
U
s
e
r
D
a
t
a
P
r
o
t
e
c
t
i
o
n
S
e
c
u
r
i
t
y
M
a
n
a
g
e
m
e
n
t
P
r
o
t
e
c
t
i
o
n
o
f
t
h
e
T
S
F
FCS_CKM.1(b) X
FCS_CKM.1(c) X
FCS_CKM.4(a) X
FCS_CKM.4(b) X
FCS_CKM.4(c)(1) HDD X
FCS_CKM.4(c)(1) SSD and
Hybrid
X
Seagate Non-proprietary
40
Seagate Non-proprietary
FCS_CKM.4(e) X
FCS_CKM_EXT.4(a) X
FCS_CKM_EXT.4(b) X
FCS_CKM_EXT.6 X
FCS_COP.1(a) X
FCS_COP.1(b) X
FCS_COP.1(c) X
FCS_COP.1(d) X
FCS_COP.1(f) X
FCS_KDF_EXT.1 X
FCS_KYC_EXT.2 X
FCS_RBG_EXT.1 X
FCS_SNI_EXT.1 X
FCS_VAL_EXT.1(a) X
FCS_VAL_EXT.1(b) X
FDP_DSK_EXT.1 X
FMT_SMF.1 X
FPT_FAC_EXT.1 X
FPT_FUA_EXT.1 X
FPT_KYP_EXT.1 X
FPT_PWR_EXT.1 X
FPT_PWR_EXT.2 X
FPT_RBP_EXT.1 X
FPT_TST_EXT.1 X
FPT_TUD_EXT.1 X
Table 9: Security Functions vs. Requirements Mapping