Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 1 of 24
Glyph Production Technologies
Secure Drive + BT
FIPS 140-2 Non-Proprietary Security Policy
Version 2.0
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 2 of 24
Table of Contents
1 Cryptographic Module Specification ....................................................................................4
1.1 Overview.......................................................................................................................4
1.2 FIPS Security Level ......................................................................................................6
1.3 Mode of Operation........................................................................................................7
2 Module Ports and Interfaces................................................................................................8
3 Roles, Services, Authentication, and Identification ............................................................10
3.1 Roles and Identification ..............................................................................................10
3.2 Module Initialization ....................................................................................................10
3.3 Services......................................................................................................................11
3.4 Authentication.............................................................................................................13
4 Physical Security ...............................................................................................................15
5 Operational Environment ...................................................................................................15
6 Cryptographic Key Management........................................................................................15
6.1 Cryptographic Algorithms............................................................................................15
6.2 Critical Security Parameters .......................................................................................17
6.3 Zeroization of Critical Security Parameters.................................................................19
7 EMI/EMC Regulatory Compliance .....................................................................................20
8 Self-Tests...........................................................................................................................21
9 Mitigation of Other Attacks .................................................................................................23
10 Glossary of Terms and Acronyms....................................................................................23
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 3 of 24
List of Tables
Table 1: Module Hardware and Firmware Versions...................................................................5
Table 2: FIPS Security Level.....................................................................................................6
Table 3: Module Ports and Interfaces........................................................................................8
Table 4: LED Status Indications................................................................................................9
Table 5: Module Rôles ............................................................................................................10
Table 6: Services Available in FIPS Approved Mode...............................................................12
Table 7: FIPS Approved Algorithms.........................................................................................15
Table 8: FIPS Allowed Algorithms............................................................................................16
Table 9: Critical Security Parameters......................................................................................17
Table 10: Public Security Parameters .....................................................................................18
Table 11: Module Self-Tests....................................................................................................20
List of Figures
Figure 1: Secure Drive + BT ....................................................................................................5
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 4 of 24
1 Cryptographic Module Specification
1.1 Overview
The Glyph Production Technologies Secure Drive + BT is a multi-chip, stand-alone,
cryptographic module that provides hardware-encrypted storage of user data with a USB 3.0
interface. Access to encrypted data is authenticated via the Bluetooth interface. 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 custom electronics within the
module are encapsulated within an opaque, production grade epoxy. The module's enclosure
defines the cryptographic boundary.
The data encryption key (DEK) and other critical security parameters (CSPs) are generated by
a NIST approved DRBG2
within the module when it is first used. The seed for the DRBG is
also produced within the module from a hardware-based, entropy generator.
The user interface for the module is three (3) status-indicators LEDs. The LEDs are each a
different color, red, green, and blue.
2 SP 800-90Ar1 – Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST.
(June 2015).
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 5 of 24
Figure 1: Secure Drive + BT
Hardware Part Numbers Firmware Versions
(implemented on all hardware versions)
SDPL1000BT
SDPL2000BT
SDPL4000BT
SDPL5000BT
SDPLSSD1000BT
SDPLSSD2000BT
SDPLSSD4000BT
SDPLSSD8000BT
Each module has one each of
Firmware A and Firmware B.
Firmware A
CLEVX_3637E_USB_V0313
or
CLEVX_3637E_USB_V0314
(no security relevant differences)
Firmware B
CLEVX_SATA-BT_v2.3
Table 1: Module Hardware and Firmware Versions
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 6 of 24
1.2 FIPS Security Level
The module meets the overall requirements for FIPS 140-23
Level 3.
FIPS Area FIPS Security Requirement Level
1 Cryptographic Module Specification 3
2 Module Ports and Interfaces 3
3 Roles, Services, and Authentication 3
4 Finite State Model 3
5 Physical Security 3
6 Operational Environment n/a
7 Cryptographic Key Management 3
8 EMI/EMC 3
9 Self-Tests 3
10 Design Assurance 3
11 Mitigation of Other Attacks n/a
Table 2: FIPS Security Level
3 FIPS 140-2 – Security Requirements for Cryptographic Modules. NIST. (December 2002).
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 7 of 24
1.3 Mode of Operation
The module operates only in a FIPS approved mode. Approved mode is indicated by the three
status-indicator LEDs illuminating one at a time, green, blue, and then red when the module is
powered on. This indication means that firmware integrity checks and KATs have successfully
passed.
To meet the requirements for FIPS 140-2 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.
• 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.
• The operator is capable of commanding the module to perform self-tests at any time by
cycling the power.
• Data output is inhibited during self-test, zeroization, key generation, and authentication.
• No CSPs are output from the module in any form.
• Each unique AES GCM/IV pair is used for one and only one secure communication
session.
• Each secure communication session is established between exactly two entities.
• The module cannot establish a secure communication session with another, identical
module.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 8 of 24
2 Module Ports and Interfaces
The cryptographic module exposes the following physical ports and logical interfaces:
Physical Port Logical Interface Description
USB Data
Data input
Data output
Control input
Status output
The USB Data port connects the module to the host
computer. It is used to exchange decrypted user data
as well as control and status information for the USB
protocol. When the drive is locked the USB interface is
disabled.
Bluetooth
Control input
Status output
Data input
Data output
User and CO Password received and module status
information transmitted via the Bluetooth port.
Red, green and
blue LEDs
Status output Refer to Table 4 for details.
USB Power External power
The USB VBUS (+5VDC) powers the module and
embedded storage component.
Table 3: Module Ports and Interfaces
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 9 of 24
LED Behavior4
Module State Status Description
LEDs illuminate one at a time,
green, blue, and then red. Red
remains lit.
Connected to
USB power
Module powered-on with all LEDs operational. Firmware
integrity tests and KATs have passed.
LEDs illuminate continuously in
circling pattern, red then green
then blue.
Failed Module in error state.
Red LED illuminated Locked Module locked. User data secure.
Green LED illuminated Unlocked
Module unlocked. DEK is unobfuscated. USB interface with
host has not enumerated with the host computer.
Green and blue LED illuminated Connected Module unlocked and connected to host computer.
Green LED illuminated. Blue
LED blinking
Connected
Module unlocked and connected to host computer. There is
an active data transfer with host computer.
Table 4: LED Status Indications
To verify that the module is in good working order when it is first powered-on, observe that thethree
status-indicator LEDs illuminate one at a time green, then blue, and then red. Red remains lit indicating
that the module is locked.
4 Because the module is powered from USB, the LED indicators are valid only when when the module is connected to a
USB port.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 10 of 24
3 Roles, Services, Authentication, and Identification
3.1 Roles and Identification
The module implements level 3, identity-based authentication with two distinct rôles.
Identity Identification Authentication Data Description
User5 User chooses ASCII value '1' for User
identification.
7-15 character Password
User has full access to all User
services.
CO
CO chooses ASCII value '0' for CO
identification.
7-15 character Password
CO has full access to all CO
services.
Table 5: Module Rôles
3.2 Module Initialization
A new module comes from the factory initialized with a default User Password of '11223344'.
This factory default password must be changed before storing confidential data on the
module6
. No CO Password is defined for a factory initialized module. In this configuration, the
module is ready for operation in a FIPS approved mode.
If the module is zeroized, there will be neither a User Password nor a CO Password defined
and there will be no DEK. The module must be initialized before it will operate in an approved
mode. From this state, either a User or a CO Password may be defined first.
5 In the case where the User password is defined but no CO password is defined, the User identity behaves as a
combined User/CO identity.
6 Per FIPS 140-2 §4.3.3, the default password does not meet the strength of the authentication requirement because it
may be guessed in one attempt.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 11 of 24
3.3 Services
Identity Service CSP Access
CO
Set CO Password
Read, Execute, and Write
Change CO Password, CO salt, and CO KEK. Create DEK
using CTR-DRBG state (seed, V, key) if one is not defined.
Set User Password
Read, Execute, and Write
Change User Password, User salt, and User KEK.
Zeroize User Password
Zeroize
Zeroize User salt and User KEK.
Erase private partition data
Read, Execute, and Write
Change CO salt and CO KEK. Create DEK using CTR-DRBG
state (seed, V, key).
Zeroize
Zeroize User salt and KEK.
Open private partition for read/write
access to user data
Read and Execute
Read CO salt and CO KEK. Unobfuscate DEK.
Lock private partition to prevent
read/write access to user data
Zeroize
Zeroize DEK in RAM.
Read or write private partition with
user data
Read
Use DEK to encrypt and decrypt user data.
Configure idle timeout lock None
Configure Remote Management None
Change nickname None
Configure Step-Away lock None
User
Set CO Password when none exists
Read, Execute, and Write
Change CO Password, CO salt, and CO KEK.
Set User Password
Read, Use, and Write
Change User Password, User salt, and User KEK. Create DEK
using CTR-DRBG state (seed, V, key) if one is not defined.
Open private partition for read/write
access to user data
Read and Execute
Read CO salt and CO KEK. unobfuscate DEK.
Lock private partition to prevent
read/write access to user data
Zeroize
Zeroize DEK in RAM.
Read or write private partition with
user data
Read and Execute
Use DEK to encrypt and decrypt user data.
Configure idle timeout lock None
Change nickname None
Configure Step-Away lock None
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 12 of 24
Identity Service CSP Access
Unauthenticated
Show locked/unlocked status None
Show whether or not drive is
initialized
Read and Execute
Verify validity of either User salt or CO salt.
Show whether or not User Password
is defined
Read and Execute
Verify validity of User salt.
Show whether or not CO/Password is
defined
Read and Execute
Verify validity of CO salt.
Run self-tests None
Factory reset (zeroize) module and
erase private partition data
Zeroize
Zeroize all CSPs.
Query firmware version None
Authentication
Read, Execute, and Write
Create and read ECC-CDH Private Key, Session Master Secret,
AES-GCM Key/IV
Table 6: Services Available in FIPS Approved Mode
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 13 of 24
3.4 Authentication
The Crypto Officer and User roles authenticate via the Bluetooth interface. The module does
not output CO or User authentication data outside of the cryptographic boundary.
Communication via the Bluetooth interface is protected by encryption. Messages are
encrypted and authenticated with AES-GCM (Cert. #5397). Cryptographic keys are
established per SP 800-56Ar3 scheme C(0s, 2e, ECC CDH) and the single step KDA per SP
800-56Cr1 Section 4. These keys are used for key derivation using KBKDF (Cert. #201) in
Counter Mode, which relies on AES-CMAC (Cert. #5366) and HMAC-SHA-1 (Cert. #3554) per
SP 800-108, to create the AES-GCM keys.
The Password, from either the User or the CO, is an input to PBKDFv2 (Cert. #A777) that
produces the Key Encryption Key (KEK) for that role. The KEK is used by the non-approved
cryptographic Synthetic Initialization Vector7
(SIV) algorithm to obfuscate the DEK. SIV is
constructed using AES CTR (Cert. #5366) and AES CMAC (Cert. #5366). Unobfuscating the
DEK requires the same Password that was given to PBKDFv2 when the DEK was obfuscated.
The authentication strength for the module is determined by the Password. There are more
than 10 million (107
) Password combinations with a minimum length of seven (7) bytes. This
lower bound is derived by using only the ASCII decimal digits '0'-'9' in the Password, seven
bytes and ten choices per byte. Because the Password may be composed of UTF-8
characters, the length in characters may be fewer than seven. The module enforces the
minimum Password length in bytes.
UTF-88
character encodings may span from one to four bytes. For UTF-8 characters to supply
more combinations of Passwords than the ASCII decimal digits, there must be at least 3.4
variable bits in each encoded byte9
. In a single byte UTF-8 character, there are seven (7)
variable bits where we require at least 3.4 to meet the lower bound. In two byte characters,
there are eleven (11) variable bits where we require at least 6.8. In three byte characters,
there are 16 variable bits where we require at least 10.2. In four byte characters, there are 21
variable bits where we require at least 13.6. Or, to put it a different way, every byte in a UTF-8
character has at least 5 variable bits which is more than the minimum of 3.4 bits necessary to
meet the lower bound. Therefore, passwords encoded in seven bytes of UTF-8 characters will
have at least 107
different combinations and the chances of a successful random guess is less
than one in 10,000,000 (10-7
).
7 Harkins, D. Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard
(AES). IETF. (October 2008)
8 https://www.unicode.org/versions/Unicode11.0.0
9 At least 3.32 binary bits are needed to uniquely represent ten distinct values; 23.32
≅ 10
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 14 of 24
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.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 15 of 24
4 Physical Security
The multi-chip standalone cryptographic module includes the following physical security
mechanisms, conforming to FIPS 140-2 Level 3 requirements:
1. Production grade components
2. Hard, opaque, tamper-evident enclosure with embedded, hard epoxy covering all
security relevant components. Epoxy hardness was tested at ambient temperature and
over the module's documented operating temperature range from 5 ˚C to 41 ˚C.
3. Memory protection enabled to prevent read-out of firmware, RAM, or NVRAM
The operator is responsible for inspecting the module on each use for evidence of tampering.
If the module is physically compromised, it is no longer guaranteed to provide FIPS
protectionsand should be replaced.
5 Operational Environment
The FIPS 140-2 Operational Environment (Area 6) requirements for the module are not
applicable because the device does not contain a modifiable operational environment.
6 Cryptographic Key Management
6.1 Cryptographic Algorithms
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 16 of 24
Algorithm Modes Key Sizes Reference CAVP Cert. Use
AES XTS10
256 NIST SP 800-38E11
4642 Encryption of user data within storage application only
AES
ECB
CMAC
CTR
128
256
(ECB only)
FIPS 19712
NIST SP 800-38A13 5366 Block cipher basis of CTR-DRBG. Algorithmic basis of SIV.
AES
ECB
GCM
128
FIPS 197
NIST SP 800-38A
NIST SP 800-38D14
5397
AES-ECB is the block cipher basis for AES-GCM which is
used to encrypt Bluetooth messages
CKG - 256 NIST SP-800-13315 Vendor
Affirmed
The unmodified output of the DRBG is used for generating
symmetric keys and asymmetric seeds.
DRBG AES-CTR 256 NIST SP 800-90A16
2077 Random number generator for encryption keys and salts
ECDSA - P-256 FIPS 186-417
142818 Key generation for SP 800-56Ar3 key agreement
HMAC HMAC-SHA-1 160 FIPS 198-119
3554 Algorithmic basis of PBKDFv2
KAS-SSC ECC CDH P-256 NIST SP 800-56Ar320 Vendor
Affirmed
Key agreement for securing Bluetooth messages. Shared
secret computation with ECDSA (Cert #1428) as a
prerequisite for ECC key pair generation. Key establishment
provides 128 bits of encryption strength used to generate the
256-bit Session Master Secret. Conforming with IG D.8
(Scenario X1).
KDA One-step KDF 160 NIST SP 800-56Cr121 Vendor
Affirmed
Key agreement for securing Bluetooth messages. Key
derivation algorithm with SHS (SHS Cert #4308) as a
prerequisite, used in conjunction with KAS-SSC. Conforming
with IG D.8 (Scenario X1)
KBKDF AES-CMAC 128 NIST SP 800-10822
201
Key agreement for securing Bluetooth messages. Derivation
of keys for Bluetooth message encryption from the Session
Master Secret.
PBKDFv2 HMAC-SHA-1 - NIST SP 800-13223
A777
KEK generation. Password is the User/CO Password with a
minimum length of 7 characters. The module supports
option 2a as documented in SP 800-132 § 5.4.
SHS SHA-1 - FIPS 180-424
4308 Algorithmic basis of HMAC-SHA1
Table 7: FIPS Approved Algorithms
10 ECB and CBC modes as well as 128 bit AES are included in the CAVS certificate, but are used by no services in the
module.
11 SP 800-38E – Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage
Devices. NIST. (January 2010).
12 FIPS 197 – Advanced Encryption Standard (AES). NIST. (November 2001).
13 SP 800-38A – Recommendation for Block Cipher Modes of Operation: Methods and Techniques. NIST. (December
2001).
14 SP 800-38D – Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST.
(November 2007).
15 SP 800-133r2 – Recommendation for Cryptographic Key Generation. NIST. (June 2020).
16 SP 800-90Ar1 – Recommendation for Random Number Generation Using Deterministic Random Bit Generators.
NIST.(June 2015).
17 FIPS 186-4 – Digital Signature Standard (DSS). NIST. (July 2013).
18 Certificate #1428 covers only key pair generation. Signature and verification functions are not used.
19 FIPS 198-1 – The Keyed-Hash Message Authentication Code (HMAC). NIST. (July 2008).
20 SP 800-56Ar3 – Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography.
NIST. (April 2018).
21 SP 800-56Cr1 – Recommendation for Key-Derivation Methods in Key-Establishment Schemes. NIST (April 2018).
22 SP 800-108 – Recommendation for Key Derivation Using Pseudorandom Functions (Revised). NIST. (October 2009).
23 SP 800-132 – Recommendation for Password-Based Key Derivation: Part 1: Storage Applications. NIST. (December
2010).
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 17 of 24
24 FIPS 180-4 – Secure Hash Standard (SHS). NIST. (August 2015).
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 18 of 24
Algorithm Strength Use
NDRNG
Entropy source has a full 256 bits of security
strength.
Entropy source for seed to CTR-DRBG
SIV25
(no security
claimed)
Per FIPS 140-2 IG §1.23, SIV is a non-approved
cryptographic algorithm. It is allowed in FIPS
approved mode because it is not a security
function. “Cryptographic keys and CSPs
encrypted using a non-approved algorithm or
proprietary algorithm or method are considered in
plaintext form, within the scope of this standard
[FIPS 140-2].”
SIV uses the CO KEK and User KEK, derived from the
CO or User PIN/Password with KBKDFv2, to obfuscate
and unobfuscate the stored DEK.
Table 8: FIPS Allowed Algorithms
6.2 Critical Security Parameters
The module does not input or output private or secret cryptographic keys. Cryptographic keys
are established per SP 800-56Ar3 scheme C(0s,2e,ECC_CDH) and conforming to SP 800-
133r2. KEKs are derived using PBKDFv226
and are only used as part of the module's data
storage application. Public/private key pairs are ephemeral, used for one and only one key
agreement, and destroyed immediately after use.
25 Harkins, D. Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard
(AES). IETF. (October 2008). SIV is a Authenticated Encryption algorithm codified by the IETF in RFC-5297. NIST has
not analyzed this algorithm, so it is specified here as non-approved for the purposes of FIPS 140-2. Obfuscation of the
DEK depends on the user's PIN/Password and SIV to prevent the plaintext DEK from being stored in NVRAM. NIST
characterizes the storage of the DEK as plaintext explicitly because SIV is non-approved.
26 Per FIPS SP800-132 and FIPS 140 IG § D.6, the materials derived from PBKDFv2 are used only for protection of
electronically-stored data or for the protection of data protection keys.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 19 of 24
Parameter Description Source Storage Creation / Destruction
CTR-DRBG
state
(seed, V, key)
Generating random
values for CSPs
256 bit output
(full entropy)
NDRNG
and
CTR-DRBG
RAM
Created when DRBG is seeded which is every time the
module initializes
Destroyed on lock, connect, successful generation of CSPs,
power-off, and zeroization
User
Password
Input to PBKDFv2 to
allow generation of the
User KEK.
Strength of 7-15 bytes
Keypad entry RAM
Created by User
Destroyed on lock, unlock, timeout, and power-off
CO
Password
Input to PBKDFv2 to
allow generation of the
CO KEK.
Strength of 7-15 bytes
Keypad Entry RAM
Created by CO
Destroyed on lock, unlock, timeout, and power-off
User Salt
Input to PBKDFv2 to
generate key to
obfuscate the DEK.
128 bit value
CTR-DRBG NVRAM
Created when User changes Password
Destroyed on Password change, zeroization
CO Salt
Input to PBKDFv2 to
generate key to
obfuscate the DEK.
128 bit value
CTR-DRBG NVRAM
Created when CO changes Password
Destroyed on Password change, zeroization
XTS-AES
DEK
Encryption and
decryption
of user data
XTS-AES 256 bit key
CTR-DRBG RAM
Created when first password, either User or CO, is set
Destroyed on lock, timeout, entering low-power mode,
power-off, and zeroization
User KEK
Obfuscation an
unobfuscation of DEK
SIV AES 128 bit key
User
Password,
User Salt,
and
PBKDFv2
RAM
Created before obfuscating or unobfuscating the DEK.
Destroyed immediately after use.
CO KEK
Obfuscation and
unobfuscation of DEK
SIV AES 128 bit key
CO
Password,
CO Salt, and
PBKDFv2
RAM
Created before obfuscating or unobfuscating the DEK.
Destroyed immediately after use.
ECC-CDH
Private Key
Bluetooth Message
Encryption
ECC P-256 256 bit key
CTR-DRBG RAM
Generated when Bluetooth client requests secure channel
Destroyed when secure channel established
Session
Pre-master
Secret
Key generated during
session negotiation
256 bit secret
ECC-CDH
Key
Agreement
RAM
Created when secure channel established
Destroyed when Session Master Secret created
Session
Master Secret
Bluetooth Message
Encryption
256 bit secret
ECC-CDH
Key
Agreement
RAM
Created when secure channel established
Destroyed when secure channel session ends
AES-GCM
Key / IV
Bluetooth Message
Encryption
Session
Master Secret
RAM
Created when secure channel established or when secure
channel is rekeyed
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 20 of 24
AES key 128 bits
IV 96 bits
and
KDF-AES-
CMAC
Destroyed when secure channel session ends
Table 9: Critical Security Parameters
Parameter Use Source Storage Creation / Destruction
Bluetooth Message Generated when Bluetooth client requests secure channel
ECC-CDH
Public Key
Encryption
ECC P-256 256 bit
ECC Primitive RAM
Destroyed when secure channel established
key
ECC-CDH
Peer Public
Key
Bluetooth Message
Encryption
ECC P-256 256 bit
key
Remote
Bluetooth
Client
RAM
Generated when Bluetooth client requests secure channel
Destroyed when secure channel established
Table 10: Public Security Parameters
6.3 Zeroization of Critical Security Parameters
Zeroization is the erasure of CSPs from volatile and non-volatile storage. The module initiates
an erase cycle to zeroize CSPs stored in NVRAM. Copies of CSPs in RAM are erased by
setting the memory 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 erased leaving the module in the factory reset state with an erased use 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 CSPs for both the CO and User rôles,
including the DEK. The module will be left in the factory reset state with an erased user data
partition.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 21 of 24
6.3.1 Zeroization via Factory Reset
A Factory Reset will erase all CSPs, settings, and user data from the module. After this
operation, the operator must initialize the module per section 3.2 to return it to a FIPS
approved mode.
Starting with the module connected to USB power:
1. Invoke the FactoryReset service.
2. Query Status until operation is complete.
3. Initialize module by creating a new PIN/Password and reformatting the drive.
7 EMI/EMC Regulatory Compliance
This module conforms to the EMI/EMC requirements specified by Title 47 of the Code of
Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B (i.e.,
for home use). The module incorporates a Bluetooth radio which is excluded from the
EMI/EMC requirements for FIPS.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 22 of 24
8 Self-Tests
When the module powers on, it runs a sequence of self-tests. If any of these tests fails, the
drive will enter an error state. The module cannot perform any cryptographic services and is
not usable in this state. The module also performs conditional self-tests. The only way to clear
a module error state is to cycle the power. Self-tests are summarized in Table 11.
Test Category Test Name When Executed Error Indication
Firmware
Integrity
Firmware CRC-32 Module power-on Module illuminates no LEDs
Firmware CRC-16 Module power-on
Module fails to mount to host PC after
successful unlock and returns to locked state.
DRBG Cert. #2077 KATs27
CTR-DRBG Instantiate
CTR-DRBG Generate
Module power-on
LEDs illuminate in continuously circling pattern,
red then green then blue.
PBKDFv2 Cert. #A777
Combined KAT28
Derivation of Master Key (§5.4)
HMAC SHA-1 Cert. #3554
SHA-1 Cert. #4308
Module power-on
LEDs illuminate in continuously circling pattern,
red then green then blue.
AES #5366 KATs
AES ECB encrypt Cert. #5366
AES ECB decrypt Cert. #5366
AES CMAC Cert. #5366
Module power-on
LEDs illuminate in continuously circling pattern,
red then green then blue.
Known
Answer
XTS-AES Cert. #4642 KATs
AES-XTS encrypt
AES-XTS decrypt
Module power-on
Module fails to mount to host PC after
successful unlock.
AES-GCM Cert. #5397 KATs
AES-GCM authenticated encrypt
AES-GCM authenticated decrypt
Module power-on
LEDs illuminate in continuously circling pattern,
red then green then blue.
KAS KATs
KAS-SSC (SP 800-56Ar3)
Primitive 'Z' Computation KAT
per IG D.8 (Scenario X1)
KDA (SP 800-56Cr1)
KDA KAT per IG D.8
(Scenario X1)
Module power-on
LEDs illuminate in continuously circling pattern,
red then green then blue.
KBKDF Cert. #201 (SP 800-108)
Conditional
ECC Partial Public-Key Validation;
Assurance per SP 800-56Ar3
§5.6.2.3.4
Use of SP 800-56Ar3
Key Agreement
LEDs illuminate in continuously circling pattern,
red then green then blue.
NDRNG Conditional Test
per FIPS 140-2 AS.09.42
Use of NDRNG
LEDs illuminate in continuously circling pattern,
red then green then blue.
XTS-AES;
Key validity per IG A.9
CAVP #4642
Creation of DEK
Module fails to mount to host PC after
successful unlock.
Table 11: Module Self-Tests
27 The CRNGT per section 4.9.2 of FIPS 140-2 is not necessary per IG 9.8.
28 A single KAT for HMAC incorporates the SHA test.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 23 of 24
9 Mitigation of Other Attacks
The module has not been designed to mitigate attacks not addressed by the security
requirements of FIPS 140-2.
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 24 of 24
10 Glossary of Terms and Acronyms
Term Definition
AES Advanced Encryption Standard
AES-GCM AES Galois Counter Mode cipher used to encrypt Bluetooth messages
CO Cryptographic Officer
CRC Cyclic Redundancy Check
CSP Critical Security Parameter
CTR-DRBG Counter-Mode Deterministic Random Byte Generator
DEK Data Encryption Key
DRBG Deterministic Random Byte Generator
ECB Electronic Code Book
ECC Elliptical Curve Cryptography
ECC-CDH ECC Cofactor Diffie Hellman
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FIPS Federal Information Processing Protocol
HMAC Keyed-Hash Message Authentication Code
KAT Known Answer Test
KDF Key Derivation Function
KEK Key Encryption Key
LED Light Emitting Diode
NDRNG Non-deterministic Random Number Generator; module entropy source
NIST National Institute of Standards and Technology
NVRAM Non-volatile Random Access Memory
PBKDFv2 Password Based Key Derivation Algorithm Version 2
Password User's secret authentication character sequence
RAM Random Access Memory
Salt Random value used to improve security of cryptographic algorithms
SATA Serial AT Attachment
SHA-1 Secure Hash Algorithm 1
SHS Secure Hash Standard
Secure Drive + BT FIPS 140-2 Level 3 Non-Proprietary Security Policy Version 2.0
Copyright © 2020 ClevX, LLC. Prepared by SECUREDATA Inc. on behalf of Glyph Production Technologies. www.glyphtech.com
This document may be freely reproduced and distributed only in its entirety and without modification.
Page 25 of 24
SIV Synthetic Initialization Vector
USB Universal Serial Bus
XTS-AES AES cipher mode used to encrypt user data in mass storage
Zeroization The process of erasing cryptographic security keys and parameters