datAshur PRO

Certificate

Approved Algorithms (8)

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

flowchart LR
  %% Deterministic review-risk graph for datAshur PRO
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status output<br/>unauthenticated</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for datAshur PRO
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status output<br/>unauthenticated</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C6 clueLow;

Security Policy, page by page

iStorage Ltd. datAshur PRO Version 1.0 This document may be freely reproduced and distributed only in its entirety and without modification.

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

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

The iStorage Ltd. datAshur PRO, datAshur PRO+A and datAshur PRO+C are multi-chip standalone, cryptographic modules that provide hardware-encrypted storage of user data with a USB 3.0 interface. Access to encrypted data is authenticated with user input via the built-in keypad.

The modules are designed to meet the Security Level 3 requirements for each of the applicable sections documented within ISO/IEC 19790, Section 6 as shown in Table 1. Table 1: Security Levels This document may be freely reproduced and distributed only in its entirety and without modification.

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

1 SP 800-90Ar1 – Recommendation for Random Number Generation Using Determinstic Random Bit Generators. NIST. (June 2015).

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

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

The datAshur PRO, datAshur PRO+A and datAshur PRO+C cryptographic modules are designed to meet the requirements of FIPS 140-3 Security Level 3 (refer to Table 1). The modules are available in the following configurations: x = 4, 8, 16, 32, 64, 128, 256, 512 (denotes module’s memory capacity in GB) y = 4, 8, 16, 32, 64, 128, 256 (denotes module’s memory capacity in GB)

The module’s operating environment is defined as non-modifiable. The FIPS 140-3 Security Level 3 validated versioning information is shown in Table 2. Table 2: Tested Configurations To identify a module covered by this security policy, locate the product hardware identifier from the back side of the module housing in the table above. Then, use the ‘Show Version’ service to verify that the This document may be freely reproduced and distributed only in its entirety and without modification.

module identifier (Red, Blue, Green LED Blink = datAshur PRO) and firmware version (e.g., Red LED blinks twice = 2.00.0)

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

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

The datAshur PRO, datAshur PRO+A and datAshur PRO+C modules support the approved cryptographic algorithms shown in Table 3.

The module supports the following approved cryptographic algorithms. Table 3: Approved Algorithms NIST. (January 2010).

3 FIPS 197 – Advanced Encryption Standard (AES). NIST. (November 2001).

4 SP 800-38A – Recommendation for Block Cipher Modes of Operation: Methods and Techniques. NIST. (December 2001).

5 SP 800-133r2 – Recommendation for Cryptographic Key Generation. NIST. (June 2020).

6 FIPS 198-1 – The Keyed-Hash Message Authentication Code (HMAC). NIST. (July 2008).

7 SP 800-132 – Recommendation for Password-Based Key Derivation: Part 1: Storage Applications. NIST. (December 2010).

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

8 FIPS 180-4 – Secure Hash Standard (SHS). NIST. (August 2015).

9 SP 800-133r2 – Recommendation for Cryptographic Key Generation. NIST. (June 2020).

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

The module does not support key establishment and therefore does not support any key agreement or key transport schemes. Table 8: Security Function Implementations N/A N/A N/A N/A N/A N/A

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

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

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

The module does not support key establishment.

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

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

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

The module supports identity-based authentication in the form of a unique ID / Password combination. technique known as a Memorized Secret in conformance with NIST SP 800-140E and SP 800-63B (refer to Section 5.1.1). The Crypto Officer and User roles authenticate via the module’s keypad interface. The module does not support a feedback mechanism or output CO or User authentication data outside of the cryptographic boundary. The module enforces some constraints on the creation of a Password. The following Password forms will be rejected by the module as invalid:

• Identical repeating characters, e.g. 77777777
• Ascending or descending characters e.g. 12345678 or 98765432 The Password from either the User or the CO is input to a PBKDF that produces the Key Encryption Key (KEK) associated to the role. The KEK is used to encrypt or decrypt the DEK with AES CTR (Cert. #3757) and authenticate the CO/User using AES CMAC (Cert. #3757). Table 10: Authentication Methods of a sequence of decimal digits 0-9, as marked on the keypad buttons, selected by the User or CO. Most of the buttons also bear alphabetic letters (refer to Figure 1). The minimum Password length is eight (8) characters10. The maximum Password length is 15 characters. The probability of a successful, The module protects against brute-force attempts to guess a role’s Password by permitting no more than ten (10) consecutive incorrect guesses before locking out that role. Incorrect Password attempts are counted independently for each role. The probability of an attacker correctly guessing a Password in any time period12, such as a one-minute interval, is 10-7 or 1 chance in 10,000,000.

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

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

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

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

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

The module implements level 3, identity-based authentication with two distinct identities, one User identity and one Crypto-Officer identity. While unauthenticated, the module supports a limited set of services such as checking the module This document may be freely reproduced and distributed only in its entirety and without modification.

The table below summarizes the Approved Services of the module. The SSP Access column identifies the SSPs accessed for each service with codes specifying the kind of access granted during the service operation. SSP access rights are defined as follows: − G = Generate: The module generates or derives the SSP. − R = Read: The SSP is read from the module (e.g., the SSP is output). − W = Write: The SSP is updated, imported, or written to the module. − E = Execute: The module uses the SSP in performing a cryptographic operation. Table 12: Approved Services This document may be freely reproduced and distributed only in its entirety and without modification.

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

The module does not support any non-approved services.

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

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

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

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

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

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

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

This module does not implement explicit environmental failure protection mechanisms (EFP). The module conforms to the FIPS 140-3 environmental failure testing (EFT) requirements. Table 13: EFP/EFT

The module supports and has been tested at the operation, storage and distribution temperatures listed in Table 14. The module’s epoxy and outer enclosure hardness are assured within these ranges. Table 14: Hardness Testing Temperature Ranges

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

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

The module is a data storage device designed to encrypt and store arbitrary data using AES-XTS within its eMMC memory components. The module physically and logically protects CSPs when they are present within the module. Please refer to Table 15 for additional information. This document may be freely reproduced and distributed only in its entirety and without modification.

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

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

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

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

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

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

Table 15: Sensitive Security Parameters This document may be freely reproduced and distributed only in its entirety and without modification.

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

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

When the module fails a pre-operational self-test, it enters the error state described in Table 16 and Table 18 below. Clearing this error state requires that the module be power cycled. Table 16: Per-Operational Self-Tests

When the module fails a conditional self-test, it enters an error state described in Table 17 and Table 18. Clearing this error state requires that the module be power cycled. Table 17: Conditional Self-Tests This document may be freely reproduced and distributed only in its entirety and without modification.

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

Table 18: Error States This document may be freely reproduced and distributed only in its entirety and without modification.

To verify that the module is in good working order, power it on by connecting it to a USB power source. The three status indicator LEDs will blink simultaneously, indicating that firmware integrity tests and KATs have passed successfully. When using the View Last Error service, the module will report the error as a sequence of LED blinks. The following table summarizes the LED patterns that the module emits for each logged error. Table 19: Logged Error Codes

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

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

After a module is assembled in the factory, production release firmware is programmed into the electronics, the circuit board is coated with epoxy, and the module is sealed with an epoxy adhesive. The factory configures the module with a DEK, loads product documentation into the secure, encrypted data partition, and then prepares the module for first use by the user. There is no default Password set at the factory. On first use, the user must create either a User or a CO Password. Subsequently, data on the encrypted partition may be read, modified, or deleted. A new module comes from the factory preloaded with product documentation and with a DEK defined. No Password is set when the module leaves the factory. Before the first use and before the secure encrypted data partition can be accessed, a User or CO Password must be set. After this is done, the module is ready for operation.

Before the first use a CO Password (8 – 15 characters) must be set (this password should not be disclosed). After this is done, the module is ready for operation. Press the KEY button once, then press This document may be freely reproduced and distributed only in its entirety and without modification.

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

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

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

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

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

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