| Standard | FIPS 140-3 |
|---|---|
| Overall level | 3 |
| Module type | Hardware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 6/23/2030 |
| Caveat | None |
| Vendor | DataLocker, Inc. |
| Algorithm | ACVP Cert |
|---|---|
| AES-CBC | A3268 |
| AES-ECB | A3268 |
| AES-KW | A3268 |
| AES-XTS Testing Revision 2.0 | A3268 |
| ECDSA KeyGen (FIPS186-5) | A3268 |
| ECDSA KeyVer (FIPS186-4) | A3268 |
| HMAC DRBG | A3268 |
| HMAC-SHA2-256 | A3268 |
| KAS-ECC-SSC Sp800-56Ar3 | A3268 |
| KDA TwoStep SP800-56Cr2 | A3268 |
| PBKDF | A3268 |
| RSA SigVer (FIPS186-4) | A3268 |
| SHA2-256 | A3268 |
flowchart LR
%% Deterministic review-risk graph for Sentry 5 Encrypted 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 Sentry 5 Encrypted 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;DataLocker, Inc. Sentry 5 Encrypted USB Flash Drive Document Version 1.0 This document may be freely reproduced and distributed, but only in its entirety and without modification.
| # | Section | Page |
|---|
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 DataLocker, Inc. (DataLocker) Sentry 5 Encrypted USB Flash Drive is a hardware cryptographic module designed to meet the overall requirements of FIPS 140-3 Security Level 3.
Table 1
Overall Level: 3 2. CRYPTOGRAPHIC MODULE SPECIFICATION
The DataLocker Sentry 5 Encrypted 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 Sentry 5 Encrypted 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
The Sentry 5 Encrypted 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: − S5-xxx-FE-M x = 008, 016, 032, 064, 128, 256, or 512 (denotes module’s memory capacity in GB)
The module’s operating environment is defined as the non-modifiable, PS2251-15 USB AES MicroController. 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. Table 2
Model/Part Hardware Version(s) Firmware Processor(s) Non-Security Relevant Number(s) Version(s) Distinguishing Features S5-128-FE-M 128GB of user data storage S5-256-FE-M 256GB of user data storage S5-512-FE-M 512GB of user data storage
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
256 Strength: 256 bits Message Authentication
A3268 HMAC DRBG NIST SP 800-90A HMAC-SHA2-256 Security strength: Deterministic Random
A3268 KAS-ECC-SSC NIST SP 800-56Ar3 ECC CDH Curve: P-256 Key Agreement Shared C(2e, 0s) Strength: 128 bits Secret calculation A3268 KDA NIST SP 800-56Cr2 Two-Step KDF Derived Key Length: 256 Key derivation as part of (HMAC-SHA2-256) bits KAS Shared Secret Length: 256 bits A3268 PBKDF 2 NIST SP 800-132 HMAC-SHA2-256 Password length: 8 to 136 Deriving KEK_CO, (option 2A) bytes (refer to Section 4.1) KEK_U, KEK_R Salt Length: 256-bit A3268 RSA SigVer FIPS 186-4 Digital Signature Modulo: 2048 Digital Signature (PKCS1 v1.5) Verification Strength: 128 bits Verification
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.
CAVP Algorithm Standards Modes/ Methods Description / Key Sizes, Use/Function Cert(s) Curves, or Moduli / Key Strengths A3268 SHA2-256 FIPS 180-4 SHA2-256 Strength: 128 bits Prerequisite for HMAC Message Digest
The module supports the following vendor affirmed algorithms. Table 4 - Vendor Affirmed Algorithms Algorithm Name Algorithm Properties Implementation Reference CKG Key Type: Symmetric Crypto Library FW v2.00 NIST SP 800-133r2 Sections 4
The module does not support non-approved algorithms. Table 5
The module does not support non-approved algorithms. Table 6
The module does not support non-approved algorithms. Table 7
Table 8 - Security Function Implementations (SFI) Name Type Description SF Properties Algorithms / CAVP Cert KAS KAS-Full NIST SP 800-56Arev3 Standards: NIST SP KAS-ECC-SSC: (A3268) per IG D.F Scenario 2 800-56Arev3, NIST path (2) SP 800-56Crev2, KDA: (A3268) FIPS 186-4 ECDSA KeyVer: (A3268) KTS KTS-Unwrap Key unwrapping per Standards: FIPS 197, AES-CBC: (A3268) NIST SP 800-38F Per FIPS 198-1, NIST SP IG D.G. Used for the 800-38A HMAC-SHA2-256: (A3268) entry of the operator’s password.
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 the Entropy Source Validation (ESV) certificate #E55. Table 9 - Non-Deterministic Random Number Generation Specification Minimum Number of Entropy Sources Details Bits of Entropy Kingston Technology Company, Inc. The ESV source outputs Based on the heuristic Crypto Library FW v2.00 1024 bits with a lower bound entropy minimum of 256 bits of estimate, the entropy ESV Validation #E55 entropy source has a rate of 1-bit per nibble or 25%. This means the entropy input required for the DRBG is 1024*0.25 = 256 bits.
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 module. In addition, the module supports KTS using AES CBC with HMAC-SHA2-256 in conformance with NIST SP 800-38F and IG D.G. 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 Physical Port Logical Interface Data that Passes over Port/Interface USB Port (Rx / Tx) Data Input The USB 3.0 port connects the module to the host computer. It is used to receive user data as well as API calls issued by the host via the USB protocol. The input is received by the module on the Rx line. Data Output The USB 3.0 port connects the module to the host computer. It is used to send user data as well as return codes upon completion of API calls issued by the host via the USB protocol. The input is received by the module on the Tx line. Control Input The USB 3.0 port connects the module to the host computer. It is used to receive commands as well as API calls issued by the host via the USB protocol. The input is received by the module on the Rx line. Status Output Error codes and other statuses are transmitted from the module to the host computer. LED Status Output Error codes and other statuses are transmitted by the LED: − Active data transfer with host computer: LED blinks at 3Hz − Error state: LED blinks rapidly at 16Hz − Pre-operational Self-test status output: LED blinks at 3Hz if all selftests completed, LED blinks at 16Hz if failed − Continuous Self-test status output: LED blinks at 16Hz if failed − Periodic Self-test status output: LED blinks at 16Hz if failed USB Port (VCC) Power The USB VBUS (+5VDC) powers the module.
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
password can consist of the following set: uppercase letters, lowercase letters, numbers, and special characters, yielding 95 choices per character. The probability of a successful random attempt is 1/ (10 * 26 * 26 * 955) ~= 1/245, which is less than 1/1,000,000. The module only allows for ten (10) unsuccessful authentication attempts. Therefore, the probability of success with multiple attempts in a one-minute period is 10/245, which is less than 1/100,000. Table 11
Table 12 lists the roles supported by the module with the respective services supported by that role. Table 12
Role Service Input Output Setup Recovery Current CO Password and Status Out (success, session Password new Recovery Password invalid, wrong password) LED blinks at 16Hz if fatal error User Change User Password Current User Password Status Out (success, session and new User Password invalid, wrong password) LED blinks at 16Hz if fatal error Close Partition (Logout) N/A Status Out (success, session invalid, partition has been closed) LED blinks at 16Hz if fatal error Decrypt Disk accessing Read partition data Encrypt Disk accessing Write partition data Open Partition (Login) User ID & Password, and Status Out (success, session the selected partition invalid, partition has been opened, wrong password) LED blinks at 16Hz if fatal error, the partition is opened if success Setup User Password Recovery Password and Status Out (success, session (Using Recovery new User Password invalid, wrong password, Password) recovery password not created) LED blinks at 16Hz if fatal error Unauthenticated CD Update API call with CD Image, Status Out (success, session Signature invalid, signature verification failed) Perform Self-Tests Power-on the module LED blinks at 3Hz if all tests complete LED blinks at 16Hz if failed Reset Drive N/A Status Out (success, session invalid) Internally zeroize all CSPs except the session keys and generate DEK_CO and configure to the single partition. LED blinks at 16Hz if fatal error Show Module Version N/A Returns module ID and version information, in addition to the approved mode indicator to API call. Show Error Status N/A Returns the error log to API call Show Status N/A Reply the service status, the disk status, or the session establishment status to API call Zeroization N/A Status Out (success) Internally zeroize all CSPs. LED blinks at 16Hz if fatal error The operator must perform that following initialization procedures to access the module for the first time.
Table 13
mechanism. The 1/100,000 < 1/1,000,000 password must be at least 8 characters long and must contain at least one integer, one lowercase letter, and one upper-case letter. User ID & Password The upper bound for the The probability of the combination used probability of having the consecutive failed authentication within a password guessed at random is: attempts in one minute period is challenge/response approximately 10/ 245 <
mechanism. The 1/100,000 < 1/1,000,000 password must be at least 8 characters long and must contain at least one integer, one lowercase letter, and one upper-case letter. This document may be freely reproduced and distributed, but only in its entirety and without modification.
SSP access rights are defined as follows:
Service Description Approved Security Keys & SSPs Roles Access Rights to Keys and / or Indicator Functions SSPs Change User Create new User DRBG, PBKDF, SHA2- KEK_U User KEK_U: G, E, Z Return status via the API: Password Password 256 User Password, User Password: E, Z 0x0000: success User Password Hash, User Password Hash: Z, G 0x8102: configuration DRBG Internal State DRBG Internal State: G, E invalid Close Partition Logout. Locks drive N/A DEK_CO or DEK_U CO DEK_CO: Z Return status via the API: (Logout) AES Session Key: Z 0x0000: success MAC Session Key: Z 0x1602: session invalid User DEK_U: Z 0x1604: partition has been closed AES Session Key: Z MAC Session Key: Z Decrypt Read partition data AES-XTS DEK_CO or DEK_U CO DEK_CO: E Return status via the API: User DEK_U: E 0x0000: success Encrypt Write partition data AES-XTS DEK_CO or DEK_U CO DEK_CO: E Return status via the API: User DEK_U: E 0x0000: success Initialize Create CO password DRBG, PBKDF, SHA2- DEK_CO, CO DEK_CO: Z, G Return status via the API: and generate DEK 256, AES-KW KEK_CO, KEK_CO: G, E, Z 0x0000: success CO Password, CO Password: W, E, Z 0x8102: configuration CO Password Hash, CO Password Hash: G Entropy Input, Entropy Input: G, E invalid DRBG Nonce, DRBG Nonce: G, E DRBG Internal State DRBG Internal State: G, E Open Partition Authenticates either PBKDF, SHA2-256, CO Password CO CO Password: W, E, Z Return status via the API: (Login) the CO or User to the AES-KW KEK_CO & DEK_CO KEK_CO: G, E, Z 0x0000: success module DEK_CO: E or 0x1402: session invalid User User Password: W, E, Z 0x1404: partition has been User Password, KEK_U: G, E, Z opened KEK_U & DEK_U DEK_U: E 0x1406: wrong password Perform Self- Perform Pre- N/A N/A Unauthenticated DRBG Internal State: G, E LED Flashing Tests Operational and Conditional Self-Tests This document may be freely reproduced and distributed, but only in its entirety and without modification.
Service Description Approved Security Keys & SSPs Roles Access Rights to Keys and / or Indicator Functions SSPs Reset Drive Erase all files stored N/A DEK_CO, DEK_U, Unauthenticated DEK_CO: Z Return status via the API: on the module and CO Password Hash, DEK_U: Z 0x0000: success zeroizes all CSPs User Password Hash, CO Password Hash: Z 0x8101: session invalid Recovery Password User Password Hash: Z Hash, DRBG Internal Recovery Password Hash: Z State DRBG Internal State: Z Setup User Create new User DRBG, PBKDF, SHA2- DEK_U, KEK_U, CO DEK_U: G, Z Return status via the API: Password password 256 User Password, User KEK_U: G, E, Z 0x0000: success Password Hash, User Password: W, E, Z 0x8102: configuration DRBG Internal State User Password Hash: G invalid DRBG Internal State: G, E Setup User Create new User DRBG, PBKDF, SHA2- KEK_R, KEK_U User KEK_U: G, E, Z Return status via the API: Password Password 256 Recovery Password, KEK_R: G, E, Z 0x0000: success (Using Recovery Recovery Password Recovery Password: E, Z 0x8102: configuration Password) Hash, Recovery Password Hash: Z invalid User Password, User Password: W, E, Z User Password Hash, User Password Hash: G DRBG Internal State DRBG Internal State: G, E Setup Recovery Create Recovery DRBG, PBKDF, SHA2- KEK_R, CO KEK_R: G, E, Z Return status via the API: Password password 256 Recovery Password, Recovery Password: W, E, Z 0x0000: success Recovery Password Recovery Password Hash: G 0x8102: configuration Hash, DRBG Internal State: G, E invalid DRBG Internal State Show Module Get module ID and N/A N/A Unauthenticated N/A Return status via the API: Version version 0x0000: success Show Error Returns the most N/A N/A Unauthenticated N/A Return status via the API: Status recent error details 0x0000: success Show Status Get the module’s N/A N/A Unauthenticated N/A Return status via the API: status 0x0000: success This document may be freely reproduced and distributed, but only in its entirety and without modification.
Service Description Approved Security Keys & SSPs Roles Access Rights to Keys and / or Indicator Functions SSPs Zeroization Zeroize all keys and N/A N/A Unauthenticated DEK_CO: Z Return status via the API: CSPs DEK_U: Z 0x0000: success CO Password Hash: Z User Password Hash: Z Recovery Password Hash: Z DRBG Internal State: Z AES Session Key: Z MAC Session Key: Z 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.
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 Physical Security Recommended Frequency of Inspection/Test Guidance Details Mechanism Inspection / Test Upon each use of the module the operator should Tamper Evidence Each time the module is used examine the module for evidence of tamper. The module supports the operation, storage and distribution temperatures listed in Table 16. Table 16
The module does not incorporate any environmental protection mechanisms (EFP). The module satisfies environmental failure testing (EFT) requirements. Table 17
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
3 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, but only in its entirety and without modification.
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
Key/CSP Name Strength Security Function Generation Import / Establishment Storage Zeroization Use & related SSPs & Cert. Number Export Crypto Officer Password 8 ~ 136 PBKDF Created by Entry: AES N/A RAM Overwritten Used to generate the bytes (Cert. #A3268) Crypto Encrypted (Plaintext) with zeros KEK_CO (refer to Officer entry via host immediately Section application after use 4.1) Output: N/A User Password 8 ~ 136 PBKDF Created by Entry: AES N/A RAM Overwritten Used to generate the bytes (Cert. #A3268) User Encrypted (Plaintext) with zeros KEK_U (refer to entry via host immediately Section application after use 4.1) Output: N/A Recovery Password 8 ~ 136 PBKDF Created by Entry: AES N/A RAM Overwritten User to generate the bytes (Cert. #A3268) Crypto Encrypted (Plaintext) with zeros KEK_R (refer to Officer entry via host immediately Section application after use 4.1) Output: N/A Crypto Officer Password Hash 128-bits SHA2-256 Generated Entry: N/A N/A eMMC ‘Zeroization’ or Used for (Cert. #A3268) from CO Output: N/A Hashed with ‘Reset Device’ Authentication Password SHA2-256 service User Password Hash 128-bits SHA2-256 Generated Entry: N/A N/A eMMC ‘Zeroization’ or Used for (Cert. #A3268) from User Output: N/A Hashed with ‘Reset Device’ Authentication Password SHA2-256 service Recovery Password Hash 128-bits SHA2-256 Generated Entry: N/A N/A eMMC ‘Zeroization’ or Used for (Cert. #A3268) from Output: N/A Hashed with ‘Reset Device’ Authentication Recovery SHA2-256 service Password Entropy Input 1024 bits Entropy Source Internally Entry: N/A N/A RAM Overwritten Used as entropy input (Security (Cert. #E55) from SP Output: N/A (Plaintext) with zeros to the SP 800-90A strength is 800-90B immediately DRBG
256 bits) Entropy after use
Source DRBG Nonce 512 bits HMAC DRBG Internally Entry: N/A N/A RAM Overwritten Used as nonce input to (Security (Cert. #A3268) from SP Output: N/A (plaintext) with zeros the SP 800-90A DRBG strength is 800-90B immediately
128 bits) Entropy after use
Source DRBG Internal State N/A HMAC DRBG Internally Entry: N/A N/A RAM ‘Zeroization’ or The internal state of (V and Key) (Cert. #A3268) from Output: N/A (plaintext) ‘Reset Device’ the SP 800-90A DRBG SP 800-90A service DRBG This document may be freely reproduced and distributed, but only in its entirety and without modification.
Key/CSP Name Strength Security Function Generation Import / Establishment Storage Zeroization Use & related SSPs & Cert. Number Export Device ECDH 256 bits ECDSA Key Gen Internally Entry: N/A N/A RAM Overwritten Used by the module Private Key (Security (Cert. #A3268) from Output: N/A (plaintext) with zeros for key agreement strength is SP 800-90A immediately (KAS-ECC-SSC per
256 bits) DRBG after use SP 800-56Ar3)
Shared Secret (Z) 256 bits KDA N/A Entry: N/A Shared Secret RAM Overwritten Used to derive the (Security (Cert. #A3268) Output: N/A from KAS-ECC- (plaintext) with zeros Session Key Material strength is SSC C(2e, 0s) immediately
128 bits) ECC CDH after use
AES Session Key 256 bits AES-CBC N/A Entry: N/A Derived by the RAM Overwritten AES Session Key (Security (Cert. #A3268) Output: N/A KDA Two-Step (plaintext) with zeros serves to encrypt data strength is Key Derivation immediately during the Secure
128 bits) Function after secure Session.
session is terminated ‘Zeroization’ service MAC Session Key 256 bits HMAC-SHA2-256 N/A Entry: N/A Derived by the RAM Overwritten MAC Session Key (Security (Cert. #A3268) Output: N/A KDK via KDA (plaintext) with zeros serves to authenticate strength is Two-Step Key immediately data during the Secure
128 bits) Derivation after secure Session.
Function session is terminated ‘Zeroization’ service CD Update Public Key RSA 2048 RSA 2048 N/A Entry: N/A eMMC N/A
4 Per IG 9.6.A
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
Table 21
Algorithm Test Test Method Type Indicator Details Conditions for or Test Properties Performing Test DRBG Instantiate, KAT CAST Success: LED blinks Instantiate KAT Power-on & Generate and at 3Hz Generate KAT Periodically Reseed 5 Error: LED blinks at (11 mins) 16Hz ECC CDH P- ECC CDH P- PCT PCT Success: LED blinks Performed ECC CDH
256 256 keypair at 3Hz immediately after key keypair
pairwise Error: LED blinks at generation during generation consistency 16Hz key agreement during key test. agreement when ‘Open Partition’ service is called. ECC CDH P- ECC CDH P- PKV PKV Success: LED blinks Full Public Key Part of key
256 256 Public at 3Hz Validation of host agreement
Key Error: LED blinks at public key when ‘Open Validation 16Hz Partition’ service is called. Entropy N/A APT/RCT APT Success: LED blinks Adaptive Proportion Continuous Source at 3Hz Test Error: LED blinks at 16Hz HMAC- 256-bit KAT CAST Success: LED blinks HMAC KAT Power-on & SHA2-256 at 3Hz Periodically Error: LED blinks at (11 mins) 16Hz KAS-ECC- Private KAT CAST Success: LED blinks Compares output Power-on & SSC Key:256-bit at 3Hz with expected result Periodically Public Key: Error: LED blinks at (11 mins) 256-bit 16Hz KDA Shared Secret: KAT CAST Success: LED blinks Compares output Power-on & 256-bit at 3Hz with expected result Periodically Error: LED blinks at (11 mins) 16Hz PBKDF Salt 256-bit, KAT CAST Success: LED blinks Compares output Power-on & Password: 8- at 3Hz with expected result Periodically bytes Error: LED blinks at (11 mins) 16Hz SHA2-256 N/A KAT CAST Success: LED blinks SHA2-256 KAT Power-on & at 3Hz Periodically Error: LED blinks at (11 mins) 16Hz RSA-2048 RSA 2048 & KAT CAST Success: LED blinks Signature Verification Power-on & SHA2-256 at 3Hz KAT Periodically Error: LED blinks at (11 mins) 16Hz
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
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:
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:
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
1 ISO/IEC 19790
2 ISO/IEC 24759
4 SP 800-140
5 SP 800-140A
6 SP 800-140B
7 SP 800-140C
8 SP 800-140D
Generation and Establishment Methods
9 SP 800-140E
10 SP 800-140F
Test Metrics This document may be freely reproduced and distributed, but only in its entirety and without modification.
14. APPENDIX B: ABBREVIATIONS AND DEFINITIONS Table 24