Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 1 of 25
THALES ESECURITY
Vormetric Data Security Manager
Module
FIRMWARE VERSION 6.0.2, HARDWARE VERSION 3.0
Security Policy FIPS 140-2 Level 2
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 2 of 25
Copyright
Date May 23, 2019
Doc. No TesUSA-DDQ-000060-EN
Version 1
Copyright 2019 Thales eSecurity. All rights reserved.
Reproduction is authorized provided the document is copied in its entirety without modification and including all copyright notices
contained herein.
Words and logos marked with ® or ™ are registered trademarks and/or trademarks of Thales eSecurity. or its affiliates in the EU
and other countries. All other company and/or product names are registered trademarks and/or trademarks of their respective
owners.
Information in this document is subject to change without notice.
Thales eSecurity may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Thales eSecurity, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 3 of 25
Contents
Copyright..............................................................................................................................................................................................2
1 Introduction ......................................................................................................................................................................................4
1.1 Purpose..........................................................................................................................................................................................4
1.2 References.....................................................................................................................................................................................4
2 Product Description..........................................................................................................................................................................5
2.1 Cryptographic Boundary ...............................................................................................................................................................5
3 Module Ports and Interfaces............................................................................................................................................................7
4 Roles, Services, and Authentication ................................................................................................................................................8
4.1 Identification and Authentication.................................................................................................................................................8
4.2 Strengths of Authentication Mechanisms....................................................................................................................................8
4.3 Roles and Services .........................................................................................................................................................................9
5 Physical Security .............................................................................................................................................................................11
6 Operational Environment...............................................................................................................................................................13
7 Cryptographic Key Management ...................................................................................................................................................14
7.1 Cryptographic Keys and CSPs......................................................................................................................................................14
7.2 Key Destruction/Zeroization .......................................................................................................................................................18
7.3 Approved or Allowed Security Functions...................................................................................................................................18
7.3.1 Approved security functions....................................................................................................................................................18
7.3.2 Allowed security functions.......................................................................................................................................................19
7.3.3 Non-Approved Algorithms.......................................................................................................................................................20
7.3.4 TLS Cipher Suites ......................................................................................................................................................................21
8 Self-Tests.........................................................................................................................................................................................22
8.1 Power-Up Self-Tests ....................................................................................................................................................................22
8.2 Conditional Self-Tests..................................................................................................................................................................22
9 Crypto-Officer and User Guidance.................................................................................................................................................23
9.1 Secure Setup and Initialization ...................................................................................................................................................23
9.2 Module Security Policy Rules......................................................................................................................................................23
10 Design Assurance..........................................................................................................................................................................24
11 Mitigation of Other Attacks .........................................................................................................................................................25
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 4 of 25
1 Introduction
1.1 Purpose
This is a non-proprietary FIPS 140-2 Security Policy for the Vormetric Data Security Manager firmware version 6.0.2 cryptographic
module. It describes how this module meets all the requirements as specified in the FIPS 140-2 Level 2 requirements. This Policy
forms a part of the submission package to the validating lab.
FIPS 140-2 (Federal Information Processing Standards Publication 140-2) specifies the security requirements for a cryptographic
module protecting sensitive information. Based on four security levels for cryptographic modules, this standard identifies
requirements in eleven sections.
1.2 References
This Security Policy describes how this module complies with the eleven sections of the Standard.
For more information on the FIPS 140-2 standard and validation program please refer to the NIST website at
csrc.nist.gov/groups/STM/cmvp/index.html
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 5 of 25
2 Product Description
The Vormetric Data Security Manager is a multi-chip standalone cryptographic module. The Vormetric Data Security Manager is
the central point of management for the Vormetric Data Security product. It manages keys and policies, and controls Vormetric
Transparent Encryption Agents (VTE). These agents contain a Cryptographic Module, which has been validated separately from
this module.
The module implements AES, RSA, ECDSA, NIST SP 800-90A DRBG, SHA-256, SHA-384, SHA-512, HMAC-SHA-256, HMAC-SHA-384
and TLS 1.2 KDF algorithms in the approved mode.
The product meets the overall requirements applicable to Level 2 security for FIPS 140-2, with Key Management, Roles, Services
and Authentication, and Design Assurance meeting the Level 3 requirements.
Table 1 - Module Compliance
2.1 Cryptographic Boundary
The Vormetric Data Security Manager (DSM) is a 1U rack-mount hardware module. The cryptographic boundary is the physical
boundary of the hardware module. The power connectors and the power connector wires in the back, two front empty disk bays
and the disk-bay backplane, empty memory DIMM slots, heat-sink, empty PCI-e slots, USB connector housing and LAN connector
housing near the back of air ventilation, jumper pins, TPM connector, and two SAS cables on the side air ventilation are excluded
components. The removable power supplies and removable front bezel are outside the physical cryptographic boundary. The
physical design of the module is shown in the following illustration:
Security Requirements Section Level
Cryptographic Module Specification 2
Cryptographic Module Ports and Interfaces 2
Roles and Services and Authentication 3
Finite State Machine Model 2
Physical Security 2
Operational Environment N/A
Cryptographic Key Management 3
EMI/EMC 2
Self-Tests 2
Design Assurance 3
Mitigation of Other Attacks N/A
Cryptographic Module Security Policy 2
Overall Level of Certification 2
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 6 of 25
Figure 1 – Hardware Module Cryptographic Boundary (front bezel removed)
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 7 of 25
3 Module Ports and Interfaces
The module is considered to be a multi-chip standalone module designed to meet FIPS 140-2 Level 2 requirements. The module
has the following interfaces
Data Input interface: The network interface cards are defined as the data input interface through which data is input to the
module.
Data Output Interface: The network interface cards are defined as the data output interface through which data is output from
the module.
Control input interface: The power switch, network interface cards, IPMI port, and serial port are interfaces by which the module
can be controlled.
Status output interface: The network interface cards, serial port, the IPMI port, LEDs, and an audible power alarm are status
output interfaces. The LEDs are located as follows: two status LEDs on the front panel for each of the two Ethernet ports on the
rear panel.
Power Interface: Two removable redundant variable DC external power connector (power supplies are shipped with 100-240V), 2
status LEDs.
The following table describes the relationship between the logical and physical interfaces.
FIPS 140-2 Interface Logical Interface Physical Interface
Data Input interface Data input parameters of API
function calls
Ethernet
Data Output interface Data output parameters of API
function calls
Ethernet
Control Input interface Control input parameters of API
function calls that command the
module
Power Switch, Ethernet, Serial port,
IPMI port
Status Output interface Status output parameters of API
function calls that show the status
of the module
Ethernet, Serial port, LED, IPMI port,
audible power alarm
Power Interface Variable DC power connector
(Power supplies shipped with 100-
240V power interface), LEDs
Table 2 – Mapping Physical and Logical Interfaces
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 8 of 25
4 Roles, Services, and Authentication
The Vormetric Data Security Manager module supports five distinct roles: System Administrator, Network Administrator, Domain
Administrator, Security Administrator, and Network User. Within the Security Administrator role there are four sub-roles: audit,
key, policy, and host. The module implements identity based authentication using passwords for the Crypto-Officer accounts. An
optional second factor of authentication is available with an RSA token. 2048-bit RSA certificates or ECDSA P-384 certificates are
used for the “Network user” account – these correspond to a Vormetric Transparent Encryption Agent instance, which is a
separately validated product.
Note: any firmware loaded into this module that is not shown on the module certificate, is out of the scope of this validation and
requires a separate FIPS 140-2 validation
4.1 Identification and Authentication
Role Group Type of
Authentication
Authentication Data
System Administrator Crypto-Officer Identity Based 8-character minimum alphanumeric password plus
optional Two Factor Authentication (TFA) using an
RSA token or LDAP password.
Network Administrator Crypto-Officer Identity Based 8-character minimum alphanumeric password plus
optional TFA using an RSA token
Domain Administrator Crypto-Officer Identity Based 8-character minimum alphanumeric password plus
optional TFA using an RSA token or LDAP password.
Security Administrator Crypto-Officer Identity Based 8-character minimum alphanumeric password plus
optional TFA using an RSA token or LDAP password.
Network User User Identity Based 2048-bit RSA Certificate or ECDSA P-384 Certificate
Table 3 - Authentication Types
4.2 Strengths of Authentication Mechanisms
Authentication
Mechanism
Strength of Mechanism
Username and
password
(+ optional TFA with
RSA token)
The module enforces at minimum 8-character passwords chosen from 76 human readable ASCII
characters. The maximum password length is 256 characters.
The UI module enforces an account lockout after a certain number of failed login attempts. This is
configurable by a System Administrator; the default is that after 3 failed login attempts the account
is locked for 30 minutes. The most lenient that it can be configured is to lock the account for 1
minute after 10 failed login attempts. This leads to a theoretical maximum for an attacker to
attempt password entry 10 times per minute. In addition, the Network Administrator enforces an
account lockout after 5 attempts for CLI access. The deny time is 5 seconds after each failed
attempt. This leads to a theoretical maximum for an attacker to attempt password entry 5 times per
minute. After 5th failed attempts, the CLI account is locked for 5 minutes. CLI lockout time is not
configurable and a process wakes up every 5 minutes to clear the lockout account.
Taking into account that the password policy requires minimum 1 uppercase, 1 numbers, and 1
special character; thus for 8-character password the probability of a successful random attempt is
1/(5.284290x1014). That is less than 1 in 1 million. The probability of success with multiple
consecutive attempts in a one minute period is 10/(5.284290x1014), which is less than 1 in 100,000.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 9 of 25
Authentication
Mechanism
Strength of Mechanism
Two Factor Authentication is also optionally available using RSA tokens. This second factor
decreases the probability of a successful random attempt significantly further.
LDAP username and
password
When an LDAP user is imported as a DSM administrator, the LDAP server's rules
for password length and complexity are used. It is the Crypto-Officer's responsibility to only use a
LDAP server with strong password rules and at least a 8 character password.
Strength of authentication and lockout is the same as the “Username and password” authentication
mechanism.
RSA Certificate The module supports RSA 2048-bit certificates, which have a minimum equivalent computational
resistance to attack of 2112. There is no programmatic limit to the number of attempts in a given
time frame, but it is limited to hardware and network latency. We can use an unrealistically high
rate of one million attempts per second (60 million per minute) for our purposes in this calculation.
Thus the probability of a successful random attempt is 2112, which is less than 1 in 1 million. The
probability of success with multiple consecutive attempts in a one minute period is 60,000,000/2112,
which is less than 1/100,000.
ECDSA Certificate The module supports Elliptical Curve Cryptography P-384 certificates, which have a minimum
equivalent computational resistance to attack of 2192. There is no programmatic limit to the
number of attempts in a given time frame, but it is limited to hardware and network latency. We
can use an unrealistically high rate of one million attempts per second (60 million per minute) for
our purposes in this calculation.
Thus the probability of a successful random attempt is 2192, which is less than 1 in 1 million. The
probability of success with multiple consecutive attempts in a one minute period is 60,000,000/2192,
which is less than 1/100,000.
Table 4 – Strengths of Authentication Mechanisms
4.3 Roles and Services
Roles in the Vormetric Data Security Manager apply to Administrative Domains. An administrative domain is a logical partition
that is used to separate administrators and the data they access from other administrators. Administrative tasks are performed in
each domain based upon each administrator’s assigned role.
- The System Administrator role operates outside of domains. It creates domains and assigns administrators of the
Domain Administrator role to the domains.
- The Domain Administrator role primarily serves to assign administrators into a domain.
- Security Administrators exist inside a domain, and are responsible for managing hosts, policies, keys, and audit settings.
- The Network Administrator role is used for network and system configuration only. It is a special, low-level type of
administrator that does not interact with the other roles.
- The Network User corresponds to an instance of a Vormetric Transparent Encryption Agent.
The Vormetric Data Security Manager supports the services listed in the following table. The table shows the privileges of each
role on a per-service basis. The privileges are divided into:
- R: The item is read or referenced by the service.
- W: The item is written or updated by the service.
- E: The item is executed by the service. (The item is used as part of a cryptographic function.)
The mapping between Authorized Services and Keys can be found in Table 8.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 10 of 25
Authorized Services
System
Administrator
Network
Administrator
Domain
Administrator
Security
Administrator
Network
User
Run Power-On Self-Test E
Show basic status on dashboard R R R
Manage preferences, LDAP, RSA tokens, etc RW R
Email and syslog setup RW RW R
Create and delete administrator accounts; Change and reset passwords RWE RWE
Create and delete accounts from their own domain RWE RWE
Create and delete domains RW R
Assign administrators to domains RW RW
Create, import, export Wrapper Key RWE RWE
Backup and restore RWE RWE
Firmware upgrade RWE RWE
Shutdown, reboot, restart Security Server E
Generate CA certificate RWE
Upload signed web console certificate RWE
Generate server certificate RWE
Configure High Availability (HA) RWE RWE
View, Configure Network Settings RW
Set date, time, NTP, etc RW
Zeroize all data and all key material WE
Create File System Keys (Agent Keys) and Certificates RWE
Create Vault Keys and Certificates RWE
Create Agent Database Backup Keys RWE
Create, modify, and delete file system policies RW
Import and Export file system policies RW
Import and export keys RWE
Create and delete Signatures RW
Create and export Reports RW RWE
View, delete, and export Log RW R RW
Apply guard points using policies (and remove them) RW
Submit a CSR and obtain a certificate RWE
Obtain host/policy/key info RE
Table 5 - Privileges of each role
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 11 of 25
5 Physical Security
The module is a “multiple-chip standalone cryptographic module”. The module consists of production grade components that
include standard passivation techniques. The module is enclosed in an opaque production-grade enclosure with tamper-evident
seals placed on the removable parts of the module to indicate attempts at removing the cryptographic module’s cover and the
hard drives.
Physical
Security
Mechanism
Recommended
Frequency of
Inspection /
Test
Inspection / Test Guidance Details
Tamper
Evident Seals
3 months
There are 3 tamper-evident seals and these are installed only by the module
manufacturer. A System or Network Administrator is required to inspect the
tamper evident seals for visible signs of malice. Upon viewing any signs of
tampering, the administrator must assume that the device has been fully
compromised. The administrator is required to zeroize the cryptographic module
and shall return the device to the factory.
Table 6 – Inspection/Testing of Physical Security Mechanisms
Figure 2a – Location of Tamper-Evident Seals – initial label version
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 12 of 25
Figure 2b – Location of Tamper-Evident Seals – new label version
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 13 of 25
6 Operational Environment
The Vormetric Data Security Manager is a limited operational environment based on Linux. Therefore, section 4.6.1 of the
standard is not applicable.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 14 of 25
7 Cryptographic Key Management
7.1 Cryptographic Keys and CSPs
The following table summarizes the module’s keys and CSPs (Critical Security Parameters):
Key Generation / Input Storage Use
800-90A DRBG Seed Internally gathered - DRBG initialization
800-90A DRBG Entropy Input String Internally gathered - DRBG initialization
800-90A CTR_DRBG “V” Internally gathered - DRBG initialization
800-90A CTR_DRBG “Key” Internally gathered - DRBG initialization
HMAC Integrity Key (HMAC-SHA 256-bit
with 256-bit key)
At vendor facility
Incorporated
into product
Protects the integrity of the module
Certificate Authority
Key (for
TLS Server)
ECDSA P-384
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A Keystore
Signs certificates used when the DSM
acts as a TLS server
2048-bit RSA
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A
Keystore
Signs certificates used when the DSM
acts as a TLS server
Certificate Authority
Key (for TLS Client)
ECDSA P-384
Generated internally
compliant to FIPS 186-
4 using a DRBG
compliant to NIST SP
800-90A
Keystore
Signs certificates used when the DSM
acts as a TLS client
2048-bit RSA
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A
Keystore
Signs certificates used when the DSM
acts as a TLS client.
Server Key (for TLS
Server)
ECDSA P-384
Generated internally
compliant to FIPS 186-
4 using a DRBG
compliant to NIST SP
800-90A
Keystore
Identifies the DSM in a TLS session
when it acts as a TLS server; Key
establishment methodology provides
128 or 192 bits of encryption strength.
2048-bit RSA
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A
Keystore
Identifies the DSM in a TLS session
when it acts as a TLS server; Key
establishment methodology provides
112 bits of encryption strength.
Server Key (for TLS
Client)
ECDSA P-384
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A
Keystore
Identifies the DSM in a TLS session
when it acts as a TLS client; Key
establishment methodology provides
128 or 192 bits of encryption strength.
2048-bit RSA
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Keystore
Identifies the DSM in a TLS session
when it acts as a TLS client; Key
establishment methodology provides
112 bits of encryption strength.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 15 of 25
Web Console Key
ECDSA P-384
Generated internally
compliant to FIPS 186-4
using a DRBG compliant
to NIST SP 800-90A
Keystore
Identifies the DSM to a web
browser: https TLS requests. Key
establishment methodology provides
128 or 192 bits of encryption strength.
2048-bit RSA
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Keystore
Identifies the DSM to a web
browser: https TLS requests. Key
establishment methodology provides
112 bits of encryption strength.
Master Key
AES 256
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Keystore Protects the Protection Key
TLS Pre-master and master secret
Agreed upon using EC
DH or generated by
DRBG and transported
using RSA (depends on
cryptography supported
by the communicating
entities)
Not
applicable.
Session keys
only persist
for the life of
the session.
Negotiated as part of the TLS
handshake. Keys are established
using EC DH or RSA (depends on
cryptography supported by the
communicating entities)
TLS Session Keys
AES 128, AES 256 (Including pre-master
secret and master secret)
Derived using SP 800-
135 TLS KDF from TLS
Master Secret
Not applicable.
Session keys
only persist for
the life of the
session.
Negotiated as part of the TLS
handshake. Keys are established using
EC DH or RSA (depends on
cryptography supported by the
communicating entities)
TLS HMAC Keys
HMAC-SHA-256 / HMAC-SHA-384
Derived using SP 800-
135 TLS KDF from TLS
Master Secret
Not applicable.
Session keys
only persist for
the life of the
session
Used as part of TLS cipher suites
TLS Key Exchange
EC DH 256-bits
EC DH 384-bits
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Not applicable.
Session keys
only persist for
the life of the
session
Negotiated as part of the TLS
handshake using elliptical curve.
Protection Key
AES 256
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Database
Protects symmetric file system keys,
vault keys, RSA keys for agent database
backups, password hashes, backup
wrapper keys The protection key
encrypts the domain key.
Domain Key
AES 256
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Database
The domain key is encrypted by the
protection key and is used to protect
symmetric file system keys, vault keys,
RSA keys for agent database backups,
password hashes, backup wrapper keys
for a defined domain.
Server Wrapper Key
AES 256
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Encrypted and
stored in file
system
Protects DSM backups
Agent Public Key
RSA 2048 bits public key
External Vormetric VTE
agent generated using
DRBG compliant to NIST
SP 800-90A
Database
Protect a single-use File System Key
Protection Key for transport.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 16 of 25
Vormetric Upgrade Verification Key
RSA 2048 bits public key
External generated
using a DRBG compliant
to NIST SP 800-90A and
preloaded.
Obfuscated
and Stored in
file system
Used to verify the uploaded upgrade
package
Symmetric File System Keys
AES 128 and 256, Triple-DES, ARIA
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Database
Encryption keys used by Transparent
Encryption agent. The File System Keys
are encrypted using the Protection Key
before being stored.
Agent Database Backup Keys
RSA
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Database
Encryption keys used by database
backup agent. The Agent Database
backup Keys are encrypted using the
Protection Key before being stored.
Symmetric Vault Keys
AES, Triple-DES, ARIA
Manually entered via
TLS
Database
Customer keys held by the DSM. The
Symmetric Vault Keys are encrypted
using the Protection Key before being
stored.
Asymmetric Vault Keys
RSA
Key entered via TLS Database
Customer keys held by the DSM. The
Asymmetric Vault Keys are encrypted
using the Protection Key before being
stored.
HA Keys (for TLS)
ECDH, AES-256
Generated internally
using a DRBG compliant
to NIST SP 800-90A
Not applicable.
Session keys
only persist for
the life of the
session.
Used as part of TLS cipher suites for
HA.
Table 7 – Keys and CSPs
All of the keys in the above table can be input/output to/from the module except the TLS Session Keys. When services are
configured to use Triple-DES, ARIA keys, or any non-approved algorithms, the services are in non-FIPS approved mode. The web
console key supports both RSA and ECDSA certificates. The web console key is used for authorized services listed in table-5 with
system administrator, domain administrator, and security administrator roles.
The following table shows the keys that are used in the Authorized Services from table 5. Note that the TLS Session Key is used
implicitly in all Authorized Services because TLS is used to connect to the cryptographic module. Note also that Administrator
Passwords are used implicitly in all Authorized Services because the administrators must enter their passwords to perform
actions.
Authorized Service Cryptographic
Key/CSP
Modes of Access
Run Power-On Self-Test N/A N/A
Show basic status on dashboard N/A N/A
Manage preferences, LDAP, RSA tokens,
etc
N/A N/A
Setup email and syslog N/A N/A
Create and delete administrator
accounts; Change and reset passwords
Administrator Passwords
Master Key
Domain key
Account passwords are created by human entry, and
are at least 8 alphanumeric characters. A SHA-256
hash of the password plus a salt is created, encrypted
with the Encryption Key, and stored.
Create and delete domains Protection key N/A
Assign administrators to domains N/A N/A
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 17 of 25
Authorized Service Cryptographic
Key/CSP
Modes of Access
Create, import, export Wrapper Key Server Wrapper Key This is an AES-256 symmetric key used to protect
backup. This key is split in an M-of-N fashion using the
“Shamir's Secret Sharing” scheme.
Backup and restore Server Wrapper Key Backups are encrypted using Server Wrapper Key. This
key is split in an M-of-N fashion using the “Shamir's
Secret Sharing” scheme.
Firmware upgrade Vormetric Upgrade
Verification Key
Upgrade packages are signed by Vormetric in the
factory using this key. The module contains the public
key, which is used to verify the authenticity of the
upgrade package.
Shutdown, reboot, restart Security
Server
N/A N/A
Generate CA certificate Certificate Authority Key
(both keys, as client and as
server),
Keystore Key,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
This key is generated and used to sign other certificates
using RSA 2048 or ECDSA P-384.
Upload signed web console certificate Web Console Key The admin generates a CSR based on this key, has it
signed by an external certificate authority, and uploads
the signed certificate to the DSM
Generate server certificate Server Key
Certificate Authority Key
(both keys, as client and as
server),
Keystore Key,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
The Server Key is generated, and a certificate using
that key is signed by the Certificate Authority Key.
Configure High Availability Server Key (of the failover
node), Master Key,
Protection Key, Keystore
Key, HA Keys (for TLS)
The Protection Key is encrypted with the Master Key of
the Failover Node for transport, and the Protection Key
is stored encrypted with the Master Key.
TLS session keys are negotiated as part of the TLS
handshake and keys are exchanged using EC DH.
View, Configure Network Settings N/A N/A
Set date, time, NTP N/A N/A
Zeroize all data and all key material All All data and key material are destroyed.
Create File System Keys (Agent Keys)
and Certificates
File System Keys,
Domain Key,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
Generation of the File System Keys.
The File System Keys are encrypted using the Domain
Key before being stored.
Create Vault Keys and Certificates Vault Keys, Domain Key,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
Generation of the Vault Keys.
The Vault Keys are encrypted using the Protection Key
before being stored.
Create Agent Database Backup Keys Agent Database Backup
Keys, Domain Key,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
Generation of Agent Database Backup Keys. The Agent
Database Backup Keys are encrypted using the
Protection Key before being stored.
Create, modify, and delete file system
policies
Domain Key N/A
Import and Export file system policies Domain Key N/A
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 18 of 25
Authorized Service Cryptographic
Key/CSP
Modes of Access
Create, modify, and delete agent
database backup policies
Domain Key N/A
Import and export keys Server Wrapper Key
Domain Key
Keys (File System Keys) are encrypted using the Server
Wrapper key during export. During import they’re
decrypted using this key.
Create and delete Signatures N/A N/A
Create and export Reports N/A N/A
View, delete, and export Log N/A N/A
Apply guard points using policies (and
remove them)
Domain Key N/A
Submit a CSR and obtain a certificate Agent Public Key,
Certificate Authority Key
(both keys, as client and as
server), Keystore Key
The Vormetric Transparent Encryption Agent creates a
CSR; it is signed by the Certificate Authority Key using
RSA 2048 or ECDSA P-384.
Obtain host/policy/key info File System Key Protection
Key,
Domain Key,
Agent Public Key,
File System Keys,
800-90A CTR_DRBG “V”,
800-90A CTR_DRBG “Key”
A single-use File System Key Protection Key is
generated. It is used to encrypt the File System Keys.
It is itself encrypted by the Agent Public Key for
transport.
Table 8 - Mapping of Cryptographic Keys and CSPs to Services
7.2 Key Destruction/Zeroization
All key material can be zeroized by any administrator with the Network Administrator role. When this action is performed, all key
material and CSPs are removed, and the system enters a state that is indistinguishable from the state in which it was shipped to
the customer.
7.3 Approved or Allowed Security Functions
7.3.1 Approved security functions
The module keys map to the following algorithms certificates:
CAVP
Cert
Algorithm Standard Mode/Method Key
Lengths,
Curves
or
Moduli
Use
4845 AES FIPS 197,
SP 800-38A
SP 800-38D
CBC, GCM 128, 256 Data Encryption/ Decryption
(Java)
5535 AES FIPS 197,
SP 800-38A
SP 800-38D
CBC, GCM 1281, 256 Data Encryption/Decryption
(OpenSSL)
3986 SHS FIPS 180-4 SHA-256, SHA-384,
SHA-512
- Message Digest
(Java)
1
AES-128 is CAVP tested but is not used by the module
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 19 of 25
4442 SHS FIPS 180-4 SHA-256, SHA-384 - Message Digest (OpenSSL)
3245 HMAC FIPS 198-1 HMAC-SHA-256,
HMAC-SHA-384
256 Message Authentication
(Java – used for TLS integrity check)
3687 HMAC FIPS 198-1 HMAC-SHA-256,
HMAC-SHA-3842
256 Message Authentication
(OpenSSL – used for software integrity
check)
2663 RSA FIPS 186-4 SHA-256, SHA-384,
SHA-512
PKCS1 v1.5
2048 Key pair generation
Digital Signature generation and
verification PKCS1.5
2969 RSA FIPS 186-4 SHA-256, SHA-384
PKCS1 v1.5
2048 Key Generation, Digital Signature
Generation and Verification used for
OpenSSL
1239 ECDSA FIPS 186-4 SHA-256, SHA-384 P-256,
P-384
Key pair generation, Digital Signature
Generation and verification
1702 DRBG NIST SP 800-90A CTR-DRBG Deterministic Random Bit Generation.
Derivation function used.
N/A CKG SP 800-133 - - Generate symmetric keys and
asymmetric key generation seeds (the
result is an unmodified output from
DRBG)
N/A KTS SP800-38F AES GCM certificate
4845 and HMAC
certificate 3245
128, 256 Key transport through TLS (import and
export)
Key establishment methodology
provides 128 or 256 bits of encryption
strength.
AES GCM certificate
5535
256 Key transport through TLS (import and
export) for HA
1481 CVL TLS 1.2 KDF SP800-135 - - TLS KDF used for Java
1978 CVL TLS 1.2 KDF SP800-135 - - TLS KDF used for OpenSSL
Table 9 – Approved security function
The module uses AES GCM within TLS v1.2 with GCM ciphersuites from SP 800-52 Rev 1, Section 3.3.1. In compliance with RFC
5246 when the IV exhausts the maximum number of possible values for a given session key a new handshake is triggered.
This module does not use any mode or key lengths not included in Table 9. The firmware module supports non-deterministic
random number generator (NDRNG) that uses internal, unpredictable physical sources of entropy that are outside of human
control. Random numbers generated by the NDRNG are used as entropy source for the FIPS approved random number generator
(DRBG cert #1702), NDRNG provides it at least 256 bits of entropy. There is no assurance of the minimum strength of generated
keys if porting to an untested platform. When services are configured to use any non-compliant algorithms, the services are in
non-FIPS approved mode.
7.3.2 Allowed security functions
Algorithm Caveat Use
NDRNG Entropy source for SP 800-
90A DRBG
RSA key wrapping Provides 112 bits of encryption strength Key establishment
Elliptic Curve Diffie-Hellman,
Supported curves: P-256 and P-
384
Provides 128 or 192 bits of encryption strength Key agreement, Key
establishment. Used for TLS
and TLS for HA.
2
HMAC SHA-384 is CAVP tested but is not used by the module.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 20 of 25
Table 10 – Allowed security function
7.3.3 Non-Approved Algorithms
Algorithm Use
Triple-DES (non-compliant) Encryption / Decryption
RSA 1024, RSA 4096 (non-compliant) Key generation
ARIA, Key size = 128 and 256 bits (non-compliant) Key generation
SSH KDF (non-compliant) SSH shall not be used in an approved mode of operation.
Table 11 – Non-Approved Algorithms
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 21 of 25
7.3.4 TLS Cipher Suites
Algorithm Supported TLS Cipher Suites
TLS Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE-RSA-AES256-GCM-SHA384
Table 12 – Supported TLS Cipher Suites
Note that TLS protocol, other than the KDF, has not been reviewed or tested by the CAVP and CMVP."
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 22 of 25
8 Self-Tests
The module performs power-up self-tests and conditional self-tests.
8.1 Power-Up Self-Tests
The power-up self-tests are performed upon module startup before any data or control interface being available. All other
processing is inhibited while the tests are in progress. If any test fails, an error status such as “FIPS Integrity Check Failed;
Appliance Halting” and “Self Test in progress: failed. Security Server cannot continue” are displayed to the serial console and IPMI
console, and the module will immediately power off. When all tests run to completion, the message “FIPS Integrity Check
Completed OK” and “Self Test in progress: passed” are displayed to the serial port console and IPMI console, and the module
continues normal startup.
See the serial console or IPMI console for self-test results.
Cryptographic Algorithm KATs:
Known Answer Tests (KATs) are run at power-up for:
- AES for OpenSSL
- AES for Java
- RSA (Sign KAT and Verify KAT) for OpenSSL
- RSA (Sign KAT and Verify KAT) for TLS for HA
- ECDSA (Sign KAT and Verify KAT)
- SHA-256, SHA-384 for OpenSSL
- SHA-256, SHA-384 for Java
- HMAC_SHA256 for Java
- HMAC_SHA256, HMAC_SHA384 for OpenSSL
- DRBG (Instantiate, Reseed, Generate KAT) for OpenSSL
Firmware Integrity Tests:
The module checks the integrity of its components using HMAC-SHA-256 during power on.
8.2 Conditional Self-Tests
The module performs the following conditional self-tests:
Firmware Load Test:
This test is run when the firmware is upgraded to verify that the firmware came from a trusted source and hasn’t been modified
during delivery and installation. It uses RSA signature verification using an RSA 2048-bit key.
Continuous RNG Test:
A continuous RNG test (that is, ensuring that two successive outputs from the RNG are not equal) is performed each time a
pseudo-random number is requested. The same test is applied to the source of entropy.
Pairwise Consistency Test:
Pairwise consistency tests are run automatically when the module generates RSA key pairs. The module performs a sign
operation with the private key and verifies it with the public key.
Pairwise consistency tests are run automatically when the module generates ECDSA key pairs. The module performs a sign
operation with the private key and verifies it with the public key.
Manual Key Entry Test:
Manual key entry is one way to create a File System Key. When manual key entry is used, the key is entered twice and the two
entries are verified to be the same.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 23 of 25
9 Crypto-Officer and User Guidance
This section describes the configuration, maintenance, and administration of the cryptographic module.
9.1 Secure Setup and Initialization
The following steps must be taken to securely initialize the module:
- A user in the Network Administrator role must log into CLI as the default user “cliadmin” and an immediate password
change is required
- A user in the Network Administrator role must configure networking so that the module has a valid IP address and host
name
- A user in the Network Administrator role must generate a CA certificate
- A user in the System Administrator role must log into the UI as the default user “admin”; an immediate password
change is required
- A user in the Network Administrator role shall enable TLS for HA before any High Availability is configured.
9.2 Module Security Policy Rules
The module operates in FIPS mode after all the power up self-test have passed and the message described in section 8.1 has
been displayed. Note that to operate in FIPS mode TLS for High Availability must be enabled. When operated in FIPS mode,
crypto-officer must ensure it is only using approved security functions.
The module uses AES GCM only within TLS v1.2 and this automatically enforces the IG A.5 IV restoration condition 3 where a new
key for the AES GCM encryption/decryption is established in the case where the module’s power is lost and then restored.
Note: network administrator shall not enable TLS1.0/1.1 support.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 24 of 25
10 Design Assurance
Vormetric uses Subversion (SVN) for configuration management of product source code. Vormetric also uses Confluence, an
internal wiki for configuration management of functional specifications and documentation. Both support authentication, access
control, and logging. A high-level language is used for all firmware components within the module.
Copyright 2019 Thales eSecurity. All Rights Reserved. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
THALES ESECURITY
Page 25 of 25
11 Mitigation of Other Attacks
The module does not mitigate against any specific attacks.