IronKey Keypad 200 Series

Certificate

Approved Algorithms (8)

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

flowchart LR
  %% Deterministic review-risk graph for IronKey Keypad 200 Series
  %% 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>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status output<br/>unauthenticated</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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for IronKey Keypad 200 Series
  %% 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>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status output<br/>unauthenticated</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,C6 clueLow;

Security Policy, page by page

Kingston Technology Company, Inc. IronKey Keypad 200 Series Version 1.0 This document may be freely reproduced and distributed only in its entirety and without modification.

This document may be freely reproduced and distributed only in its entirety and without modification.

This document may be freely reproduced and distributed only in its entirety and without modification.

The Kingston Technology Company, Inc. (Kingston) IronKey Keypad 200 Series is a hardware, multichip standalone, cryptographic module that provides hardware-encrypted storage of user data. Access to encrypted data is authenticated with user input via the built-in keypad.

The module is designed to meet the FIPS 140-3 Security Level 3 requirements for each of the applicable sections documented within ISO/IEC 19790, Section 6 as shown in Table 1. Table 1: Security Levels ISO/IEC 24759 FIPS 140-3 Security Section 6 Section Title Level

Overall Level: 3 This document may be freely reproduced and distributed only in its entirety and without modification.

Purpose: The IronKey Keypad 200 Series provides hardware-encrypted storage of user data. Access to encrypted data is authenticated with user input via the built-in keypad. The module is designed to interface with a general-purpose computer (GPC) or similar device. Module Type: The IronKey Keypad 200 Series is defined as a hardware module (refer to ISO/IEC 19790, Section 7.2.2) Embodiment: The module’s physical embodiment is defined as multi-chip standalone. Module Characteristics: User data is protected by 256-bit XTS-AES encryption that secures sensitive information from unauthorized disclosure in the event that the module is lost or stolen. The critical components within the module are encapsulated inside a hard, opaque, production-grade epoxy. There is a non-replaceable battery within the module. The data encryption key (DEK) and other sensitive security parameters (SSPs) are generated within the module, on-demand by an approved NIST SP 800-90A DRBG 1. The seed for the DRBG is also produced within the module from a hardware-based, NIST SP 800-90B compliant entropy source. The user interface for the module is an alphanumeric keypad with eleven (11) buttons and three (3) status-indicator LEDs. The LEDs are each a different color (red, green, and blue) and in distinct locations. The keypad accepts the User or Cryptographic Officer (CO) password when creating new credentials and when authenticating to unlock the module. The LEDs provide status information while entering authentication credentials and using the module.

1 SP 800-90Ar1

• Recommendation for Random Number Generation Using Determinstic Random Bit Generators. NIST. (June 2015).

This document may be freely reproduced and distributed only in its entirety and without modification.

The module is a multi-chip standalone cryptographic module whose outer enclosure defines the cryptographic boundary and Tested Operational Environment’s Physical Perimeter (TOEPP) (refer to Figure 1 and Figure 2). Figure 1: IronKey Keypad 200 Series (USB-A) Cryptographic Boundary Figure 2: IronKey Keypad 200 Series (USB-C) Cryptographic Boundary This document may be freely reproduced and distributed only in its entirety and without modification.

The IronKey Keypad 200 Series cryptographic module is designed to meet the requirements of FIPS 140-3 Security Level 3 (refer to Table 1). The module is available in the following configurations: − IKKP200/xGB (USB A) − IKKP200C/yGB (USB C) x = 8, 16, 32, 64, 128, 256, 512 (denotes module’s memory capacity in GB) y = 8, 16, 32, 64, 128, 256 (denotes module’s memory capacity in GB)

The module’s operating environment is defined as non-modifiable. The FIPS 140-3 Security Level 3 validated versioning information is shown in Table 2. Table 2: Tested Configurations Model Hardware Version Firmware Processor(s) Distinguishing Features Version IronKey Keypad IKKP200/8GB 2.00.0 STMicroelectronics 32-bit MCU 8GB of user data storage; USB A

200 8GB ARM-based Cortex & Phison

IronKey Keypad IKKP200/16GB 2.00.0 Electronics PS2251-13 16GB of user data storage; USB A

IronKey Keypad IKKP200/32GB 2.00.0 32GB of user data storage; USB A

IronKey Keypad IKKP200/64GB 2.00.0 64GB of user data storage; USB A

IronKey Keypad IKKP200/128GB 2.00.0 128GB of user data storage; USB A

IronKey Keypad IKKP200/256GB 2.00.0 256GB of user data storage; USB A

IronKey Keypad IKKP200/512GB 2.00.0 512GB of user data storage; USB A

IronKey Keypad IKKP200C/8GB 2.00.0 STMicroelectronics 32-bit MCU 8GB of user data storage; USB C 200C 8GB ARM-based Cortex & Phison IronKey Keypad IKKP200C/16GB 2.00.0 Electronics PS2251-13 16GB of user data storage; USB C 200C 16GB IronKey Keypad IKKP200C/32GB 2.00.0 32GB of user data storage; USB C 200C 32GB IronKey Keypad IKKP200C/64GB 2.00.0 64GB of user data storage; USB C 200C 64GB IronKey Keypad IKKP200C/128GB 2.00.0 128GB of user data storage; USB C 200C 128GB IronKey Keypad IKKP200C/256GB 2.00.0 256GB of user data storage; USB C 200C 256GB To identify a module covered by this security policy, locate the product hardware identifier from the back side of the module housing in the table above. Then, use the ‘Show Version’ service to verify that the module identifier (Red, Blue, Green LED Blink = IronKey Keypad 200 Series) and firmware version (e.g., Red LED blinks twice = 2.00.0). This document may be freely reproduced and distributed only in its entirety and without modification.

The module does not exclude any components from the requirements of FIPS 140-3.

The module supports a single, approved mode of operation with only approved services. There are no non-approved modes, degraded modes, or non-approved services available to the module. Upon successful completion of the pre-operational and conditional self-tests on power-up, the module provides an indicator of the approved mode identified by the three status-indicator (Red, Green, and Blue) LEDs blinking once simultaneously.

The IronKey Keypad 200 Series supports the approved cryptographic algorithms shown in Table 3.

The module supports the following approved cryptographic algorithms. Table 3: Approved Algorithms CAVP Algorithm & Standard Mode / Method Description / Key Size(s), Use / Function Cert. Key Strength(s)

3749 AES XTS 256-bits Encryption of user data within storage

(NIST SP 800-38E 2) application only

3757 AES ECB 128-bit, 256-bit Block cipher basis of CTR-DRBG for

(FIPS 197 3 CTR encryption/decryption of the DEK NIST SP 800-38A, NIST SP 800-38B 4)

3757 CMAC AES 128-bits CO/User authentication

1032 DRBG AES-CTR 256-bits Random bit generator for the generation

(NIST SP 800-90A, of encryption keys and salts NIST SP-800-133 5) -- ENT (P) - 384-bits Entropy source used to seed the DRBG (NIST SP-800-90B)

2459 HMAC SHA-1 160-bits Algorithmic basis of PBKDFv2

(FIPS 198-1 6) A777 PBKDFv2 HMAC-SHA-1 1 in 10,000,000 (~23 bits) Derivation of the KEK. Conforms to FIPS (NIST SP 800-132 7) 140-3 Implementation Guidance (IG) D.N: the module supports option 2a as documented in SP 800-132 § 5.4

3127 SHS SHA-1 N/A Primitive within HMAC-SHA-1

2 SP 800-38E

• Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage Devices.

4 SP 800-38A

• Recommendation for Block Cipher Modes of Operation: Methods and Techniques. NIST. (December 2001).

5 SP 800-133r2

• Recommendation for Cryptographic Key Generation. NIST. (June 2020).

6 FIPS 198-1

• The Keyed-Hash Message Authentication Code (HMAC). NIST. (July 2008).

7 SP 800-132

• Recommendation for Password-Based Key Derivation: Part 1: Storage Applications. NIST. (December 2010).

This document may be freely reproduced and distributed only in its entirety and without modification.

The module supports the following vendor affirmed algorithms. Table 4: Vendor Affirmed Algorithms Algorithm Standard Modes/ Methods Description / Key Use/Function Size(s) / Key Strength(s) CKG NIST SP-800-133 9 Per Section 4 The unmodified The unmodified output of the DRBG is used for output from SP generating symmetric keys 800-90A DRBG (256 bits)

For all approved services the module supports only approved algorithms. Table 5: Non-Approved, Allowed Algorithms Algorithm Caveat Use/Function N/A N/A N/A

The module does not support any non-approved algorithms. Table 6: Non-Approved, Allowed Algorithms with No Security Claimed Algorithm Caveat Use / Function N/A N/A N/A

The module does not support any non-approved, not allowed algorithms. Table 7: Non-Approved, Not Allowed Algorithms Algorithm / Function Use / Function N/A N/A

The module does not support key establishment and therefore does not support any key agreement or key transport schemes.

9 SP 800-133r2

• Recommendation for Cryptographic Key Generation. NIST. (June 2020).

This document may be freely reproduced and distributed only in its entirety and without modification.

Table 8: Security Function Implementations Name Type Description SF Properties Algorithms Algorithm Properties N/A N/A N/A N/A N/A N/A

The module utilizes only approved algorithms that are tested and validated under the Cryptographic Module Validation Program (CAVP).

The module incorporates a NIST SP 800-90A CTR-DRBG (Cert. #1032) that is seeded with 384 bits of entropy from a NIST SP 800-90B conforming physical entropy source. The unmodified output of the DRBG is used for generating symmetric keys and salts.

The module generates cryptographic keys using a NIST SP 800-90A conforming DRBG (Cert. #1032) for the encryption and protection of user data.

The module does not support key establishment.

The module relies upon the standard USB protocol for communication with general purpose computer (GPC) systems.

The module incorporates both physical ports and logical interfaces. This document may be freely reproduced and distributed only in its entirety and without modification.

Table 9: Physical Ports and Logical Interfaces Physical Port Logical Interface Description USB Port (Rx/Tx) Data input The USB Data port connects the module to the host computer. It is used to exchange Data output decrypted user data as well as control and status information for the USB protocol Control input Status output When the drive is locked the USB interface is disabled Alphanumeric Data input The keypad with ten (10) alphanumeric labeled buttons is connected to button inputs Keypad (0-9) The keypad is used to enter User or CO Password KEY Button Control input The KEY button is connected to a button input. It is used to awaken the module from low-power sleep and to control UI flow including selection of the role

3 x LEDs Status output Refer to Table 11, Table 12, Table 16, Table 17, Table 18, and Table 19 for details

(Red, Green, & Blue) USB Port (VCC) Power Input The USB VBUS (+5VDC) charges the battery and provides power to the module and embedded storage components

The module implements a trusted channel for the input of plaintext SSPs in the form of passwords via the module’s keypad. Each key is mapped to a dedicated, physically separated channel. The channel is protected by the physical security mechanisms inherent within the module. This document may be freely reproduced and distributed only in its entirety and without modification.

The module supports identity-based authentication in the form of a unique ID / Password combination. The authentication method of both Crypto Officer and User is the password-based authentication technique known as a Memorized Secret in conformance with NIST SP 800-140E and SP 800-63B (refer to Section 5.1.1). The Crypto Officer and User roles authenticate via the module’s keypad interface. The module does not support a feedback mechanism or output CO or User authentication data outside of the cryptographic boundary. The module enforces some constraints on the creation of a Password. The following Password forms will be rejected by the module as invalid: • Identical repeating characters, e.g. 77777777 • Ascending or descending characters e.g. 12345678 or 98765432 The Password from either the User or the CO is input to a PBKDF that produces the Key Encryption Key (KEK) associated to the role. The KEK is used to encrypt or decrypt the DEK with AES CTR (Cert. #3757) and authenticate the CO/User using AES CMAC (Cert. #3757). Table 10: Authentication Methods Name Description Mechanism Strength Each Attempt Strength Per Minute ID & Password CO and User role au- ID & Password The upper bound for the proba- The probability of the consecuthentication method bility of having the password tive failed authentication atguessed at random is: tempts in one minute period is The password is at 1 / (10^8) or 1 in 100,000,000 approximately 10-7 or 1 chance least 8 chars in length in 10,000,000 The authentication strength for the module is determined by the Password. The Password is composed of a sequence of decimal digits 0-9, as marked on the keypad buttons, selected by the User or CO. Most of the buttons also bear alphabetic letters (refer to Figure 1). The minimum Password length is eight (8) characters

10. The maximum Password length is 15 characters. The probability of a successful, random guess of a minimum length Password is approximately 10-8 or 1 chance in 100,000,000
11. The module protects against brute-force attempts to guess a role’s Password by permitting no more than ten (10) consecutive incorrect guesses before locking out that role. Incorrect Password attempts are counted independently for each role. The probability of an attacker correctly guessing a Password in any time period 12, such as a one-minute interval, is 10-7 or 1 chance in 10,000,000.

10 As per SP 800-63B, in Approved mode the module checks and enforces a minimum password length of eight (8)

11 Sequential and repeating Passwords are not allowed. For example, the module will reject a Password of 1-2-3-4-5-6-7-8 or 7-6-5-4-3-

2-1-0. Attempts to create such a Password will cause the module to indicate an error. There are 270 such combinations.

12 In this product, a single successful attempt to guess a Password has a probability one in 100,000,000 (10-8). Ten guesses has a

probability of one in 10,000,000 (10*10-8 or 10-7) of success. The standard requires that the probability of a successful guess be less than one in 100,000 (10-5) in a one-minute period. The authentication mechanism of this module is better than the standard requires, over any time interval—including a one-minute period. A probability of one in 10,000,000 (10-7) is less likely than one in 100,000 (105). This document may be freely reproduced and distributed only in its entirety and without modification.

The module implements level 3, identity-based authentication with two distinct identities, one User identity and one Crypto-Officer identity. While unauthenticated, the module supports a limited set of services such as checking the module status and zeroizing the module using the Factory Reset service. Table 11: Roles, Service Commands, Input and Output Role Service Input Output CO Set CO Password Keypad command + - Solid Red LED  Solid Green LED (Success) New CO Password Set User Password Keypad command + - Solid Red LED  Solid Green LED (Success) New User Password Erase Private Partition Data Keypad commands - Solid Red LED  Solid Red & Green LEDs  (Control Input) + CO Green flickering LED indicating that all data has Password been deleted CO / User Unlock Private Partition CO / User - Solid Red LED  Solid Green LED (Success) (Login) ID & Password - Solid Red LED Lock Private Partition Keypad command - Solid Red LED  Fades to off (Logout) (Control Input) / Remove Power Read / Write Private Disk Access - Blue LED flashes continuously Partition Data - Read/Write partition data Configure Idle Timeout Lock Keypad command + - Solid Red LED  Solid Green LED (Success) Timeout Value Enable / Disable Keypad command - Solid Red LED  Solid Green LED (Success) Read Only (Control Input) Show Module Version Keypad command - All LEDs illuminate (indicating IronKey Keypad (Control Input) 200 Series) - Red and Green LEDs output firmware version View Last Error Keypad command (Control Input) Unauthenticated Factory Reset (zeroize) Keypad command - Solid Red & Green LEDs  Solid Red LED (Control Input) Show Status Keypad command Returns roles configured on the module: (Control Input) - Red LED blinks continuously for 10 seconds (shows only the CO role exists) - Red & Blue LED blink continuously for 10 seconds (shows both CO & User have been defined) Run Self-tests Power Refer to Table 16 and Table 17 This document may be freely reproduced and distributed only in its entirety and without modification.

The table below summarizes the Approved Services of the module. The SSP Access column identifies the SSPs accessed for each service with codes specifying the kind of access granted during the service operation. SSP access rights are defined as follows: − G = Generate: The module generates or derives the SSP. − R = Read: The SSP is read from the module (e.g., the SSP is 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. Table 12: Approved Services Name Description Approved Keys and / or Role Access Rights to Indicator Security SSPs Keys and / or Functions SSPs Configure Idle Timeout Sets the how long N/A N/A CO / User N/A Solid Red LED  Solid Lock the drive can be idle Green LED (Success) before needing to reauthenticate Erase Private Partition Zeroizes the drive AES DEK CO DEK (G, E, Z) Solid Red LED  Solid Data partition (Cert. #3757) DRBG Internal DRBG Internal Green LED (Success) DRBG State State (G, E, Z) (Cert. #1032) HMAC User KEK (Z) (Cert. #2459) SHS (Cert. #3127) Enable / Disable Read Sets the data N/A N/A CO / User N/A Solid Red LED  Solid Only partition to read only Green LED (Success) Factory Reset Resets the module N/A DEK Unauthenticated DEK (Z) Solid Red & Green LEDs  (Zeroize) to its original factory DRBG Internal DRBG Internal Solid Red which fades to off state State State (Z) This service zeroizes CO Salt (Z) the module User Salt (Z) This document may be freely reproduced and distributed only in its entirety and without modification.

Name Description Approved Keys and / or Role Access Rights to Indicator Security SSPs Keys and / or Functions SSPs Lock Private Partition Logout service that None DEK CO / User DEK (Z) Solid Red LED  Fades to (Logout) locks the drive’s off storage partition Read / Write Private Par- Encrypts and writes AES DEK CO / User DEK (E) Blue LED flashes continutition Data inbound data or (Cert. #3749) ously reads and decrypts outbound data Run Self-tests Runs the modules None None Unauthenticated None Refer to Table 16 and Table Pre-operational and 17 for indicator values Conditional self-tests Set CO Password Sets the CO AES CO KEK CO CO KEK (G, E) - Solid Red LED  Solid Password (Cert. #3757) DEK CO IV Key (G, E) Green LED (Success) DRBG - Solid Green LED (Error) (Cert. #1032) DRBG Internal CO Salt (G, E) HMAC State DEK (Z) (Cert. #2459) DRBG State (G, E, PBKDF Z) (Cert. #A777) SHS (Cert. #3127) Set User Password Sets the User AES User KEK CO User KEK (G, E) - Solid Red LED  Solid Password (Cert. #3757) DEK (E) User IV Key (G, E) Green LED (Success) DRBG - Solid Green LED (Error) (Cert. #1032) DRBG State User Salt (G, E) HMAC DEK (Z) (Cert. #2459) DRBG State (G, E, PBKDF Z) (Cert. #A777) SHS (Cert. #3127) Show Module Version Requests the None None CO / User None LEDs all flash on momentarily modules identifier followed by red LED blinking and version out major version number information and then green LED blinking out minor version number This document may be freely reproduced and distributed only in its entirety and without modification.

Name Description Approved Keys and / or Role Access Rights to Indicator Security SSPs Keys and / or Functions SSPs Show Status Returns roles None None Unauthenticated None - Red LED blinks configured on the continuously for 10 seconds module (shows only the CO role exists) - Red & Blue LED blink continuously for 10 seconds (shows both CO & User have been defined) Unlock Private Partition CO / User login AES CO KEK CO / User CO/User KEK (G, - Solid Red LED  Solid (Login) service that unlocks (Cert. #3757) DEK E, Z) Green LED (Success) the drive’s storage DRBG CO/User IV Key - Solid Red LED  Fades to partition. (Cert. #1032) (G, E, Z) off (Error) HMAC (Cert. #2459) CO/User Salt (E) PBKDF (Cert. #A777) SHS (Cert. #3127) View Last Error Requests last known None None CO / User None Refer to Table 19 for indicator error values

The module does not support any non-approved services.

The module does not support external software / firmware loading. This document may be freely reproduced and distributed only in its entirety and without modification.

This module firmware is non-modifiable and as such, does not support firmware upgrades. When powered-on, components within the module perform a firmware integrity check. Failure of any firmware integrity check puts the module into an error state which is signaled by the LED status indicators not illuminating.

A firmware integrity check may be performed by powering the module off and then on.

The module is built upon a custom operational environment that is non-modifiable.

The multi-chip standalone cryptographic module includes the following physical security mechanisms, conforming to FIPS 140-3 Level 3 requirements:

1. Production grade components.
2. Hard, opaque, tamper-evident enclosure with embedded, hard epoxy covering all security relevant components.
3. Memory protection enabled to prevent read-out of firmware, RAM, or NVRAM.

The cryptographic boundary for the module is the aluminum case as shown in Figure 1. On each use, the user should check the module for physical damage, cracks, scratches, or other evidence of tampering such as the integrity of the end cap. While holding the body of the module, a firm tug on the lanyard should not show movement of the end cap or the body. This document may be freely reproduced and distributed only in its entirety and without modification.

This module does not implement explicit environmental failure protection mechanisms (EFP). The module conforms to the FIPS 140-3 environmental failure testing (EFT) requirements. Table 13: EFP/EFT Temperature / Voltage EFP / EFT Shutdown, Zeroization, Undefined Failure, Known Measurement Error Sate or Continues to Operate Normally 13 Low -100°C EFT Continues to Operate Normally Temperature High 145°C Undefined Failure EFT Temperature Low Voltage 2.5V EFT Shutdown High 10.1V Undefined Failure EFT Voltage

The module supports and has been tested at the operation, storage and distribution temperatures listed in Table 14. The module’s epoxy and outer enclosure hardness are assured within these ranges. Table 14: Hardness Testing Temperature Ranges Hardness Tested Temperature Measurement Low Temperature -20°C High Temperature 60°C

The module does not provide protections against non-invasive security methods.

The module incorporates Critical Security Parameters (CSPs) in the form of secret keys and passwords. The module does not utilize Public Security Parameters (PSPs) e.g. public keys.

The module is a data storage device designed to encrypt and store arbitrary data using AES-XTS within its eMMC memory components. The module physically and logically protects CSPs when they are present within the module. Please refer to Table 15 for additional information.

13 For EFP, states can be Shutdown or Zeroise; for EFT, states can be Shutdown, Zeroization, Undefined Failure, Known Error Sate or

Continues to Operate Normally. This document may be freely reproduced and distributed only in its entirety and without modification.

Passwords are input into the module by the operator via the module’s dedicated keypad. These are the only SSPs entered into the module. The operator’s KEK is derived from the associated password using PBKDFv2 14. (Note, the KEK is used as part of the module's data storage application only). The DEK is stored encrypted with AES CTR. The module does not output or establish SSPs using key agreement or key transport methods.

Zeroization is the erasure of CSPs from volatile and non-volatile storage. The module initiates an erase cycle to zeroize SSPs stored in NVRAM. Copies of SSPs in RAM are zeroized by setting the memory locations to zeros. This process occurs when the module is factory reset or when the module detects a brute-force attack. There are two kinds of brute-force attacks. Ten consecutive failed attempts to unlock the module as the User is the first type of brute-force attack and will zeroize the User CSPs. After this type of attack, the CO will be able to unlock the module, recover user data, and permit the setup of a new User Password. However, if there is no CO Password, the user data partition will be permanently unrecoverable, leaving the module in the factory reset and blank state with an empty user data partition. The second kind of brute-force attack is against the CO Password. Ten consecutive failed attempts to unlock the module as CO will zeroize all SSPs for both the CO and User roles, including the DEK. The module will be left in the factory reset and blank state with an empty user data partition.

A Factory Reset will zeroize all SSPs, settings, and user data from the module. After this operation, the operator must reinitialize the module per Section 11.1 before data may be written to the user data partition. Starting with the module disconnected from the USB port,

1. Press and hold the 7 button. Press and release the KEY button. Release the 7 button. The red and green LEDs will alternate. If the LEDs do not illuminate, connect the module to a USB power source and charge the battery for at least one minute. Disconnect the module from USB and restart this procedure.
2. Enter the sequence 999. The red and green LEDs will continue to alternate.
3. Press and hold the 7 button. Press and release the KEY button. Release the 7 button. If the procedure is correctly performed, the red and green LEDs will illuminate together while the module zeroizes.
4. On completion, the LEDs turn off.

14 Per FIPS SP800-132 and FIPS140IG § D.6, the materials derived from PBKDFv2 are used only for “protection of electronically stored

data or for the protection of data protection keys.” This document may be freely reproduced and distributed only in its entirety and without modification.

Table 15: Sensitive Security Parameters Key / CSP Strength Security Generation Import/Export Establishment Storage Zeroization Use & Related Keys Name Function & Cert. Number DRBG 256 bits CTR-DRBG Internally: Input: N/A N/A Plaintext in Zeroized on module lock, Internal state of the Internal (Cert. #1032) from DRBG Output: N/A RAM (Static) connect, after generation DRBG State of CSPs, power-off, and (V and Key) zeroization service Entropy 256-bits ENT (P) Internally: Input: N/A N/A Plaintext in Zeroized immediately after DRBG seed material Input from Entropy Output: N/A RAM use Source (Dynamic) User 8-15 chars N/A N/A Input: Manual / N/A Plaintext Zeroized immediately after Used to authenticate Password Direct Entry temporarily in use the User and derive the Output: N/A RAM User’s KEK and IV Key (Dynamic) CO 8-15 chars N/A N/A Input: Manual / N/A Plaintext Zeroized immediately after Used to authenticate Password Direct Entry temporarily in use the CO and derive the Output: N/A RAM CO’s KEK and IV Key (Dynamic) DEK 256 bits AES-XTS CTR-DRBG Input: N/A N/A Encrypted by Zeroized on module lock, Data encryption and (AES Cert. #3749) Output: N/A KEK timeout, power-off, and decryption using AES(Dynamic) zeroization service XTS User KEK 128 bits AES CTR N/A Input: N/A Derived from Plaintext Zeroized immediately after Encryption/Decryption (Cert. #3757) Output: N/A User Password temporarily in use of the DEK and Salt using RAM PBKDFv2 (Dynamic) CO KEK 128 bits AES CTR N/A Input: N/A Derived from CO Plaintext Zeroized immediately after Encryption/Decryption (Cert. #3757) Output: N/A Password and temporarily in use of the DEK Salt using RAM PBKDFv2 (Dynamic) User Salt 128 bits PBKDF CTR-DRBG Input: N/A N/A Plaintext in Zeroized on zeroization Used with User (Cert. #A777) Output: N/A RAM (Static) service (Factory Reset) password to create User KEK and User Key This document may be freely reproduced and distributed only in its entirety and without modification.

CO Salt 128 bits PBKDF CTR-DRBG Input: N/A N/A Plaintext in Zeroized on zeroization Used with User (Cert. #A777) Output: N/A RAM (Static) service (Factory Reset) password to create CO KEK and CO Key User IV Key 128 bits AES CMAC N/A Input: N/A Derived from Plaintext in Zeroized immediately after Used to authenticate (Cert. #3757) Output: N/A User Password RAM (Static) use the User and Salt using PBKDFv2 CO IV Key 128 bits AES CMAC N/A Input: N/A Derived from CO Plaintext in Zeroized immediately after Used to authenticate (Cert. #3757) Output: N/A Password and RAM (Static) use the CO Salt using PBKDFv2 This document may be freely reproduced and distributed only in its entirety and without modification.

When the module powers on, it performs a sequence of self-tests. If any of these tests fail, the drive will enter an error state. The module will not perform any cryptographic services and will output no user data in the error state. The module also performs continuous self-tests. The only way to clear a module error state is to cycle the power.

When the module fails a pre-operational self-test, it enters the error state described in Table 16 and Table 18 below. Clearing this error state requires that the module be power cycled. Table 16: Per-Operational Self-Tests Algorithm Test Test Method Type Indicator Details Properties CRC-32 CRC-32 Cyclic CRC-32 Redundancy Success: All three LEDs A CRC is an error detection Check blink once simultaneously code (EDC) that is calculated over the firmware binary and CRC-16 CRC-16 Cyclic CRC-16 Error: LED will not illuminate; verified as part of the firmware Redundancy the module shuts down integrity tests Check

When the module fails a conditional self-test, it enters an error state described in Table 17 and Table 18. Clearing this error state requires that the module be power cycled. Table 17: Conditional Self-Tests Algorithm Test Properties Test Indicator Details Condition Method AES ECB 128-bit Key KAT Success: All three LEDs blink once simul- Encrypt KAT Power-on Cert. #3757 taneously Error: LEDs illuminate two times in circling pattern, red then green then blue

• Red LED illuminates. AES ECB 128-bit Key KAT Success: All three LEDs blink once simul- Decrypt KAT Power-on Cert. #3757 taneously Error: LEDs illuminate two times in circling pattern, red then green then blue
• Red LED illuminates. AES CMAC 128-bit Key KAT Success: All three LEDs blink once simul- Generation KAT Power-on Cert. #3757 taneously Error: LEDs illuminate two times in circling pattern, red then green then blue
• Red LED illuminates. This document may be freely reproduced and distributed only in its entirety and without modification.

Algorithm Test Properties Test Indicator Details Condition Method AES XTS 256-bit Key KAT Success: All three LEDs blink once simul- Encrypt KAT Power-on Cert. #3749 taneously Error: Illuminates red LED AES-XTS 256-bit Key KAT Success: All three LEDs blink once simul- Decrypt KAT Power-on Cert. #3749 taneously Error: Illuminates red LED CTR-DRBG 384-bit KAT Success: All three LEDs blink once simul- Instantiate and Power-on Cert. #1032 taneously Generate KAT Error: LEDs illuminate two times in circling pattern, red then green then blue

• Red LED illuminates. PBKDFv2 Password KAT Success: All three LEDs blink once simul- PBKDF KAT using Power-on Cert. (8 chars) taneously known password #A777 Error: LEDs illuminate two times in circling pattern, red then green then blue
• Red LED illuminates. Entropy N/A APT/RCT Success: All three LEDs blink once simul- Adaptive Proportion Continuous Source taneously Test and Repetition Error: LEDs illuminate two times in circling Count Test perpattern, red then green then blue
• Red formed on the enLED illuminates. tropy source AES-XTS XTS Key Validity: N/A Error: Illuminates red LED Per IG C.I after Creation of DEK Key Gener- Key #1 ≠ Key #2 AES-XTS key genation eration test to ensure keys are unique: Key #1 ≠ Key #2 Password N/A Manual Success: When setting passwords, the Requires Setting CO or User Integrity Key Entry module will illuminate its red LED for a few passwords to be Password seconds entered twice Any other indication means the password do not match

The module authentication component performs periodic self-tests each time it powers on and prior to authentication by the operator. Once authenticated, the authentication component enters a low-power state. It may be awakened to rerun the self-tests by disconnecting the module from USB and then powering the module on by pressing the KEY button. The module data encryption component performs periodic self-tests while the module is connected and mounted to a host computer. These tests are executed automatically every 15 minutes. This document may be freely reproduced and distributed only in its entirety and without modification.

Table 18: Error States State Name Description Conditions Recovery Mode Indicator Hard Error Hard Error State Transitions to this Power-Cycle Illuminates Red LED state for all errors To verify that the module is in good working order, power it on by connecting it to a USB power source. The three status indicator LEDs will blink simultaneously, indicating that firmware integrity tests and KATs have passed successfully. When using the View Last Error service, the module will report the error as a sequence of LED blinks. The following table summarizes the LED patterns that the module emits for each logged error. Table 19: Logged Error Codes Logged Error Code LED Pattern None 0 Green Entropy Health Failure 1 Red DRBG Failure 2 Red Green Credential Storage Failure 3 Red Red Encryption Component Health Failure 4 Red Green Green

The operator may initiate all self-tests (pre-operational and conditional cryptographic algorithm selftests) at any time by powering on the module (either by inserting the module into a USB port or by pressing the KEY button once).

Power-up self-tests are run based on user action. For a module that is unlocked and in-use for an extended period of time, the user is encouraged to disconnect and reconnect the module to re-run selftests.

After a module is assembled in the factory, production release firmware is programmed into the electronics, the circuit board is coated with epoxy, and the module is sealed with an epoxy adhesive. The factory configures the module with a DEK, loads product documentation into the secure, encrypted data partition, and then prepares the module for first use by the user. There is no default Password set at the factory. On first use, the user must create either a User or a CO Password. Subsequently, data on the encrypted partition may be read, modified, or deleted. This document may be freely reproduced and distributed only in its entirety and without modification.

A new module comes from the factory preloaded with product documentation and with a DEK defined. No Password is set when the module leaves the factory. Before the first use and before the secure encrypted data partition can be accessed, a User or CO Password must be set. After this is done, the module is ready for operation.

Before the first use a CO Password (8

• 15 characters) must be set (this password should not be disclosed). After this is done, the module is ready for operation. Press the KEY button once, then press the KEY button twice. Enter the CO password and press the KEY button twice. Enter the CO password again and press the KEY button twice. The module’s administrator’s guide is shipped with the module. An operator may choose to Factory Reset the module before first use if the provenance of the module is unknown or suspect. Performing a Factory Reset will guarantee that the encrypted data partition is blank and unformatted on first use and that a new DEK is generated when the first Password is set. If the module is zeroized, it will become blank in the same way that a Factory Reset causes the module to be made blank. There will be no DEK defined, it will have neither a User Password nor a CO Password defined, and on first use the encrypted data partition must be formatted.

The CO may choose to configure the module for dual roles i.e. CO and User. In such instances, a User password must be established and set by the CO.

To meet the requirements for FIPS 140-3 Security Level 3, the module enforces the following security rules:

• The cryptographic module provides two distinct operator roles: User and Cryptographic Officer (CO).
• The cryptographic module provides identity-based authentication.
• Upon removing power from the module, the authentication session is cleared.
• When the module has not been placed in a valid role or is in an error state, the operator shall not have access to any cryptographic service.
• Passwords must not be disclosed.
• The operator can command the module to perform self-tests at any time by cycling the power.
• All data output is inhibited during pre-operational and conditional self-tests, zeroization, key generation, and authentication.
• The module is an encrypted storage drive that utilizes PBKDFv2 (NIST SP 800-132) and AESXTS (FIPS 197 and NIST SP 800-38e). These algorithms can only be used for the protection of data at rest. This document may be freely reproduced and distributed only in its entirety and without modification.

The module is not designed to mitigate other attacks beyond the scope of FIPS 140-3 requirements. This document may be freely reproduced and distributed only in its entirety and without modification.

Term Definition AES Advanced Encryption Standard CO Cryptographic Officer CRC Cyclic Redundancy Check CSP Critical Security Parameter CTR-DRBG Counter-Mode Deterministic Random Byte Generator DEK Data Encryption Key DRBG Deterministic Random Byte Generator ECB Electronic Code Book EFP Environmental Failure Protection EFT Environmental Failure Testing EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standards GPC General Purpose Computer HMAC Keyed-Hash Message Authentication Code KAT Known Answer Test KEK Key Encryption Key LED Light Emitting Diode NIST National Institute of Standards and Technology NVRAM Non-volatile Random Access Memory PBKDFv2 Password Based Key Derivation Algorithm Version 2 PSP Public Security Parameter RAM Random Access Memory Salt Random value used to improve security of cryptographic algorithms SHA-1 Secure Hash Algorithm 1 SHS Secure Hash Standard SSP Sensitive Security Parameter TOEPP Tested Operating Environment Physical Perimeter USB Universal Serial Bus XTS-AES AES cipher mode used to encrypt user data in mass storage Zeroization The process of erasing cryptographic security keys and parameters ⩫ This document may be freely reproduced and distributed only in its entirety and without modification.