TuffServ® Encryption Module (TSEM)

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for TuffServ® Encryption Module (TSEM)
  %% 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>Update<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Unauthenticated</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."]
  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?"]
  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"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  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 clue;
  class I2,I3 infer;
  class R2,R3 risk;
  class E2,E3 evidence;

flowchart LR
  %% Deterministic clue tier for TuffServ® Encryption Module (TSEM)
  %% 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>Update<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Unauthenticated</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 clueLow;

Security Policy, page by page

Ampex Data Systems Corporation TuffServ® Encryption Module (TSEM) Document Version 1.11 May 29, 2024 Prepared for: Prepared by: Ampex Data Systems Corporation KeyPair Consulting Inc.

Hayward, CA 94545 San Luis Obispo, CA 93401 ampex.com keypair.us +1 650.367.2011 +1 805.316.5024

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table of Contents

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy List of Tables

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy List of Figures

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

This document defines the Security Policy for the TuffServ® Encryption Module by Ampex, hereafter denoted the “TSEM”. The TSEM:

• is a non-modifiable environment.
• does not implement mitigations of attacks outside the scope of the FIPS 140-3 specification. The TSEM is validated to FIPS 140-3 overall Level 2 requirements with security levels as specified in Section 1.2.

Purpose and Use: The hardware TSEM is a multichip embedded embodiment in FIPS 140-3 terminology. The TSEM provides cryptographic key management services for the TuffServ® secure storage device. Module Type: Hardware Module Embodiment: MultiChipEmbed

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Cryptographic Boundary: The Tested Operational Environment’s Physical Perimeter (TOEPP) is depicted in Figure

1. The cryptographic boundary is the metal enclosure and the P1 connector on the back of the enclosure. The enclosure opening for the P1 connector does not expose any circuitry except for the P1 connector and associated traces or decoupling capacitors. Front of Module Back of Module with P1 Connector Top of Module (Location of Tamper Seal #1) Bottom of Module (Location of Tamper Seal #2) Figure 1: TSEM Physical Perimeter The TSEM logical functionality (outlined in red) in the context of the larger TuffServ® product is shown in Figure
2. The two SATA controllers (SATA CTL) implement all data plane functionality, including AES XTS data encryption and decryption to and from the storage media. The SoC implements control plane functionality, such as module initialization, configuration, and provisioning. All TSEM firmware is contained within the boundary.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Figure 2: Block Diagram

Mode Name Approved Mode

Description Approved mode of operation

Type Approved

Status Indicator

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

N/A for this Module. Modes List and Description: Table 3: Modes List and Description The TSEM supports only an Approved mode of operation, with no configuration necessary to operate and remain in the Approved mode. The TSEM design corresponds to the TSEM security rules specified in Section 11.4.

Approved Algorithms: Cipher Table 4: Approved Algorithms - Cipher

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Signature Table 5: Approved Algorithms - Signature Random Table 6: Approved Algorithms - Random Message authentication Table 7: Approved Algorithms - Message authentication Key derivation Table 8: Approved Algorithms - Key derivation Message digest Table 9: Approved Algorithms - Message digest Vendor-Affirmed Algorithms: Table 10: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this Module.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this Module. Non-Approved, Not Allowed Algorithms: N/A for this Module.

Table 11: Security Function Implementations

In accordance with SP 800-38E, the XTS-AES algorithm is to be used for confidentiality on storage devices. The TSEM complies with FIPS 140-3 IG C.I by:

• Generating Key_1 and Key_2 independently according to the rules for component symmetric keys from SP 800-133 Rev. 2 Section 6.3.
• Explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS-AES algorithm to process data with them.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

Table 12: Entropy Sources The entropy source does not have an ESV certificate. In accordance with FIPS 140-3 IG 9.3.A option 1(a), the TSEM generates ENT within the module boundary using a SP 800-90B compliant ENT (P) present on the SoC component. Per SP 800-90A Rev. 1 Table 2, the SHA2-256 Hash_DRBG requires 256 bits of entropy (equivalent to security strength) within the 440-bit DRBG_Seed value. As input to the SP 800-90A Rev. 1 Hash_df, the TSEM collects 1024 bytes of data from the ENT (P) to use as entropy and nonce input. The SP 80090B compliant assessment supports at least 0.099 bits of entropy per bit of ENT (P) output; as such the DRBG seeding material contains at least 811 bits of entropy, well in excess of the requirement for generating the largest key size of 256 bits.

The TSEM performs symmetric key generation per FIPS 140-3 IG D.H (direct output of the DRBG):

• Random values are produced in accordance with SP 800-133 Rev. 2 Section 4, in that the DRBG output is provided directly as the random output.
• All usage of DRBG output is of the form B = U⊕V, where V = 0.
• Symmetric keys are generated directly by the DRBG in accordance with SP 800-133 Rev. 2 Section 6.1. The TSEM also performs derivation of symmetric keys in accordance with SP 800-133 Rev. 2 Section 6.2.

Key agreement: N/A for this Module. Key transport: The Module uses AES-KW with AES-256, which provides 256 bits of strength. This is an Approved key transport method compliant with SP 800-38F and FIPS 140-3 IG D.G.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

Table 13: Ports and Interfaces The P1 connector, shown in Figure 1, is the only physical port of the TSEM. It incorporates all of the specified interfaces.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 14: Authentication Methods

Table 15: Roles The CO and the User roles are implicitly identified by the service requested.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy G,E,Z

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 16: Approved Services The TSEM supports two status mechanisms: nop returns minimal status information, status returns additional information. A return code of 0 represents a state without errors. Any other return code is the specific function error of the TSEM. The phrase “self-test selection” in do_bit and get_bit_results commands refers to an enumerated target of self-tests, which can specify the firmware integrity test, subsets of CASTs or SATA controller self-tests. “BIT” refers to built-in tests. eDEK and eTMK refer to the wrapped set of AES XTS (DEK) keys or wrapped TMK, respectively. CPSW (control plane status word): the Approved mode indicator and success or failure (enumerated) status. The Indicator column above shows all possible (success or failure) indicator values. The TSEM is a slave device and as such can return status only when it receives a command. If the TSEM fails any CAST or firmware integrity test, it will respond as described in Section 10.4. The return code TSEM_STATUS_OK confirms normal successful completion of the command in the Approved mode, similar to FIPS 140-3 IG 2.4.C example scenario 2, a global indicator for modules having Approved services only. The relationship of SSPs and security functions is detailed next, using the following notation based on the cited specifications: SP 800-38F Authenticated encryption: Ciphertext (wrapped) Key = KW-AE (Wrapping Key, Plaintext Key). SP 800-38F Authenticated decryption: Plaintext key = KW-AD (Wrapping Key, Ciphertext (wrapped) Key). SP 800-90A Rev. 1 DRBG Generate (Length): generate Length random bits. SP 800-108 Rev. 1 Key Based Key Derivation Function (KBKDF) used to derive symmetric Key Material from a Key Derivation Key. The TSEM uses the Counter mode with HMAC as PRF. Key Material = KBKDF (Key Derivation Key, Label, Context, Length)

• Label: binary string that identifies the purpose for the derived keying material.
• Context: a binary string used to bind the derived value to an entity or process.
• Length of material to be derived in bits. The notation eKeyname refers to Keyname in encrypted (ciphertext) form. It is not a different CSP. create_keys [1] Verify command (with COA Public).

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy [2] TIK = KBKDF (PIK): Derive TIK from PIK. [3] TMK = KW-AD (TIK, eTMK): Use TIK to obtain KEK. [4] KEK = KBKDF (TMK). Generate DEKs and wrap using KEK. Return wrapped DEKs. (eDEK refers to the wrapped DEK.) [5] DEK = DRBG Generate. [6] Verify AES XTS non-equal. [7] eDEK = KW-AE(KEK, DEK). create_random Performs a DRBG generate. DRBG_EI is used to seed as required. Random generation updates the DRBG_State. destroy [1] Verify command (with COA Public). [2] Halt / reset SATA controllers. [3] Overwrite RAM CSPs. [4] Erase NVM CSPs. do_bit, get_bit_results, nop, status and Media control do not utilize approved security functions or access SSPs. The term “bit” refers to built-in self-test functionality. The nop command provides a mechanism to check simple status; the status command provides extended status information, including name and version correlatable to the CMVP listing (as required by ISO/IEC 19790:2012 AS04.13). The status command response (intended for use by the host device driver) is a binary structure encoded in Base64 for transfer. When translated to ASCII, the response includes the module name (“TSEM”) as well as version information for the SoC and the SATA controllers. provision [1] Verify command (COA Public). [2] TIK = KBKDF (PIK): Derive TIK from PIK. [3] eTMK = KW-AE (TIK, TMK): Wrap TMK using TIK. (eTMK refers to the wrapped TMK.) put_keys Update SATA controller. [1] Verify command (COA Public). [2] TIK = KBKDF (PIK): Derive TIK from PIK. [3] TMK = KW-AD (TIK, eTMK): Use TIK to obtain KEK. [4] KEK = KBKDF (TMK): Derive KEK from TMK. [5] DEK = KW-AD (KEK, eDEK): Use KEK to unwrap DEK. [6] Verify AES XTS key constituents are non-equal. [7] Update SATA controller DEK.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy SATA reset Resets the SATA engine hardware, zeroizing the DEK SSPs in both channels. The DEK keys are erased from SATA controller registers but remain intact in the TSEM RAM. read Decrypts the data using AES-XTS; supports 2 channels of decryption with separate keys. Write Encrypts the data using AES-XTS; supports 2 channels of encryption with separate keys.

The TSEM uses ECDSA P-384 SHA2-384 signature verification performed over all module firmware as the integrity technique.

The operator can initiate the integrity test on demand by power cycling the module or by issuing the do_bit command.

Type of Operational Environment: Non-Modifiable

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 17: Mechanisms and Actions Required The hardware TSEM is a multichip embedded embodiment packaged in a metal enclosure. The metal enclosure is protected by two (2) tamper seals placed within the seal guides (milled sections on the enclosure), as shown in Error! Reference source not found.. The metal enclosure is opaque in the visible spectrum. Ampex maintains control over the tamper seals, which may only be applied or replaced in the factory setting. Figure 4: Location of Tamper Seal #1 (Top Edge) Figure 3: Location of Tamper Seals (Front) Figure 5: Location of Tamper Seal #2 (Bottom Edge)

Name COA Public

Description Verification of CO operator commands.

Size - Strength Size: 384 - Strength: 192

Type - Category G ECDSA P-384 - PSP

enerated By

Established By

Used By Signature ECDSA

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

Table 19: SSP Input-Output Methods

Table 20: SSP Zeroization Methods TSEM code destroys all plaintext CSPs prior to return from any control plane command.

Name DEK DRBG_C DRBG_EI DRBG_Seed DRBG_V KEK PIK TIK TMK

Description AES XTS data encryption keys (DEKC1, DEKC2, DEKD1, DEKD2). DRBG state value C. DRBG Entropy Input (inclusive of nonce). DRBG Seed (required per CMVP SSP conventions). DRBG state value V. AES-256 key used to wrap DEK keys. Platform Identity Key, used to derive TIK which unwraps TMK; success authenticates host to TSEM. TSEM Identity Key: used to wrap the TMK. TSEM Master Key: AES-256 key used to derive KEK.

Size - Strength Size: 256 - Strength: 256 Size: 440 - Strength: 256 Size: 1024 - Strength: 256 Size: 440 - Strength: 256 Size: 440 - Strength: 256 Size: 256 - Strength: 256 Size: 256 - Strength: 256 Size: 256 - Strength: 256 Size: 256 - Strength: 256

Type - Category Symmetric - CSP Hash_DRBG_C - CSP Entropy input - CSP DRBG_Seed - CSP Hash_DRBG_V - CSP Symmetric - CSP Symmetric - CSP Symmetric - CSP Symmetric - CSP

Generated By CKG Section 4 CKG Section 6.1 Hash DRBG Hash DRBG Hash DRBG Key derivation Key derivation

Established By

Used By Cipher Hash DRBG Hash DRBG Hash DRBG Hash DRBG KTS Key derivation KTS Key derivation

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy 6.1 Table 21: SSP Table 1

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 22: SSP Table 2

Table 23: Pre-Operational Self-Tests The corresponding ECDSA signature verification CAST is performed prior to the integrity test.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 24: Conditional Self-Tests All cryptographic algorithm self-tests (CASTs) must complete successfully prior to any other use of cryptography by the TSEM. Table 25: Pre-Operational Periodic Information Table 26: Conditional Periodic Information

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy Table 27: Error States If one of the CASTs fails, the TSEM enters the ERROR state. The error state is persistent, and only Status services are available. All attempts to use the TSEM’s services result in the return of a non-zero error code in the range -40 (TSEM_ERROR_CYBER) to -47 (TSEM_ERROR_CYBER_LYCAN2).

The TSEM automatically invokes all self-tests on each power-on or reset. The conditional self-tests may also be invoked on demand by the Self-Test service do_bit command; detailed results are available using the Self-Test service get_BITResults command.

The TSEM is a subsystem of the TuffServ® product and is not intended for use in other settings. The TSEM User and CO Guide documents all procedures for the following:

• Secure installation, initialization, configuration, and provisioning of the TSEM.
• Secure distribution and delivery of the TSEM. The module only operates in the Approved mode of operation. There are no maintenance requirements for the TSEM.

The TSEM User and CO Guide is inclusive of all information required per ISO/IEC 19790:2012 Section 7.11.9.

The TSEM User and CO Guide is inclusive of all information required per ISO/IEC 19790:2012 Section 7.11.9.

The TSEM enforces the following security rules:

1. All services implemented by the module are described in the tables below. The module has no other mechanism which permits access to CSPs.
2. Data output is inhibited during key generation, self-tests, zeroization, and the error state.
3. Control output is inhibited whenever the module is in the error state and during self-tests.
4. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
5. The module does not support manual key entry.
6. The module does not support firmware loading.
7. The module does not output plaintext CSPs or intermediate key values.

TuffServ® Encryption Module (TSEM) FIPS 140-3 Security Policy

8. The module does not allow CSPs entered in the module in encrypted form to be displayed in plaintext.
9. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
10. The module can use only algorithms that have passed self-tests.
11. The module prohibits changing to the Crypto Officer state from any other role other than the Crypto Officer.
12. The module does not support multiple concurrent operators, a maintenance role or a bypass capability.

The TSEM User and CO Guide documents all procedures for decommissioning and sanitization of the TSEM.