Mercury Systems
ASURRE
-Stor
®
SSD
Administrative Guidance
Copyright 2020 Mercury Systems. May only be reproduced in its original form (without revision)
Rev. 1.5.1 February 2020 © 2020 Mercury Systems. All rights reserved
Mercury Systems, Inc. • (602) 437-1520 •
7
256,
SP 800‐38F)
the DEK. The TOE then overwrites the password that was entered by the CO and the derived key
(BEV/KEK) resulting from the PBKDF function and saves the wrapped DEK in NVRAM. After configuration completes,
the CO exits the Crypto Officer role. At this point the TOE is operational and ready to accept mission data in a User
Role. Mission personnel load mission data into the TOE then turn off TOE power. Removing power purges the DEK
from the TOE. In the powered-off state the TOE contains only the wrapped DEK located in NVRAM.
The TOE is transported to the mission vehicle and installed. The mission vehicle host system provides the password.
The TOE conditions the password with PBKDF to create a derived key (BEV/KEK) that is then used to un-wrap (AES-KW-
256,
SP 800‐38F)
the DEK. If the unwrap operation completes successfully and the resulting DEK is the correct DEK, the
TOE enters a normal operating mode which allows the mission to begin. When the mission completes, TOE data, if
applicable, is retrieved.
The TOE retains the AES wrapped DEK across power cycles in NVRAM, however; the password must fill on each power
cycle to complete the key chain.
Mode 6: ATA password with KEK and BLACK key
Pre-configuration operations, separate from the TOE, are described below.
In Mode 6, the Crypto Officer (CO) begins by creating three keys, a 256-bit BEV(KEK), a 512-bit DEK, and a 576-bit BLACK
key. The DEK consists of a 256-bit AES key and a different 256-bit XTS key. The CO uses the BEV(KEK) and AES key wrap
(AES-KW-256, SP 800-38F) to wrap the DEK. The resulting wrapped DEK is referred to as the BLACK key. The CO and
mission personnel must retain the BLACK key for filling the TOE at each mission power-on cycle.
TOE configuration operations (performed on the TOE):
The CO configures the TOE using MDU or a similar custom utility program to operate in Mode 6. The CO fills the
BEV(KEK) and enters a password of up to 64 characters. The TOE conditions the password with PBKDF (Password Based
Key Derivation Function SP 800-132) to create a derived 256-bit key that the TOE uses to AES key wrap (AES-KW-256, SP
800‐38
F) the BEV(KEK). The TOE saves the wrapped BEV(KEK) in NVRAM. The CO then cycles TOE power off then on
again.
Next, the CO fills the TOE with the password followed by the BLACK key. The TOE conditions the password using PBKDF
(Password Based Key Derivation Function SP 800-132) to create a derived intermediate key and uses it to AES unwrap
(AES-KW-256,
SP 800‐38F)
the BEV(KEK). The TOE then uses the BEV(KEK) to unwrap the BLACK key re-creating the DEK
and completing the key chain. The TOE overwrites the password and derived key. The CO exits the Crypto Officer role.
At this point the TOE is operational and ready to accept mission data in a User Role. Mission personnel load mission
data into the TOE then turn off TOE power. Removing power purges the DEK and unwrapped BEV from the TOE RAM.
In the powered off state, the TOE contains only the wrapped BEV(KEK) in NVRAM.
The TOE is transported to the mission vehicle and installed. The mission vehicle host system provides the password and
the BLACK key. The TOE conditions the password with PBKDF to create a derived intermediate key that the TOE uses to
unwrap the BEV(KEK) previously saved in NVRAM. If the unwrap operation succeeds, the TOE uses the BEV(KEK) to
unwrap the BLACK key. If the unwrap operation succeeds and the resulting DEK is the correct DEK, the TOE enters a
normal operating mode which allows the mission to begin.
When the mission completes, TOE data, if applicable, is retrieved.
The TOE retains the AES wrapped BEV(KEK) in NVRAM across power cycles. The password and BLACK key must fill on
each power cycle to complete the key chain.
5
Failed attempts penalty
The TOE supports a feature to limit the number of sequential failed attempts to enter correct passwords, key values,
and correct digital signature during firmware updates. When the maximum number of failed attempts count is
