Seagate Secure® Self-Encrypting Drive

Certificate

Approved Algorithms (17)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Seagate Secure® Self-Encrypting Drive
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>rollback<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status output<br/>Unauthenticated<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Seagate Secure® Self-Encrypting Drive
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>rollback<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status output<br/>Unauthenticated<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Seagate SecureTM Self-Encrypting Drive Non-Proprietary FIPS 140-3 Module Security Policy Security Level 2 Revision 0.8 Seagate Technology, LLC This document may be reproduced and distributed in its original entirety without revision Page 1

Table 1-2: Terms and Acronyms Page 5

The Cryptographic Module (CM) is defined as a hardware module. It is a multi-chip embedded physical embodiment contained in a full drive enclosure. No part of the enclosure is excluded from the security requirements. A photo of an example module is provided in Figure 1. The physical interface to the CM is a SATA or SAS connector. The data carried over the SATA and SAS connectors conform to the industry-standard SCSI, SATA, or TCG Enterprise SSC. The primary function of the module is to provide data encryption access control and cryptographic erase of the data stored on the drive media. The human operator of the drive interfaces with the CM through a “host” application on a host system. There is also an LED status indicator on the CM. The CM may operate in one of two mutually exclusive security modes:

• TCG Security Mode
• In the Security mode, access control for User Data is managed by the Locking SP. In TCG mode the CM can support multiple independent User Data bands/ranges via the TCG Enterprise SSC protocol. To operate the CM in TCG Security Mode, the host must follow the steps described in 11.1.1 and 11.1.2.
• ATA Security Mode
• In ATA mode, access control for User Data is managed by the ATA Security State. In ATA mode, the CM only supports a single User Data LBA band/range that includes all LBAs on the CM. To operate the CM in ATA Security Mode, the host must follow the steps described in 11.1.3 and 11.1.4. Note: ATA Security mode is only supported on CMs that support the ATA Security feature set. When the CM is in the TCG Security Mode or ATA Security Mode, the CM is in a Compliant state if the steps described in 11.1 are followed. If the CM is in a Compliant state, whether or not the CM is in an Approved mode or a Non-Approved mode is dependent on what types of services the host invokes. If the host invokes an Approved service, then the CM is an Approved mode. If the host invokes a Non-Approved service, then the CM is in a Non-Approved mode. Page 6

Figure 1: Seagate Self-Encrypting Drive Page 7

Table 2-1: Cryptographic Module Tested Configurations Select Hardware and Firmware Version combinations will output a different hardware version identification during the “Compliance Indicator Service” as detailed in the table below. There has been no change to the hardware itself. Page 9

Table 2-2: Hardware Substitute Configurations

This section describes the algorithms used by the CM. The Approved algorithms are described in section 2.3.1 and the Non-Approved Not Allowed algorithms are described in section 2.3.2. The CM does not implement any of the following categories of cryptographic algorithms:

• Non-Approved Algorithms Allowed in the Approved Mode of Operation
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Note: Not all algorithms, modes, and key sizes that appear in the module’s ACVP certificates are utilized by the module.

The Approved algorithms used by the CM are shown in Table 2-3: Approved Algorithms (HW) and Table 2-4: Approved Algorithms (FW). Page 10

Table 2-3: Approved Algorithms (HW) Page 11

1 The 96-bit IV used for AES GCM is generated by the module randomly by the DRBG.

2 The value of the Iteration Count used is 1000 which meets the requirements in [SP 800-132 rev1] and

Table 2-4: Approved Algorithms (FW) The Non-Approved, Not Allowed algorithms used by the CM are shown in Table 2-5: Non-Approved Algorithms Not Allowed in the Approved Mode of Operation. Table 2-5: Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Page 13

Table 3-1: Ports and Interfaces The CM does not support a control output interface. Page 15

This section describes the roles, services, and authentications supported by the CM. Some services in this section are identified as aligning with the “lock-based authentication model”. The “lock-based authentication model” is described in IG 4.1.A. The primary purpose of the CM is data-atrest protection for User Data and the “lock-based authentication model” is sufficient to meet this use case. Assuming the CM has been correctly initialized (see section 11.1), when the CM is powered cycled, the CM will be in a locked state and will require authentication and unlocking prior to the Approved service being available.

4 No operator authentication is enforced for the FW Download service that was unlocked by the

Set FW Ports service. If the new FW violates device FW rollback policy both the FW Download and Rollback FW Download ports must be unlocked. This service aligns with the “lock-based authentication model” (see section 4).

5 No operator authentication is enforced for the User Data Read / Write service that was unlocked

based authentication model” (see section 4). Page 16

6 No operator authentication is enforced for the FW Download service that was unlocked by the

Set FW Ports service. If the new FW violates device FW rollback policy both the FW Download and Rollback FW Download ports must be unlocked. This service aligns with the “lock-based authentication model” (see section 4). aligns with the “lock-based authentication model” (see section 4). Page 17

If the CM is operating in TCG Security Mode, the Approved services provided by the CM are described in section 4.5.1. If the CM is operating in ATA Security Mode, the Approved services provided by the CM are described in 4.5.2.

• G = Generate: The module generates or derives the SSP
• R = Read: The SSP is read from the module (e.g., the SSP is an output)
• W = Write: The SSP is updated, imported, or written to the module
• E = Execute: The module uses the SSP in performing a cryptographic operation
• Z = Zeroize: The module zeroizes the SSP Page 18

“True” and the LockOnReset value includes “Power Cycle”. The current values of these attributes can be determined using the Show Status Approved Service (i.e., the TCG Get Method on the associated LBA range locking object).

• G = Generate: The module generates or derives the SSP
• R = Read: The SSP is read from the module (e.g., the SSP is an output)
• W = Write: The SSP is updated, imported, or written to the module
• E = Execute: The module uses the SSP in performing a cryptographic operation
• Z = Zeroize: The module zeroizes the SSP

The Non-Approved services provided by the CM are described in Table 4-7. Table 4-7 Non-Approved Services

17 Locking is disabled for an LBA range if the ReadLockEnabled or WriteLockEnabled values are

set to “False”, or the LockOnReset value does not include “Power Cycle”. The current values of these attributes can be determined using the Show Status Approved Service (i.e., the TCG Get Method on the associated LBA range locking object),

During the power-on boot process, the CM will verify the authenticity and integrity of the CM firmware using RSA Signature Verification (certificate #A1093 ) with the following parameters:

• The key is the Signing Authority Key i.e., SAK (see section 9.2).
• The modulus size is 3072 bits.
• The hash function is SHA2-256 (#A1092). The operator can invoke the boot firmware integrity test on demand by performing a power-on reset operation on the CM. Page 25

The CM operates in a limited operational environment where the CM firmware (FW) may be updated by an external source via the FW download operation. Prior to accepting new FW provided by the FW download operation, the CM will verify the signature of the new FW (see section 10.2). Note: The ability to download FW to the device is restricted based on the state of the FW Download and Rollback Download logical ports (see section 4.5). All FW downloads require the FW Download port to be unlocked. Rollback FW downloads (i.e., downgrading FW to a release that violates the device FW rollback policy) require both the FW Download and Rollback FW Download ports to be unlocked, Page 26

The CM is a multi-chip embedded module of product grade components with standard passivation. The CM is surrounded in a metal enclosure that is opaque within the visible spectrum. To meet the level 2 physical security requirements, the CM employs a single factory installed tamper-evident labels to prevent physical tampering. Refer to Table 7-1 for actions required by the operator to ensure Figure 3: Module 1 Seal Application Locations Page 27

Table 7-1: Physical Security Inspection Guidelines Page 28

The CM does not provide mitigation against any non-invasive attacks. Page 29

The storage areas on the CM where SSPs may be present are described in Table 9-1. Table 9-1: SSP Storage Areas Page 30

The SSPs (Sensitive Security Parameters) used by the device are different depending on which security mode the CM is operating. The SSPs used by the CM are described in Table 9-2.

20 Source: section 4 Terms and Definitions of NIST Special Publication 800-90A. Values of V and the AES key are the critical values of the

internal state on which the security of this DRBG mechanism depends (i.e., V and the AES key are the “secret values” of the internal state).

21 PK is used for pre-operational FW integrity test and is not an SSP but included in this table for completeness.

22 SAK is used for pre-operational FW integrity test and are not SSPs but included in this table for completeness.

The Entropy sub-system uses a Non-Deterministic Random Bit Generator (NRBG) to generate random data. The NRBG is supplied with conditioned entropy via two Entropy sources. Each conditioned output of an entropy source is a 128-bit full entropy output. The NRBG used by the device is the XOR-NRBG construction described in SP 800-90C and the DRBG construction is based on SP 800-90A rev 1. The DRBG seed used for instantiation is constructed by concatenating the following values:

• Entropy Input (256 bits of conditioned entropy)
• Nonce (128 bits of conditioned entropy)
• Personalization String (64 bits of device unique data such as the device serial number padded to 256 bits) The concatenated value is passed to the derivation function Block_Ciper_df as described in SP 80090A rev. 1 which outputs 384 bits of seed material. The design of the entropy sources is based on the recommendations in SP 800-90B. The entropy sub-system has two independent entropy sources:
• Ring Oscillator entropy source The Entropy sources generate entropy samples when required by the Entropy sub-system. The raw samples from each entropy source are stored in independent entropy pools. The raw entropy samples from each source are concatenated into 128-bit blocks. When there are greater than 256 bits of entropy in an entropy pool23, based on the minimum entropy of the sources, the Entropy subsystem concatenates sufficient 128-bit blocks for 256 bits of entropy and passes the concatenation of these blocks to the CMAC conditioner (#A1081 (PES) and #A3515 (Ring Oscillator)). The entropy sources used by the CM are described in Table 9-3. Table 9-3: Non-Deterministic Random Number Generation Specification

The method used by the CM to zeroize SSPs is different depending on where the SSP is stored:

• If a SSP is stored in volatile memory, the CM will zeroize the SSP (when required) by writing the memory where the SSP is stored with a pattern of all bytes set to 0x00. Note: When the CM is powered down all SSPs stored in volatile memory are zeroized automatically as the volatile memory can only store data when powered.
• If a SSP is stored unprotected (i.e., plaintext) in non-volatile memory, the CM will zeroize the SSP (when required) by writing the memory where the SSP is stored with a pattern of all bytes set to 0x00 and then writing the new SSP value.

23 The combined entropy is calculated using Method 2 as described in IG D.O Combining Entropy from

• If a SSP is stored protected (i.e., encrypted using another SSP) in non-volatile memory, the CM will zeroize the SSP (when required) by writing the memory where the SSP is stored with a new SSP value.24

24 As indicated in Table 9-2 some keys are stored encrypted on the CM using an approved algorithm.

Per IG 9.6.A, they are considered “protected” thus not requiring zeroization when unprotected SSPs are zeroized. Page 35

The sections below list all self-tests performed by the module, along with the failure behavior when any of the self-tests fail. While in an error state, the module outputs an error indicator, disables cryptographic operations and the data output interface is inhibited. All pre-operational and conditional self-tests can be executed on-demand by power-cycling the module.

Table 10-1: Pre-Operational Self-Tests

Table 10-2: Conditional Self-Tests Page 37

To initialize the CM into the Compliant state, one of the following procedures must be followed: TCG Enterprise or ATA Security. Upon receiving the CM, the authorized operator must inspect the physical security mechanisms for tamper evidence and verify that the drive boots up in an uninitialized Security Mode. The “FIPS Operating Mode” Indicator designates whether the drive has been configured to operate in the Compliant state. The “FIPS Operating Mode” Indicator is a bit (byte 30, bit 0) in the Vendor Unique fields in Level 0 Device Discovery. If byte 30, bit 0 of the Vendor Unique fields is set to one (1), then the device is operating in a Compliant state. If the bit is set to zero (0), then the device is operating in a Non-Compliant state and is not considered a FIPS 140 validated CM.

1. Upon receipt of the product examine the shipping packaging and the product packaging to ensure it has not been accessed during shipping by the trusted courier.
2. At initialization and periodically thereafter, examine the physical security mechanisms for tamper evidence.
3. At initialization, set all enabled operator PINs applicable for the Compliant state to private values of at least 8 bytes (64 bits) in length: Drive Owner, EraseMaster, and BandMasters27.
4. Set ReadLockEnabled and WriteLockEnabled to “True” and the LockOnReset column to include “Power Cycle”, on at least one (1) User Data range.
5. At initialization, disable the “Makers” authority.
6. At initialization, the value of LockOnReset for FW Download port must be set to include “Power Cycle”.

1. The ReadLockEnabled and WriteLockEnabled values must be set to “True” and the LockOnReset value must include “Power Cycle”, for at least one (1) User Data range.
2. The “Makers” Authority must be disabled.
3. The LockOnReset value for the FW Download port must include “Power Cycle”.

1. Upon receipt of the product examine the shipping packaging and the product packaging to ensure it has not been accessed during shipping by the trusted courier.
2. At initialization and periodically thereafter, examine the physical security mechanisms for tamper evidence.
3. Transition the CM to ATA Security Mode by setting the User Password to a private value of 32 bytes (256 bits) in length.
4. At initialization, set the remaining operator Passwords/PINs applicable for the Compliant state to private values of at least 8 bytes (64 bits) in length: Master and Drive Owner (optional).
5. At initialization, the value of LockOnReset for FW Download port must be set to “Power Cycle”.

1. The “Makers” Authority must be disabled.
2. The LockOnReset value for the FW Download port must include “Power Cycle”.

27 A subset of the operator authority/PINs are enabled by default. If use of any other

authority/PINs not enabled by default is required in the Compliant state, the Crypto Officer will need to enable them as part of the initialization steps. Page 38

When the CM reaches end-of-life, the Crypto Officer must zeroize all SSPs prior to discarding the CM. The Crypto Officer shall perform the following steps when the CM is at end-of-life:

1. The Crypto Officer shall revert the CM to the factory default state by invoking the Revert or RevertSP methods28 on the Admin SP.
2. If step 1 fails, all SSPs on the device may not have been sanitized. If this occurs, the Crypto Officer should handle the CM per organizational policies.

28 The Revert/RevertSP methods will cause the CM to zeroize all the SSPs and exit the Compliant

The CM does not make claims to mitigate against other attacks beyond the scope of FIPS 140-3. Page 40