DL4FE

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for DL4FE
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<br/>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 DL4FE
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<br/>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

DATALOCKER, INC., DL4FE 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 defines the Security Policy for the DataLocker, Inc. (DataLocker) DL4FE module, hereafter “the The physical form of the module is depicted in Figure 1. The module is a multi-chip standalone embodiment as defined by FIPS 140-3 and conforms to Security Level 3.

The module meets the overall requirements of FIPS 140-3 Security Level 3. Table 1: Security Levels This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module is an encrypted portable storage device, featuring three crypto processors, which provide layers of cryptographic protection. It requires no additional software or drivers to be installed on the host PC. The module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated encrypted storage. Figure 1: DL4FE Purpose and Use: The DL4FE is a portable encrypted storage hard drive. Module Type: Hardware The DL4FE is defined as hardware module (refer to ISO/IEC 19790, Section 7.2.2). Module Embodiment: MultiChipStand The DL4FE is defined as a multiple chip standalone cryptographic module. Module Characteristics: The critical components within the module are encapsulated inside a hard, opaque, production grade epoxy. Cryptographic Boundary: The cryptographic boundary is defined as the perimeter of the epoxy that encapsulates all the module’s components on the printed circuit board (PCB). This document may be freely reproduced and distributed, but only in its entirety and without modification.

Figure 2: Block Diagram N.B. The JTAG Write PIN Interface shown in Figure 2 is used to write firmware on debug devices. On production devices, the configuration setting is such that the JTAG interface cannot be used to read, erase, or program the STM32 flash memory.

The DL4FE 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 configuration (refer to Table 2): Tested Module Identification – Hardware: This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 2: Tested Module Identification

• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

Several non-sensitive components within the cryptographic boundary are excluded from the requirements of FIPS 140-3 under AS02.13 & AS02.14. These components are primarily passive in nature (e.g. resistors, capacitors, LED) or provide additional support to the general functionality of the module (e.g. enclosure, HDD/SSD, LCD touch panel). Failure or malfunction of these components would not compromise the security of the module. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Modes List and Description: The module only supports an Approved mode of operation and cannot be configured to operate in a nonApproved mode. Once the operator has authenticated, the unlocked screen will display “FIPS 140-3 Security Level

3 AES-256-bit XTS” along with the evaluated firmware version, “DL4FE 3.09”. The Bootloader Version (1.12) can be

verified via the SDK. Table 3: Modes List and Description The device will not respond to service calls before it has entered its approved mode of operation.

The DL4FE cryptographic module supports the approved cryptographic algorithms shown in Table 4. Approved Algorithms: The module supports the following approved cryptographic algorithms. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: The module supports the following vendor affirmed algorithms (refer to Table 5). Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

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 6: Security Function Implementations

The module utilizes only approved algorithms that are tested and validated under the Cryptographic Module Validation Program (CMVP). The module’s AES-GCM implementation conforms to IG C.H scenario 2. The module uses the approved Hash DRBG to generate the IV with a length of 96-bits. The entropy source producing the DRBG seed is located inside the module’s cryptographic boundary. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Per IG D.N, the PBKDF iteration count is selected to a value between 1,000 and 10,000. It utilizes the highest possible value, as long as the time required to generate the key using the entered password is acceptable for the users. Compliance to NIST SP 800-56ARev3 assurances: For KAS-ECC, the module satisfies IG D.F Scenario 2 path (2). The key derivation function complies with NIST SP 800-56Cr2 (i.e., One-Step KDF). Furthermore, the module obtained the appropriate assurances, as required in Sections 5.6.2 of NIST SP 800-56Ar3. For KAS-ECC, the module uses C(2e,0s), thus no static key pairs are used as a part of the KAS schemes per NIST SP 800-56Ar3. Full public key validation is implemented (NIST SP 800-56Ar3 Section 5.6.2.3.3). No key confirmation is implemented.

The module incorporates a NIST SP 800-90A CTR-DRBG (Cert. #A5176) that is seeded from the module’s NIST SP 800-90B validated entropy source. The unmodified output of the DRBG is used for generating cryptographic key material or random nonces. Table 7: Entropy Certificates Table 8: Entropy Sources

The module generates symmetric cryptographic keys in conformance with NIST SP 800-133r2 using a NIST SP 80090A conforming DRBG (Cert. #A5176) for the encryption and protection of data and cryptographic keys. The module generates asymmetric cryptographic key pairs in conformance with FIPS 186-5 for the verification of digital signatures, or for the facilitation of key agreement in conformance with NIST SP 800-56ar3.

The module supports the establishment of cryptographic keys using elliptic curve cryptography (ECC) in conformance with NIST SP 800-56ar3. The module implements KAS-ECC-SSC per NIST SP 800-56A Rev3 (Cert. #A5176), used in conjunction with KDA per NIST SP 800-56Cr1 (Cert. #A5176). Key establishment methodology provides at least 128 bits of encryption strength. This is used to establish secure communication sessions.

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

The module relies upon the standard USB and other serial protocols 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 physical ports and logical interfaces. The physical ports are defined within Table 9 below: Table 9: Ports and Interfaces

The module provides a physically secured keypad interface for operator entry of plaintext Critical Security Parameters (CSPs), such as authentication data. Each signal connects through physically separated conductors directly into the module’s cryptographic boundary. The trusted channel is established when the module is assembled during manufacturing and cannot be disabled. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module supports authentication methods for the Cryptographic Officer roles. These roles have separate authentication methods as indicated in Table 10.

Table 11: Roles The module does not support concurrent operators. Only one operator is allowed to access the device at any time. Operator authentication does not persist beyond power-cycling the module. The selection of roles is implicit. This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

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

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

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

(Z): G,E G,E,R (Z): G,E This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

Name

Description and firmware are destroyed).

Indicator

Inputs

Outputs

Security Functions

SSP Access Encryption Key (SEK): Z - System Base Key (SBK): G,E,Z - DRBG-EI: G,E

The module supports firmware updates by the Cryptographic Officer role (both Crypto Officer (CO) Admin and Crypto Officer (CO) Standard) through a secure firmware-loading mechanism. Upon authentication of the Cryptographic Officer, a Secure Channel (via the Secure Channel service) is established to logically isolate and to protect the confidentiality and integrity of the firmware image during transfer. The Firmware Update service should then be called. The firmware image is digitally signed using ECDSA P-256 and verified within the module using an embedded public key prior to installation. The module inhibits all data output interfaces during the firmware update, and no cryptographic operations are performed. Only after successful verification does the module write the updated firmware to protected memory and perform a controlled power-cycle to activate the firmware. This mechanism provides assurance that only authenticated, integrity-verified firmware can be loaded, satisfying the controls and isolation requirements of ISO/IEC 19790 Annex B and FIPS 140-3 IG 10.3.A.

The module includes the following firmware components that include separate firmware integrity tests: − Bootloader: Signature Verification (ECDSA, Cert. #A5176), P-256 − Firmware: Signature Verification (ECDSA, Cert. #A5176), P-256 The module will transition to its error state upon the failure of either firmware integrity test.

Self-tests may be initiated on demand by power cycling the module or invoking a soft reset via the services.

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

Type of Operational Environment: Limited How Requirements are Satisfied: The module does not contain a modifiable operational environment. The module’s operational environment is limited. The module includes a firmware load service to support necessary updates. Firmware versions validated through the FIPS 140-3 CMVP will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the module defined by this Security Policy or covered by this validation. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The DL4FE is protected by an opaque epoxy and conforms to FIPS 140-3 Security Level 3 physical security requirements. The operator is required to physically inspect the module for indications of tampering attempts at intervals specified by their organization’s policies. The fascia can be removed without tamper evidence and should be inspected when examining for tamper evidence. Table 13: Mechanisms and Actions Required The module does not support environmental failure protection (EFP) mechanisms for high/low voltage and temperature extremes. The module underwent environmental failure testing (EFT) instead (refer to Table 14). Table 14: EFP/EFT Information

The module has been tested at the operational, storage and distribution temperatures listed in Table 15. The module’s epoxy hardness is assured within these ranges. Table 15: Hardness Testing Temperatures This document may be freely reproduced and distributed, but only in its entirety and without modification.

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

The module supports both volatile and persistent storage of SSPs within internal RAM and Flash. Table 16: Storage Areas

Table 17: SSP Input-Output Methods

The zeroization methods described within Table 18 are supported by the module. Zeroization services explicitly overwrite SSPs with zero values. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 18: SSP Zeroization Methods 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 19: SSP Table 1 This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 20: SSP Table 2 N.B. The Key Encryption Key (KEK) is derived using PBKDF (NIST SP 800-132). This algorithm is only approved for use within storage applications. This document may be freely reproduced and distributed, but only in its entirety and without modification.

All self-tests must be completed successfully prior to any other use of cryptography by the module. If one of the self-tests fails, the module enters the error state and will output an error message to the attached screen prior to shutting down; otherwise, the module indicates successful completion by presenting the login screen. If an error is encountered during self-tests, operators must power-cycle the device to reinitiate the power-up selftests. The module automatically assumes the Approved mode of operation upon successful completion of the selftests. Table 21: Pre-Operational Self-Tests

The following conditional tests are performed upon power-up, on-demand and periodically. 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 22: Conditional Self-Tests The module will perform periodic self-tests at every power-on and every 24 hours. If the module is actively using the DEK, periodic self-tests will be delayed until the DEK is no longer in use. Table 23: Pre-Operational Periodic Information 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 24: Conditional Periodic Information This document may be freely reproduced and distributed, but only in its entirety and without modification.

Self-tests may be invoked on demand by power cycling the module or invoking a soft reset through the services.

There are no specific maintenance requirements.

The module does not include a default passphrase. Upon first use, the module enforces the CO to configure their own during initialization. If the optional secondary CO Standard role is created, the CO Standard must also configure a passphrase. There are no other instructions for initializing the module for use in the Approved mode of operation.

Before the first use, a Crypto Officer (CO) Admin password (8 – 64 characters) must be set. (This password should not be disclosed.) After this is done, the module is ready for operation. The module’s administrator’s guide is shipped with the module. Performing zeroisation will restore the drive to its factory state (blank and unformatted). A new DEK is generated immediately after a new password is set, and the Crypto Officer role is assumed.

There are no non-administrator roles.

All of the following security rules except for the last two items are enforced by the cryptographic module to ensure the FIPS 140-3 security requirements are met. This document may be freely reproduced and distributed, but only in its entirety and without modification.

1. The module provides two distinct, authenticated operator roles: Cryptographic Officer (CO) Admin and Cryptographic Officer (CO) Standard.
2. The module does not provide any feedback mechanisms when entering passwords.
3. An operator does not have access to any cryptographic services prior to assuming an authorized role.
4. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
5. The module does not support concurrent operators, a maintenance interface, or maintenance role.
6. The module does not have any proprietary external input/output devices used for entry/output of data.
7. The module does not output intermediate key values or plaintext CSPs; plaintext operator passwords are entered directly via the touch screen panel.
8. When the module is in an error state, the operator does not have access to any cryptographic service.
9. The cryptographic module does not support a non-approved mode of operation and only operates in an approved mode of operation.
10. The cryptographic module supports identity-based authentication for all services that utilize CSPs and approved security functions.
11. The data output interface is inhibited during self-tests, zeroization, PIN entry, and when the module is in an error state.
12. When the cryptographic module is in an error state, it ceases to provide cryptographic services, inhibits all data outputs, and provides status of the error.
13. When the cryptographic module is powered off and subsequently powered on, the results of previous authentications are not retained, and the cryptographic module requires the operator to be reauthenticated in an identity-based fashion.
14. The cryptographic module protects CSPs from unauthorized disclosure, unauthorized modification, and unauthorized substitution.
15. The cryptographic module does not support bypass capability and does not implement bypass tests.
16. The module receives external power inputs through the defined power interface. The power interfaces cannot be used to drive power to external targets.
17. Upon authenticating into a particular role, it is not possible to switch into another role without reauthenticating.
18. The finite state machine does not support the following states: maintenance and CSP output.
19. The cryptographic module is not a radio and does not support any wireless interfaces or OTAR.
20. The module is an encrypted storage drive that utilizes PBKDFv2 (NIST SP 800-132) and AES-XTS (FIPS 197 and NIST SP 800-38E). These algorithms can only be used for the protection of data at rest.
21. The cryptographic module performs a 256-bit comparison to ensure XTS key_1 is not equal to key_2.
22. Operators must not disclose their passwords.
23. There are no restrictions on which unprotected SSPs are zeroised by the zeroisation service.

Zeroise the module and dispose of it at a proper e-waste facility.

The module is not purposefully designed to mitigate any 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.