K350

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for K350
  %% 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 K350
  %% 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., K350 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) K350 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

The module, depicted in Figure 1 below, 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. As shown in Figure 2, the three processors are STMicroelectronics STM32L452VE, NXP This document may be freely reproduced and distributed, but only in its entirety and without modification.

JCOP3, and Fujitsu/Socionext MB86C31. The module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated encrypted storage. Figure 1: K350 Purpose and Use: The K350 is a portable encrypted storage drive. Module Type: Hardware The K350 is defined as hardware module (refer to ISO/IEC 19790, Section 7.2.2). Module Embodiment: MultiChipStand The K350 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 K350 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: Table 2: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. This document may be freely reproduced and distributed, but only in its entirety and without modification.

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.

No components within the cryptographic boundary are excluded from the requirements of FIPS 140-3 under AS02.13 & AS02.14.

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 Level 3 AES256-bit XTS” along with the evaluated firmware version, “K350 3.07”. The Bootloader Version (1.03) 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 K350 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). This document may be freely reproduced and distributed, but only in its entirety and without modification.

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 Algorithm Validation Program (CAVP). 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. Per NIST SP 800-38E, AES-XTS is used for storage applications only. The module’s AES-XTS implementation conforms to IG C.I. The module checks explicitly that Key_1 ≠ Key_2 before using the keys in the XTS-Algorithm to process data with them. The length of the AES-XTS data unit does not exceed 220 blocks. The PBKDF algorithm is used to derive the Key Encryption Key (KEK) via Option 2a per NIST SP 800-132 with AESGCM (AES Cert. #3971) as the approved authenticated encryption algorithm. Per IG D.N, the PBKDF iteration count is selected to be 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. The Key Encryption Key (KEK) is the only key derived via PBKDF and may only be used for storage applications. Compliance to 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. This document may be freely reproduced and distributed, but only in its entirety and without modification.

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 80090Ar1 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-56Ar3 (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.

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 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 conformance with NIST SP 800-140E and NIST SP 800-63B (refer to Section 5.1.1).

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.

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.

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

G,E 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.

N/A for this module. This document may be freely reproduced and distributed, but only in its entirety and without modification.

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.

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 K350 is protected by an opaque epoxy and conforms to FIPS 140-3 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 protections 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 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 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 Crypto Officer (CO) Admin to configure their own during initialization. If the optional secondary Crypto Officer (CO) Standard role is created, the Crypto Officer (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 Cryptographic Officer (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 when the first Password is set.

There are no non-administrator roles.

The following security rules, except for the very last one, 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 provides identity-based authentication and clears previous authentications on power cycle.
3. The module does not provide any feedback mechanisms when entering passwords.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. Data output is inhibited during password entry, key generation, self-tests, zeroisation, and error states.
6. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
7. There are no restrictions on which unprotected SSPs are zeroised by the zeroisation service.
8. The module does not support concurrent operators, a maintenance interface, or maintenance role.
9. The module does not have any proprietary external input/output devices used for entry/output of data.
10. The module does not output intermediate key values or plaintext CSPs; plaintext operator passwords are entered directly via the keypad.
11. All CSPs are protected from unauthorized disclosure, modification, and substitution.
12. All PSPs are protected from unauthorized modification and substitution.
13. When the module is in an error state, the operator does not have access to any cryptographic service.
14. Operators must not disclose their passwords.

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.