IronKey D500S Series USB Flash Drive

Certificate

Approved Algorithms (13)

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

flowchart LR
  %% Deterministic review-risk graph for IronKey D500S Series USB Flash 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>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Self-test</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 D500S Series USB Flash 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>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Self-test</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 D500S Series USB Flash Drive Document Version 1.0 This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

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

TABLE OF TABLES This document may be freely reproduced and distributed, but only in its entirety and without modification.

The Kingston Technology Company, Inc. (Kingston) IronKey D500S Series USB Flash Drive is a hardware cryptographic module designed to meet the overall requirements of FIPS 140-3 Security

The Kingston IronKey D500S Series USB Flash Drive (refer to Figure 1) is a hardware cryptographic module designed for organizations that require a secure way to store and transfer portable data. The stored data is secured by hardware‐based 256‐bit AES on‐the‐fly encryption to guard sensitive information in case the drive is lost or stolen. Its strong, durable, metal casing provides robust physical protection. Its strong password rules and lock‐down control protect against brute force attacks. Such advanced security features make the IronKey D500S Series USB Flash Drive ideal for corporations and service organizations that require employees to transport large digital files consisting of confidential documents. This document may be freely reproduced and distributed, but 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). Figure 1 – Cryptographic Boundary

2.2 T ESTED AND V ENDOR A FFIRMED M ODULE V ERSION AND I DENTIFICATION

The IronKey D500S Series USB Flash Drive is a FIPS 140-3 Security Level 3 (refer to Table 1) multi‐ chip standalone cryptographic module (module) available in the following configurations: − IKD500S/xGB − IKD500SM/xGB x = 8, 16, 32, 64, 128, 256 and 512 (denotes module’s memory capacity)

The module’s operating environment is defined as the non-modifiable, Kingston PS2251-15 USB AES Micro-Controller. The FIPS 140-3 Security Level 3 validated versioning information is shown in Table 2. The hardware versions differ by memory capacity e.g., 16GB, 32GB, etc. The Kingston IronKey D500S Series USB Flash Drive is marketed as IronKey D500S or IronKey D500SM. There is no physical or logical difference between these two branded products. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 2 – Tested Module Identification - Hardware

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

The module supports a single approved mode of operation that is entered by powering-on the module. There are no non-approved modes, degraded modes or non-approved services available to the module. The module’s firmware provides an indicator (i.e., “FIPS ACTIVE”) showing the approved configuration which can be queried. This global indicator will be used along with the successful return codes of each service to indicate the module has provided an approved security service. If the module reports “FIPS DEFAULT”, the module is awaiting a new password (CO Password) to be set. The module is always running in an approved mode when module reports either “FIPS DEFAULT” or “FIPS ACTIVE”. The approved mode cannot be exited. The module does not support a non-approved or degraded mode of operation. In case of critical error, the module will remain in an error state, until reset. While in its error state, the LED will blink rapidly until it is reset. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module supports the following approved cryptographic algorithms. Table 3 – Approved Algorithms

1 AES XTS was designed for the cryptographic protection of data on storage devices per NIST SP 800-38E. It

was not designed for other purposes, such as the encryption of data in transit.

2 The module implements PBKDF in conformance with NIST SP 800132 and FIPS IG D.N. Specifically, the

module implements Option 2a from Section 5.4 to generate the Key Encryption Key (KEK) responsible for protecting the Data Encryption Key using AES KW (Cert. #3268). The module implements an iteration counter equal to 1024 bits which is greater than the minimum recommendation documented within NIST SP 800-132 - Section 5.2. This is also justified by the maximum limit enforced on password retry attempts (Max = 10). This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module supports the following vendor affirmed algorithms. Table 4 - Vendor Affirmed Algorithms

The module does not support non-approved algorithms. Table 5 – Non-Approved, Allowed Algorithms N/A N/A N/A N/A

2.5.4 N ON -A PPROVED , A LLOWED A LGORITHMS WITH N O S ECURITY C LAIMED

The module does not support non-approved algorithms. Table 6 – Non-Approved, Allowed Algorithms with No Security Claimed N/A N/A N/A

The module does not support non-approved algorithms. Table 7 – Non-Approved, Not Allowed Algorithms N/A N/A This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 8 - Security Function Implementations (SFI)

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

The module includes an internal entropy source for the generation of the DRBG seed. Please refer to Table 9 - Non-Deterministic Random Number Generation Specification

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

The module supports a NIST SP 800-56Ar3 conforming key agreement scheme for the establishment of AES 256 and HMAC-SHA2-256 keys to secure communication to / from the This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module relies upon the standard USB protocol for communication with general purpose computer (GPC) systems. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module incorporates both physical and logical interfaces as described within Table 10. Table 10 - Ports and Interfaces

The module does not support a Trusted Channel. 4. ROLES, SERVICES, AND AUTHENTICATION

The module supports identity-based authentication in the form of a User ID and Password (Memorized Secret) in conformance with NIST SP 800-140E and SP 800-63B (refer to Section 5.1.1).

Per NIST SP 800-63B – Section 5.1.1, passwords must be a minimum of 8 bytes (enforced by the module). The password must contain three of the following four-character types: lowercase letters, uppercase letters, numeric characters and/or special characters. This greatly increases the passwords entropy. Assuming a mix of lowercase letters, uppercase letters, numeric characters, the This document may be freely reproduced and distributed, but only in its entirety and without modification.

(10 * 26 * 26 * 955) ~= 1/245, which is less than 1/1,000,000. The module only allows for ten (10) Table 11 – Authentication Methods

Table 12 lists the roles supported by the module with the respective services supported by that Table 12 – Roles, Service Commands, Input and Output This document may be freely reproduced and distributed, but only in its entirety and without modification.

The operator must perform that following initialization procedures to access the module for the first time.

1. Connect the IronKey D500S Series USB Flash Drive to a GPC. The module will enumerate onto the GPC and register its CD ROM partition. Locate and run the application located on the CDROM partition.
2. Follow the instructions presented by the application to ‘Initialize’ the module. Initialize the CO authentication by establishing a password and continue to login to the device. Per NIST SP 800-63B – Section 5.1.1 the password must be at least 8 characters. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 13 – Roles and Authentication This document may be freely reproduced and distributed, but only in its entirety and without modification.

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 14
• Approved Services This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

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

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

The module does not support any non-approved services.

The module’s firmware is non-modifiable. It does not have the ability to support the external software / firmware loading.

The module supports the following authenticated roles: • Crypto Officer (CO) • User It enforces the separation of roles using identity-based authentication. The operator must perform that following initialization procedures to access the module for the first time.

1. Connect the IronKey D500S Series USB Flash Drive to a GPC. The module will enumerate onto the GPC and register its CD ROM partition. Locate and run the application located on the CD-ROM partition.
2. Follow the instructions presented by the application to ‘Initialize’ the module. Initialize the CO authentication by establishing a password and continue to login to the device. Per NIST SP 800-63B – Section 5.1.1 the password must be at least 8 characters. Table 13 lists all operator roles supported by module. The module also supports an Unauthenticated role. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module incorporates an RSA 2048 PKCS1 v1.5 (Cert. #A3268) digital signature mechanism over its firmware. The digital signature provides integrity as well as authentication. All commands sent to and from the cryptographic module are protected with HMAC-SHA2-256.

The module loads the firmware image from non-volatile memory to on-chip RAM when powering on the module where it then performs the firmware integrity test using the module’s RSA-2048 ‘Firmware Integrity Public Key’. If the test fails, the module enters an error state, the data output interface is inhibited, and the module’s LED (status output) blinks at 16Hz. The firmware integrity test is a part of Pre-Operational Self-Tests. It is automatically executed at power-on or during the Periodic Self-Tests. It can also be invoked by power-cycling the module. 6. OPERATIONAL ENVIRONMENT

The operational environment is classified as non-modifiable. 7. PHYSICAL SECURITY The module is a multiple-chip standalone module and conforms to FIPS 140-3 Security Level 3 physical security requirements. The module is housed within a strong, non-removable, tamperevident enclosure. The enclosure is opaque within the visible spectrum. In addition, all components are protected with a hard epoxy coating that protects each component from being viewed or probed. Attempts at removing the epoxy will render the module inoperable.

The operator of the module should inspect the outer casing of the module each time prior to connecting the module to a computer. If tamper evidence is observed on the outer casing, the module should not be used. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 15 - Physical Security Inspection Guidelines The module supports the operation, storage and distribution temperatures listed in Table 16. Table 16

• Normal Operation, Storage and Distribution Temperature Ranges The module does not incorporate any environmental protection mechanisms (EFP). The module satisfies environmental failure testing (EFT) requirements. Table 17
• EFP/EFT

The module supports and has been tested at the operation, storage and distribution temperatures listed in Table 16. The module’s epoxy and outer enclosure hardness are assured within these ranges. Table 18 – Hardness Testing Temperature Ranges This document may be freely reproduced and distributed, but only in its entirety and without modification.

8. NON-INVASIVE SECURITY The module does not provide protections against non-invasive security methods.
9. SENSITIVE SECURITY PARAMETERS (SSP) MANAGEMENT The module incorporates both Critical Security Parameters (CSPs) and Public Security Parameters (PSPs).

The module is designed to encrypt and store arbitrary data with XTS-AES within eMMC memory components. The module physically and logically protects static keys and CSPs. Please refer to Table 19 for additional information.

The module inputs CSPs encrypted with AES CBC and authenticated with HMAC-SHA2-256. The module does not output CSPs. PSPs are output in order to authenticate the module to the connected GPC. Please refer to Table 19 for additional information.

During normal operation, the module explicitly erases copies of CSPs in volatile memory (e.g., RAM) by overwriting with zeros after their use. For CSPs stored in non-volatile memory the module initiates its erase operation to zeroize. The following methods are used to zeroize the module’s CSPs during normal operation. − ‘Zeroization’ and ‘Reset Drive’ service: This service overwrites all CSPs with zeroes and returns the module to its factory default state. − After ten failed CO authentication attempts the respective CO and User DEKs are erased. − After ten failed User authentication attempts the respective User DEK is erased. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module incorporates SSPs as defined with Table 19. Table 19 – SSPs This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

4 Per IG 9.6.A

• Additional Comment #6
• “a PSP is considered protected if it cannot be modified or if its modification can be determined by the module.”

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

The module performs pre-operational self-tests and conditional self-tests (refer to Section 10.2). Both self-tests ensure that the module is not corrupted, and the cryptographic algorithms work as expected. During self-tests, data output (via the data output interface) is inhibited. The module services are not available until the self-tests have completed successfully. Table 20 – Pre-Operational Self-Tests For the above error case, the device can be powered cycle to reinitiate the power-up self-tests. Please note: An RSA signature verification known-answer test (KAT) is performed prior to the

Table 21 – Conditional Self-Tests This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module performs all self-tests automatically (with no operator intervention) every 11 minutes after being powered-on.

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

The module supports the following error states: Table 22 – Error States The module transitions into an error state when an error condition is encountered and provides an unambiguous error status indicator (i.e., blinking LED and error code). All data output is inhibited while the module is in the error state.

The operator can initiate the self-tests at any time by power-cycling the module or via the ‘Perform Self-Tests’ command. 11. LIFE-CYCLE ASSURANCE

The User must configure and enforce the following initialization procedures:

1. Connect the IronKey D500S Series USB Flash Drive to a GPC. The module will enumerate onto the GPC and register its CD ROM partition. Locate and run the application located on the CDROM partition.
2. Follow the instructions presented by the application to ‘Initialize’ the module. Setup the new CO password and continue to login to the device.
3. Click on the Kingston icon in the system tray to bring up a pull-up menu and select “About D500S” option (refer to Figure 2). The application will display the firmware and application versions. Verify that the firmware version is 3.06. This is the FIPS validated version of the module. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Upon receipt of the module an operator must follow the initialization procedure outlined in Section 11.1. This establishes the operator as the Cryptographic Officer (CO) with a valid ID and password. The module is designed to securely store authorized user’s data files using physical and logical security methods. A user may transfer files to the device via a compatible PC or similar device. Over the life of the device an operator may: − Initialize the device as a single operator (CO only). − Initialize the device for multiple operators (CO and User). − Transfer files to the device for secure storage. − Reset the device effectively erasing all data and security parameters. Services available to the CO role are listed in Table 12.

The cryptographic officer must establish access for additional operators. Additional operators will be assigned to the User role. An operator under the User role shall authenticate and transfer files to the device via a compatible PC or similar device. Services available to the User role are listed in Table 12.

In the approved mode of operation, the module shall adhere to the following rules:

• The module prohibits operator passwords less than 8 characters.
• The module generates at a minimum 256 bits of entropy for use in key generation (refer to ESV validation #E55).
• The cryptographic module satisfies the requirements of FIPS 140-3 IG C.I for AES-XTS key generation (i.e., key_1 ≠ key_2). This document may be freely reproduced and distributed, but only in its entirety and without modification.

• The cryptographic module does not output CSPs in any form.
• The cryptographic module enters its defined error state upon failure of self-tests, ceasing cryptographic services.
• The approved DRBG is used for generating cryptographic keys.
• The cryptographic module enforces identity-based authentication for security relevant services.
• The operator can invoke the module to perform the Pre-Operational and Conditional selftests on-demand by power-cycling the module.
• The module performs firmware integrity test as part of the Pre-Operational self-tests at power-on, prior to each operator authentication, on demand and automatically after a set period of time.
• The module does not support concurrent operators.
• The module inhibits data output via the data output interface during self-tests, SSP generation, error states and zeroization.
• Modification of PSPs by unauthorized operators is prohibited.
• The module does not support bypass mechanisms.
• The module does not support maintenance role.
• The operator cannot change roles without first exiting from the currently assumed role.
• Cryptographic keys derived from passwords conformant with NIST standard Special Publication (SP) 800-132 - 'Recommendation for Password-Based Key Derivation' (PBKDF) may only be used in storage applications.

Upon the need to decommission the module, the CO should perform a ‘Reset Drive’ operation to securely overwrite all security parameters which makes all stored data unrecoverable. The module can then be repurposed or physically scrapped. 12. MITIGATION OF OTHER ATTACKS This module is not designed to mitigate other attacks beyond the scope of FIPS 140-3 requirements. This document may be freely reproduced and distributed, but only in its entirety and without modification.

13. APPENDIX A: REFERENCES Table 23 – References This document may be freely reproduced and distributed, but only in its entirety and without modification.

14. APPENDIX B: ABBREVIATIONS AND DEFINITIONS Table 24 – Abbreviations and Definitions This document may be freely reproduced and distributed, but only in its entirety and without modification.