NIAP: Compliant Product
  NIAP  »»  Product Compliant List  »»  Compliant Product  
Compliant Product - ASURRE-Stor(TM) Solid State Self-Encrypting Drive Hardware revision 3.0, Firmware revision 1.5.1

CC Certificate [PDF] Security Target [PDF] * Validation Report [PDF]

Assurance Activity [PDF]

Administrative Guide [PDF]

* This is the Security Target (ST) associated with the latest Maintenance Release.  To view previous STs for this TOE, click here.

Product Description

The TOE functions as a standard 2.5” SATA self-encrypting solid state hard drive. The TOE is a solid state device that stores all user data in encrypted form. This provides secure storage of data and facilitates rapid cryptographic erasure via sanitization of the encryption key.

The physical embodiment of the TOE conforms to the EIA SFF-8201 specification. The electrical and software interface is the Serial ATA revision 2.6 specification. As such it can interface to any environment that is compatible with standard 2.5” SATA hard drives. The TOE also uses two of the SATA power interface lines as a serial interface that can serve as an optional method of entering the Key Chain parameters when in KEK with Black Key mode. The TOE also has optional status LEDs and a Write Protect Port.  The TOE can utilize the industry standard ATA security functions to authenticate users and can load or generate its own encryption keys and as such is not dependent on TCG based hardware or a TPM module.

Evaluated Configuration

The TOE is operating in the CC Evaluated configuration when it is configured in Modes 1 or 6.

Security Evaluation Summary

The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. The Mercury Systems ASURRE-Stor™ Solid State Self-Encrypting Drive was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 5, the collaborative Protection Profile for Full Drive Encryption – Encryption Engine, Version 2.0 + Errata 20190201, February 01, 2019, and the collaborative Protection Profile for Full Drive Encryption - Authorization Acquisition, Version 2.0 + Errata 20190201, February 01, 2019. The product, when installed and configured per the instructions provided in the guidance, satisfies all of the security functional requirements stated in the Security Target. The evaluation was completed in February 2020. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, (CCEVS-VR-11041-2020, dated March 6, 2020) prepared by CCEVS and the Assurance Activities Report (AAR) (20-3516-R-000 V1.1, dated February 7, 2020).

Environmental Strengths

Cryptographic Support

The TOE utilizes the following cryptographic algorithms:

-           AES-XTS-256 – Encryption/decryption of stored data.

-           DRBG – Generation of cryptographic keys.

-           AES Key Wrap – Encryption/decryption of cryptographic keys.

-           SHA-512 – DRBG, HMAC, and ECDSA primitive.

-           PBKDF – Derivation of a key from a user provided password.

-           ECDSA – Verification of firmware updates.

All algorithms, except for PBKDF, were tested by the CAVP.

User Data Protection

The TOE uses the XTS-AES-256 algorithm to encrypt all user data on the drive. The TOE does not write any plaintext user data to persistent storage.

Security Management

The TOE allows authorized users to change the data encryption key (DEK), cryptographically erase the DEK, initiate firmware updates, import wrapped DEK, change passwords, and configure cryptographic functionality.

Protection of the TSF

The TOE protects itself by running a suite of self-tests at power-up, authenticating firmware and by not providing any mechanism to export any key values. The customer is encouraged to externally fill keys so that an unpowered module contains no CSP information that would lead to compromise of the encrypted data at rest. Beyond self-tests and crypto KATs, the module has numerous continuously running checks built into the C code and the VHDL code. Whenever an error is detected, (corruption, impossible states, out of range values, extra bytes in queues, etc.) that might compromise the security of the module, the module sets a flag and resets. This eliminates any CSP values in FPGA RAM and renews/reloads logic in the FPGA.

Vendor Information

Mercury Systems, Inc.
Sabrina Piña
Site Map              Contact Us              Home