FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
Pitney Bowes, Inc.
X4i Hardware Security Module
(HSM)
FIPS 140-2 Non-Proprietary Security Policy
Document Version 1.3
© Copyright 2021
Pitney Bowes, Inc.
27 Waterview Drive
Shelton, CT 06484
May be reproduced only in its original entirety [without revision].
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
1
TABLE OF CONTENTS
1. Cryptographic Module Specification....................................................................................................3
1.1 Overview....................................................................................................................................................3
1.2 Security Level...........................................................................................................................................4
1.3 Modes of Operation................................................................................................................................4
2. Module Ports and Interfaces ...................................................................................................................5
3. Roles, Services, and Authentication......................................................................................................5
3.1 Roles.............................................................................................................................................................5
3.1.1 Initialization.......................................................................................................................................6
3.2 Services.......................................................................................................................................................6
3.2.1 Service Access to Security Functions and CSPs ...................................................................8
3.3 Non-Approved Mode Roles and Services ................................................................................... 11
3.4 Security Rules........................................................................................................................................ 11
4. Physical Security....................................................................................................................................... 12
5. Mitigation of Other Attacks................................................................................................................... 12
6. Operational Environment...................................................................................................................... 12
7. Cryptographic Key Management........................................................................................................ 13
7.1 FIPS Approved Algorithms............................................................................................................... 13
7.2 FIPS Allowed Algorithms.................................................................................................................. 15
7.3 FIPS Non-Approved Algorithms..................................................................................................... 15
7.4 CSPs and Keys ....................................................................................................................................... 16
7.4.1 Critical Security Parameters..................................................................................................... 16
7.4.2 Public Security Parameters Keys............................................................................................ 18
7.4.3 Zeroization...................................................................................................................................... 19
8. Self-Tests...................................................................................................................................................... 19
8.1 Power on Self-Tests ............................................................................................................................ 19
8.2 Conditional Tests................................................................................................................................. 20
Appendix A: References................................................................................................................................... 21
Appendix B: Abbreviations and Definitions ............................................................................................ 22
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
2
TABLE OF TABLES
Table 1 – X4i Hardware Security Module (HSM) Component Versions............................................................ 3
Table 2 – Module Security Level........................................................................................................................................ 4
Table 3 – Roles and Authentication................................................................................................................................. 5
Table 4 – Strength of Authentication............................................................................................................................... 6
Table 5 – Services Available in FIPS Approved Mode .............................................................................................. 8
Table 6 – FIPS Approved Algorithms ............................................................................................................................13
Table 7 – FIPS Non-Approved Algorithms..................................................................................................................15
Table 8 – Secret Keys, Private Keys, Cryptographic Key Components, and Other CSPs ..........................16
Table 9 – Public Security Parameters ...........................................................................................................................18
Table 10 – References..........................................................................................................................................................21
Table 11 – Abbreviations and Definitions...................................................................................................................22
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
3
1. CRYPTOGRAPHIC MODULE SPECIFICATION
1.1 OVERVIEW
This document describes the Security Policy for the X4i Hardware Security Module (HSM) (the X4i
HSM). The X4i HSM is a single-chip cryptographic module designed by Pitney Bowes, Inc. (PB) to
conform with FIPS 140-2 Level 3 + EFP requirements.
Table 1 – X4i Hardware Security Module (HSM) Component Versions
Item Version
Hardware Components:
MAX32590 Secure Microcontroller Revision B4
Firmware Components:
PB Bootloader 00.00.0016
HSM Application
Device Abstraction Layer (DAL)
21.04.0008
01.02.002F
The HSM Application and DAL are compiled into a single firmware and integrity tested together.
This single firmware is referred to as the HSM Application hereafter.
The X4i HSM provides cryptographic services to a host device, including authentication, privacy,
and key protection.
The X4i HSM is defined as a single chip cryptographic module.
Figure 1 – MAX32590 (Back and Front)
The X4i HSM’s cryptographic boundary is defined as the IC package that comprises the Maxim
Integrated MAX32590 DeepCover Secure Microcontroller (refer to Figure 1). PB executable code is
stored in external memory and copied to internal SRAM to be executed. On each power up, the
firmware components listed in Table 1 are copied to internal SRAM and then authenticated via
digital signatures.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
4
The PB Bootloader is authenticated by verification of the “CRK” key using RSA 2048 with SHA-256
(Cert. #C477). Once the PB Bootloader has been loaded and authenticated, the PB Bootloader copies
HSM Application (i.e., the combined Device Abstraction Layer (DAL) and HSM Application) to SRAM
and authenticates it by verification of the “SWAK” Key using ECDSA P-256 with SHA-256 (Cert.
#C476).
1.2 SECURITY LEVEL
The module meets the overall requirements of FIPS 140-2 Security Level 3 +EFP
Table 2 – Module Security Level
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 +EFP
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 3
1.3 MODES OF OPERATION
The module supports both an Approved mode and a non-Approved mode of operation. The module
provides an explicit mode of operation indicator: the FIPS mode status flag is returned in every
response from the module. The FIPS mode flag is set to zero for an Approved mode of operation or
to one for non-Approved mode of operation.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
5
2. MODULE PORTS AND INTERFACES
The MAX32590 is supplied in a 324-pin BGA package where all power input, data input, data
output, control input, and status output interfaces are supported.
Ball Grid Array Pin Horizontal from “x”
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ball
Grid
Array
Pin
Vertical
from
“
x”
A - - - - - - O - - - - - - - - - - -
B - - - - - - I - - - - - - - - - - -
C - - P - - - - - - - - - - - - - - -
D - - P - - - - - - - - - - - - - - -
E - - - - - - - - - - - - - - - - - -
F - - - - - P P P P P P P IO IO - - - -
G - - - - S P - - - - - P C - - - - -
H - - - - P P - - - - - P S - - - - -
J - - - - C P - - - - - P C - - - - -
K - - - - C P - - - - - P C - - - - -
L - - - - - P - - - - - P - - - - - -
M - - - S - P - - - - - P - - - - - -
N - - - - - P P P P P P P - S - - S S
P - - - O - O O O O O O - O O O O O O
R - - - - - - - - - IO IO IO IO O O O O O
T - - - - - - - - - IO IO IO IO - O O O O
U - - - - - - - - - IO IO IO IO - - O O O
V - - - - - - - - - IO IO IO IO - - O O O
I = Data In O = Data Out S = Status Out C = Control In P = Power - = Disabled
Figure 2 – X4i HSM Interface Mapping
3. ROLES, SERVICES, AND AUTHENTICATION
3.1 ROLES
The module supports two authenticated roles that are either categorized as Crypto-Officer (CO)
Administrator, or CO/User role. Additionally, the module has a single unauthenticated role. The CO
Admin role is implicitly selected and authenticated via digital signature. The CO/User identities are
implicitly selected by a unique ID and possession of the respective HMAC key used for
authentication.
Table 3 – Roles and Authentication
Role Authentication Method Authentication Type
Crypto-Officer Administrator
(CO Admin)
Digital Signature (ECDSA P-256) authenticated by PAK Identity-based
Crypto-Officer/User
(CO/User)
Uniquely Assigned ID in conjunction with HMAC key (128
bits – 256 bits) used with HMAC-SHA-256
Identity-based
Unauthenticated None None
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
6
Table 4 – Strength of Authentication
Authentication Mechanism
Probability of False Acceptance
(Single Attempt)
Probability of False Acceptance
(One Minute)
Digital Signature The probability of a random access or
false acceptance occurring is 1 in
2^128 for ECDSA P-256, which is less
than 1 in 1,000,000.
The module can execute at most 17.85
ECDSA verifications per second. Therefore,
the probability of a successful random
attempt in a one-minute period is 17.85 in
2^128 for ECDSA, which is far less than 1 in
100,000.
Uniquely Assigned ID and HMAC
key
A 128-bit to 256-bit HMAC key
(PSWD) is used for authentication.
(Per SP 800-63B, HMAC keys are used
to sign a 64-bit challenge nonce, which
is authenticated by the module.) Given
the strength of the HMAC key, the
probability of a random access or false
acceptance occurring is 1 in 2^128,
which is less than 1 in 1,000,000.
Password verification relies on HMAC
authentication. The module can execute at
most 3,000 HMAC authentication attempts
per second. Therefore, the probability of a
successful random attempt in a one-minute
period is 3000 in 2^128 which is far less
than 1 in 100,000.
3.1.1 INITIALIZATION
During manufacturing, the PB Bootloader (verified by CRK key) and HSM application (verified by
the SWAK key) are loaded at secure vendor facilities. The system is initialized. Initialization
includes loading the entropy input, which is not persistently stored. The entropy input is 512 total
bits and contains 419 bits of entropy. The entropy is generated by a FIPS module validated with an
entropy rate of 82%. Per IG 7.14, there is no assurance of the minimum strength of generated keys.
The DRBG seed, KEK (Key Encryption Key) and KAK (Key Authentication Key) are generated. The
mode of operation is locked to Approved mode unless changed via a HSM LoadParameter command
before additional keys are loaded or generated. Signed public keys, the Device Authentication Keys
(DAK) and Device Privacy Key (DPK) are loaded and verified1. The module is now configured.
3.2 SERVICES
Crypto-Officer Administrator (CO Admin):
The services allocated to this role are as follows:
• Load Parameters: Load a set of parameters into the HSM.
• Firmware Update2: Secure firmware update process using the Software Download Utility
(SDU) within the Device Abstraction Layer (DAL). The PB Bootloader verifies the ECDSA P-
256 (Cert. #C476) signature on the combined HSM Application and DAL firmware.
Crypto-Officer/User (CO/User):
The same services are allocated to these roles. These services are as follows:
• Decrypt: Decrypt data.
• Decrypt Compare: Decrypt encrypted data and compare to expected result.
1 The DAK and DPK are generated for modules configured as a Key Root Authority (KRA) HSMs
2 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
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
7
• Decrypt Encrypt: Decrypt encrypted data and re-encrypt with another key.
• Delay Echo: Respond with input message after delay.
• Delete Key: Remove a key from the HSM.
• Delete Key Parameter: Remove a key parameter from the HSM.
• Derive Key Agreement: Establish a key to be used to exchange secure information with the
HSM (AES 128/192/256 KW or HMAC-SHA-256).
• Encrypt: Encrypt data.
• Encrypt Nonce: Generate a nonce (if not passed in) and then encrypt the nonce.
• Export Key: Securely export a key for storage / use in another location.
• Generate: Generate a public/private key pair or a secret key. The message specifies the
cryptographic algorithm and the parameters for use in the generation of the key(s).
• Generate Password Block: Generate a HMAC-SHA-256 password for a specific HSM.
• Generate Password Token: Generate a token used to login to a specific HSM.
• Generate PSD RSA Record: Generate an RSA public/private key pair for a Postal Security
Device (PSD).
• Generate RSA Primes: Generate a pair of prime numbers used for RSA key generation.
• Get Counters: Output a copy of the current values of the internal counters.
• Join Key: Assemble a key that has been previously split.
• Load Key: Load an encrypted or public key for later use. The command specifies the storage
type:
o Volatile: Store in RAM, can be replaced if space is needed.
o Sticky: Store in RAM, can NOT be replaced until it is deleted by the host.
o Static: Store in NVM
• Load Key Parameters – Load a set of key parameters for later use, stored in NVM.
• Load Parameters: Load a set of parameters into the HSM.
• Load Password Block: Loads a HMAC-SHA-256 password.
• Set Counter: Set an internal counter to a specific value.
• Sign: Apply a cryptographic signature to a set of data.
• Split: Divide a key into 2 or more parts.
• Update Counters: Update specific internal counters
• Verify: Verify a cryptographic signature on a set of data.
Unauthenticated Services:
Miscellaneous functions that do not require the HSM authentication of the entity. Unauthenticated
Services (listed below) are available to all roles, both authenticated and unauthenticated.
• Get Challenge: Get 8-byte pseudo-random number used as a challenge in a future command.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
8
• Get HW Status: Get the hardware specific status data of the HSM.
• Get Key List: Return a list of all active keys stored in the HSM.
• Get Key Parameters: Retrieve list of key parameters loaded into HSM.
• Get Key Table: Retrieves data of key and key parameters stored in key table.
• Get Parameters: Retrieve parameter values from the HSM. The Host can request individual
parameter IDs or all of the stored parameters in the HSM.
• Get Random: Get a pseudo-random number from the HSM.
• Get Status: Get HSM status information.
• Get Versions: Get the versions of the components in the HSM
• Login: Crypto-Officer login with ID and authentication token
• Perform Diagnostic Test: Perform one or more diagnostic tests.
• Perform Full Diagnostics: Run power up tests and perform other maintenance activities.
• Read Log: Get Log Data. The number of available entries, the size of each entry, and the data
contained in each entry will depend on the log that is being requested.
• Reboot: Reboot the device.
• Reinit: Reinitialize HSM by erasing all NVM data except for HW Mfg Data and ‘persistent’ data
(total device cycles, reinit count) and then invalidates the HSM Application. This command
zeroizes the unique HSM Key Encryption Key (KEK), which results in the loss of all other private
and secret keys. Used to ‘clean’ the HSM so it can be re-configured.
3.2.1 SERVICE ACCESS TO SECURITY FUNCTIONS AND CSPS
Critical Security Parameter (CSP) and Public Security Parameter (PSP) access by services is
classified as Read (R), Write (W), or Zeroize (Z) in the table below.
Table 5 – Services Available in FIPS Approved Mode
Role(s) with
Service Access
Service Security Functions Used CSP Access PSP Access
CO Admin Load Parameters ECDSA P-256 SigVer None PAK: R
Firmware Update ECDSA P-256 SigVer None SWAK: R
CO/User All services with
CSP access
HMAC-SHA-256
AES 256 KW
KAK: R
KEK: R
-
Decrypt HMAC-SHA-256 or
AES 128/192/256 or
RSA 2048
Session Key: R or
PK: R or
DPK: R
None
Decrypt Compare HMAC-SHA-256 or
AES 128/192/256 or
RSA 2048
Session Key: R or
PK: R or
DPK: R
None
Decrypt Encrypt HMAC-SHA-256 or
AES 128/192/256 or
RSA 2048
Session Key: R or
PK: R or
DPK: R
PK Public: R
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
9
Role(s) with
Service Access
Service Security Functions Used CSP Access PSP Access
Delay Echo No additional No additional None
Delete Key No additional All static keys except DAK,
KEK, KEK’, KAK: Z
All static public
keys: Z
Delete Key
Parameter
No additional No additional None
Derive Key
Agreement
DRBG
KAS-SSC
KDA
HMAC-SHA-256 or
AES 128/192/256 (KW only)
DRBG Working State: R, W
ECC-CDH Key: W, R, Z
Shared Secret: W, R, Z
Session Key: W, R
ECC-CDH Peer
Public Key: W, R
ECC-CDH Public
Key: W, R
Encrypt HMAC-SHA-256 or
AES 128/192/256 or
RSA 2048
Session Key: R or
PK: R or
DPK: R
PK Public: R
Encrypt Nonce DRBG
HMAC-SHA-256 or
AES 128/192/256 or
RSA 2048
DRBG Working State: R, W
Session Key: R or
PK: R or
DPK: R
PK Public: R
Export Key HMAC-SHA-256
AES 128/192/256 (KW only)
All static keys except KEK,
KEK’, KAK: R
All static public
keys: R
Generate DRBG
ECDSA P-224/P-256 KeyGen
or
RSA 2048 Key Gen or
AES 128/192/256 Key Gen or
HMAC-SHA-256 Key Gen
DRBG Working State: R, W
AK: W or
PK: W or
DAK: W3 or
DPK: W or
CRK Private: W or
SWAK Private: W or
PAK Private: W
AK Public: W or
PK Public: W or
CRK Public: W4
or
SWAK Public: W
or
PAK Public: W
Generate
Password Block
DRBG
HMAC-SHA-256 Key Gen
HMAC-SHA-256
AES 128/192/256 (KW only)
DRBG Working State: R, W
All static keys except KEK,
KEK’, KAK: R
All static public
keys: R
Generate
Password Token
HMAC-SHA-256 PSDW: R None
Generate PSD RSA
Record
DRBG
RSA 2048 SigGen
HMAC-SHA-256
AES 128/192/256 (KW only)
DRBG Working State: R, W
DPAG Private: W
Session Key: R
DPAG Public: W
3 DAK, DPK, CRK, SWAK, and PAK keys are only generated in modules configured as KRA HSMs
4 CRK, SWAK, and PAK keys are only generated in modules configured as KRA HSMs
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
10
Role(s) with
Service Access
Service Security Functions Used CSP Access PSP Access
Generate RSA
Primes
DRBG
RSA 2048 SigGen
HMAC-SHA-256
AES 128/192/256 (KW only)
DRBG Working State: R, W
RSA Primes: W
Session Key: R
None
Get Counters HMAC-SHA-256
ECDSA P-224/P-256 SigGen
or
RSA 2048 SigGen
AK: R AK Public: R
Join Key AES 256 KW
ECDSA P-256 SigVer
PK: W AK: R
Load Key HMAC-SHA-256 or
AES 128/192/256
ECDSA P-224/P-256 SigVer
Session Key: R or
PK: R or
DPK: R
All static keys except KEK,
KEK’, KAK: W5
RSA primes: W
AK Public: R
All static public
keys: W6
Load Key
Parameters
HMAC-SHA-256 or
AES 128/192/256
ECDSA P-224/P-256
SigVer
Session Key: R or
PK: R or
DPK: R
AK Public: R
Load Parameters ECDSA P-256 SigVer No additional PAK: R
Load Password
Block
HMAC-SHA-256
AES 128/192/256
PSWD: W AK: R
PK : R
DAK: R
PAK :R
Set Counter No additional No additional None
Sign DRBG
ECDSA P-224/P-256 SigGen
or
RSA 2048 SigGen or
HMAC-SHA-256
DRBG Working State: R, W
AK: R or
CRK Private: R or
SWAK: R or
PAK: R
None
Split DRBG
ECDSA P-256 SigGen
DRBG Working State: R, W
AK: R
PK: W
None
Update Counters No additional No additional None
Verify ECDSA P-224/P-256 SigVer
or
RSA 2048 SigVer or
HMAC-SHA-256
AK: R AK Public: R or
CRK Public: R or
SWAK Public: R
or
PAK Public: R
Unauthenticated
User
Get Challenge None DRBG Working State: R, W None
Get HW Status None None None
5 DAK, DPK, CRK, SWAK, and PAK keys are only loaded in Manufacturing
6 CRK, SWAK, and PAK keys are only loaded in Manufacturing
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
11
Role(s) with
Service Access
Service Security Functions Used CSP Access PSP Access
Get Key List None None None
Get Key
Parameters
None None None
Get Key Table None None None
Get Parameters None None None
Get Random DRBG DRBG Working State: R, W None
Get Status None None None
Get Versions None None None
Login HMAC-SHA-256 PSWD: R None
Perform
Diagnostic Test
None None None
Perform Full
Diagnostics
None None None
Read Log None None None
Reboot None None None
Reinit None KEK: Z None
3.3 NON-APPROVED MODE ROLES AND SERVICES
The non-Approved Mode of the module implements the same roles and services as the Approved
Mode of operations, but this mode also allows the use of the algorithms specified in Section 7.3 FIPS
Non-Approved Algorithms. Additionally, non-Approved mode includes the following services:
Crypto-Officer/User (CO/User):
• Decrypt Conv Encrypt: Decrypts, converts legacy records and re-encrypts.
• Derive Key: Establish a Triple DES key to be used to exchange information between a PSD
and a Post.
• Get Entropy: Retrieves data from the hardware TRNG.
3.4 SECURITY RULES
This section documents the security rules enforced by the cryptographic module to implement the
security requirements of a FIPS 140-2 Level 3 Module.
• The module shall not process more than one request at a time (i.e., single threaded). While
processing a transaction, prior to returning a response, the module will ignore all other inputs
to the module. No output is performed until the transaction is completed, and the only output is
the transaction response.
• The module shall validate identities using digital signatures or unique IDs and Message
Authentication Codes (MACs) using unique HMAC keys for each identity
• All keys generated in the module shall have at least 112 bits of cryptographic security strength
for an Approved mode of operation.
• The module shall not provide a bypass state where plaintext information is passed through the
module.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
12
• The module shall not support a maintenance mode.
• The module shall not output any secret or private key in plaintext form.
• The module shall not accept any secret or private key in plaintext form outside of
manufacturing.
• There shall be no manual entry of keys into the system.
• There shall be no entry or output of split shared keys from the module except when it is
configured as a Key Root Authority (KRA).
• Keys shall be established via an Approved method or entered into the system through FIPS
Approved processes.
• Once a module has been zeroized, it must be returned to the factory for software loading and
parameterizing prior to being usable by a customer.
4. PHYSICAL SECURITY
The X4i HSM utilizes the Maxim Semi-Conductor MAX32590 micro-controller, a single chip
cryptographic module that protects key material from unauthorized disclosure, modification or
substitution. The module is conformant to FIPS 140-2 Level 3 physical security requirements and is
protected by an encapsulant. The hardness of the module encapsulant was tested at room
temperature and over the module’s documented operating temperature range from -40˚C to + 85˚C.
In addition to Level 3 physical security features, the module includes real time environmental
monitoring (temperature, battery, voltage), and tamper detection and response. Triggering the
environmental failure protection mechanisms or damaging the active shield (tamper detection)
that protects the entire module results in a tamper event. A tamper event halts the processor and
automatically zeroizes the master key encryption key (KEK).
The operator should periodically inspect the module for evidence of tampering.
5. MITIGATION OF OTHER ATTACKS
The module has been designed to mitigate specific attacks outside the scope of FIPS 140-2, Level 3.
It incorporates environmental failure protection mechanisms inherent to a Level 4 module. The
module is designed to defend against out of bound voltage and temperature extremes. Additionally,
the module provides a tamper detection and response mechanism.
6. OPERATIONAL ENVIRONMENT
The FIPS 140-2 Area 6 (Operational Environment) requirements for the module are not applicable
because the device does not contain a modifiable operational environment.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
13
7. CRYPTOGRAPHIC KEY MANAGEMENT
7.1 FIPS APPROVED ALGORITHMS
The following FIPS Approved cryptographic algorithms listed in Table 6 are supported by the
module.
Table 6 – FIPS Approved Algorithms
CAVP
Certs
Algorithm Standards
Modes/
Methods
Key Lengths, Curves,
or Moduli
Use
5954 AES FIPS 197
SP 800-38A
SP 800-38F
CBC, ECB, KW 256, 192, 128 Data encryption and
decryption
Cryptographic key
wrapping and unwrapping
(KTS key establishment
providing 256 bits of
encryption)
Vendor
Affirmed
CKG SP 800-133r2 Symmetric key generation
and asymmetric seed
generation from the
unmodified output of the
DRBG
C472 DRBG SP 800-90A HASH_DRBG Deterministic Random Bit
Generator with 256-bit
security strength. DRBG
does not support reseed.
The entropy input pre-
loaded into the module in
manufacturing. The
entropy input is 512 total
bits and contains 419 bits
of entropy. The entropy is
generated by a FIPS
module validated with an
entropy rate of 82%. Per
IG 7.14, there is no
assurance of the minimum
strength of generated keys.
C476 ECDSA FIPS 186-4 KeyGen
SigGen
SigVer
P-2247
P-256
P-224, SHA-256
P-256, SHA-256
P-224, SHA-256
P-256, SHA-256
Generation of
cryptographic key pairs,
and digital signature
generation and
verification.
7 The following ECDSA functionality is included in the algorithm certificate, but is not used in Approved mode:
SigGen Component; SigVer (P-192, SHA-1)
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
14
CAVP
Certs
Algorithm Standards
Modes/
Methods
Key Lengths, Curves,
or Moduli
Use
C464 HMAC FIPS 198-1 HMAC-SHA-
2568
256 bits Used to generate Message
Authentication Codes
(MACs). Truncated MACs
(at least 128 bits) are used
for some applications.
A1869 KAS-SSC SP 800-56Ar3 ECC P-256 Key Agreement Protocol
used to establish a session
key (Ephemeral Unified
Model C (2e, 0s, ECC
CDH)). Provides 128 bits of
encryption strength.
A1869 KDA SP 800-56Cr1 One-Step KDF SHA-256 Key Derivation Function
used with KAS-SSC to
establish a session key
KTS (AES Cert. #5954) SP 800-38F AES KW 128, 192, 256 Protects exported keys.
Key establishment
methodology provides
between 128 and 256 bits
of encryption strength.
KTS (AES Cert. #5954
and HMAC Cert. #C464)
SP 800-38F AES CBC 256
HMAC-SHA-256
256 Protects CSPs stored in
Non-Volatile Memory
(NVM) external to the
module (using KEK and
KAK keys)
Provides 256 bits of
encryption strength.
C477 RSA FIPS 186-4 KeyGen
SigGen
(ANSI X9.31,
PKCS 1.5,
PKCSPSS)
SigVer
(ANSI X9.31,
PKCS 1.5,
PKCSPSS)
20489
2048, SHA-256
2048, SHA-256
Generation of
cryptographic key pairs,
digital signature
generation and
verification, and data
encryption and decryption.
C295 SHS FIPS 180-4 SHA-224
SHA-25610
SHS provides the hashing
algorithm necessary for
ECDSA and RSA digital
signature generation/
verification and for the key
derivation function
8 HMAC-SHA-1 is included in the algorithm certificate, but is not used in Approved mode
9 The following RSA functionality is included in the algorithm certificate, but is not used in Approved mode:
SigVer ANSI X9.31 (1024, SHA-1 and SHA-256); SigVer PKCS 1.5 (1024, SHA-1 and SHA-256); SigVer PKCSPSS
(1024, SHA-1 and SHA-256) and (2048, SHA-1)
10 SHA-1 is included in the algorithm certificate, but is not used in Approved mode
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
15
7.2 FIPS ALLOWED ALGORITHMS
The module does not support any non-Approved but Allowed security functions.
7.3 FIPS NON-APPROVED ALGORITHMS
The following cryptographic algorithms listed in Table 7 are used solely in a non-Approved mode of
operation (this includes specified CAVP-validated algorithms). There exists no mechanism to allow
the use of these algorithms in an Approved mode of operation.
Table 7 – FIPS Non-Approved Algorithms
Algorithm Key Lengths, Curves, or Moduli Use
KAS (non-compliant) 1024 FFC KAS used to establish a Triple DES
session key
DSA (non-compliant) KeyGen:
(1024, 160)
SigGen:
(1024, 160, SHA-1)
SigVer:
(1024, 160, SHA-1)
Used to generate key pairs and
generate/verify digital signatures. Legacy
verification validated by CAVP DSA Cert.
#C475.
ECDSA (non-compliant) KeyGen:
P-160
P-192
SigGen:
P-160, SHA-1
P-192, SHA-1
SigVer:
P-160, SHA-1
P-192, SHA-1
Used to generate key pairs and
generate/verify digital signatures. Legacy
verification of P-192, SHA-1 validated by
CAVP Cert. #C476.
HMAC (non-compliant) HMAC-SHA-1 Validated by CAVP Cert. #C464
NDRNG (non-compliant) -- Used to seed the DRBG in a non-Approved
mode of operation
RSA (non-compliant) KeyGen:
1024
SigGen ANSI X9.31, PKCS 1.5, PKCSPSS:
(1024, SHA-1)
SigVer ANSI X9.31, PKCS 1.5, PKCSPSS:
(1024, SHA-1)
Used to generate keys and digital signatures.
Legacy verification validated by CAVP Cert.
#C477
SHS (non-compliant) SHA-1 Hashing for digital signatures and key
derivation. Validated by CAVP Cert. #C295
Triple-DES (non-compliant) 2 key and 3 key encrypt/decrypt Data encryption and decryption. Validated by
CAVP TDES Cert. #2900.
Triple-DES MAC (non-compliant) 128-bit, 192-bit Used to generate Message Authentication
Codes (MACs).
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
16
7.4 CSPS AND KEYS
7.4.1 CRITICAL SECURITY PARAMETERS
All CSPs except the KEK are stored in battery-backed memory encrypted by the KEK, or in Non-
Volatile Memory (NVM) external to the module encrypted by the KEK and additionally protected by
the KAK. Therefore, zeroizing the KEK destroys access to all CSPs. All CSPs that are input or output
are wrapped in conformance to SP 800-38F by an AES KW key (128-256 bits).
Table 8 – Secret Keys, Private Keys, Cryptographic Key Components, and Other CSPs
CSP/Key Security Function Use Establishment Entry/Output Storage Destruction
KEK
(256-bit)
(Key Encryption
Key)
AES KW 256 (Cert.
#5954)
Protect all keys
stored internally or
in NVM
Generated
Internally by
FIPS approved
DRBG (during
manufacturing)
Entry: N/A
Output: N/A
Plaintext Zeroization,
Tamper or
removal of all
power
KEK’
(256-bit)
(Backup Key
Encryption Key)
AES KW 256 (Cert.
#5954)
Backup KEK Generated
Internally by
FIPS approved
DRBG (during
manufacturing)
Entry: N/A
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
KAK
(256-bit)
(Key
Authentication
Key)
HMAC-SHA-256
(Cert. #C464)
Protect keys
externally stored in
NVM
Generated
Internally by
FIPS approved
DRBG (during
manufacturing)
Entry: N/A
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
DAK
(Device
Authentication
Keys)
HMAC-SHA-256
(Cert. #C464)
Additional integrity
and authentication
check for loaded
keys
Generated
Internally by
FIPS approved
DRBG (KRA
HSM only)
Entered in
manufacturing
Entry: N/A
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
DPK
(Device Privacy
Key)
AES CBC 256 or
AES KW 256 (Cert.
#5954)
Keys used to
encrypt data or keys
Generated
Internally by
DRBG from
entropy input
pre-loaded into
the module in
manufacturing
Entry: N/A
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
DRBG Seed
(1024-bit)
DRBG Seed
Material
Seeding the DRBG Loaded during
manufacturing
only.
Entry: N/A
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
DRBG Working
State
(1024-bit)
DRBG (Cert.
#C472)
Internal working
state of the DRBG
Generated
Internally by
FIPS approved
DRBG
Entry: N/A
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
AK
(Authentication
HMAC-SHA-256
(Cert. #C464)
Used to provide
Authentication
Generated
Internally by
Entry:
Encrypted by
Encrypted
with KEK
Zeroization,
Tamper or
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
17
CSP/Key Security Function Use Establishment Entry/Output Storage Destruction
Key) ECDSA P-224 or P-
256 (Cert. #C476)
Used to provide
Authentication
FIPS approved
DRBG
Or loaded as
needed
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
removal of all
power
RSA 2048 (Cert.
#C477)
Used to provide
Authentication
Encrypted
with KEK
PK
(Privacy Key)
AES CBC 128, 192,
256 or
AES KW 128, 192,
256 (Cert. #5954)
Keys used to
encrypt data or keys
Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
RSA 2048 (Cert.
#C477)
Keys used to
decrypt data
Encrypted
with KEK
DPAG Private
(DPAG Private
Key)
RSA 2048 (Cert.
#C477)
RSA Keys generated
for PSDs
Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
ECC-CDH Key
(256-bit)
KAS-SSC (Cert.
#A1869)
Ephemeral ECC-
CDH private key
used in KAS-SSC
Generated
Internally by
FIPS approved
DRBG
Entry: N/A
Output: N/A
Destroyed
immediately
after session
established
Zeroization,
Tamper or
removal of all
power
Shared Secret
(256-bit)
KDA (Cert.
#A1869)
Used to derive
session keys
KAS-SSC per SP
800-56Ar3
Entry: N/A
Output: N/A
Destroyed
immediately
after session
established
Zeroization,
Tamper or
removal of all
power
Session Key
(256-bit)
AES KW 128, 292,
256 (Cert. #5954)
Encrypt data or
wrap keys
transported to
infrastructure
KAS-SSC per SP
800-56Ar3 +
KDF per SP 800-
56Cr1
Entry: N/A
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
HMAC-SHA-256
(Cert. #C464)
Provide message
Authentication
CRK Private Customer Root Key
(RSA PSS 2048)
Signs the PB
Bootloader
firmware
Generated
Internally by
FIPS approved
DRBG (KRA
HSM only)
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
SWAK Private Software
Authentication Key
(ECDSA P-256)
Signs the HSM
firmware
Generated
Internally by
FIPS approved
DRBG (KRA
HSM only)
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
18
CSP/Key Security Function Use Establishment Entry/Output Storage Destruction
PAK Private Parameter
Authentication Key
(ECDSA P-256)
Signs the HSM
parameters
Generated
Internally by
FIPS approved
DRBG (KRA
HSM only)
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
PSWD
(Password
Authentication
Key)
HMAC-SHA-256
(Cert. #C464)
Used to provide
Login
Authentication
Loaded as
needed
Entry:
Encrypted by
AES KW
Output: N/A
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
RSA Primes Primes for RSA PSS
2048
Primes used to
speed up RSA key
generation
Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry:
Encrypted by
AES KW
Output:
Encrypted by
AES KW
Encrypted
with KEK
Zeroization,
Tamper or
removal of all
power
7.4.2 PUBLIC SECURITY PARAMETERS KEYS
Table 9 – Public Security Parameters
Public Key Description Use Establishment Entry/Output Storage
CRK Customer Root Key
(RSA PSS 2048)
Validates the PB Bootloader
firmware integrity on power-
on
Loaded in
Manufacturing
Entry: N/A
Output: Plaintext
Plaintext
SWAK Software
Authentication Key
(ECDSA P-256)
Validates the HSM
Application firmware
integrity on power-on
Loaded in
Manufacturing
Entry: N/A
Output: Plaintext
Plaintext
PAK Parameter
Authentication Key
(ECDSA P-256)
Validated loaded Parameters Loaded in
Manufacturing
Entry: N/A
Output: Plaintext
Plaintext
ECC-CDH Peer
Public Key
ECC-CDH KAS
Public counterpart
received during the
DH handshake
ECDH public counterpart
received as part of the EC DH
exchange.
Externally
(Loaded during
KAS-SSC)
Entry: Authenticated
per 56A
Output: N/A
Plaintext
ECC-CDH Public
Key
ECC-CDH KAS
Public key
generated during
the DH handshake
ECDH public key transmitted
as part of the EC DH exchange
Generated
Internally
Entry: N/A
Output: Plaintext
Plaintext
AK Public
(Public
Authentication
Key)
ECDSA P-224 or P-
256 Public Key
Used to provide
Authentication
Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry: Plaintext
Output: Plaintext
Plaintext
RSA 2048 Public
Key
Used to provide
Authentication
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
19
Public Key Description Use Establishment Entry/Output Storage
PK Public
(Public Privacy
Key)
RSA 2048 Public
Key
Keys used to encrypt data Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry: Plaintext
Output: Plaintext
Plaintext
DPAG Public
(DPAG Public Key)
RSA 2048 Public
Key
Used to provide
Authentication
Generated
Internally by
FIPS approved
DRBG
Or loaded as
needed
Entry: Plaintext
Output: Plaintext
Plaintext
7.4.3 ZEROIZATION
The module is a single-chip, cryptographic module that incorporates an Active Shield that provides
a tamper detection and response mechanism. When this mechanism is triggered, the module
immediately zeroizes the KEK, which renders all encrypted keys non-operational. The module
transitions to a hard error state in which it must be returned to manufacturing.
Zeroization of the module can also be performed by the operator via the Reinit service.
8. SELF-TESTS
The module supports the following self-tests.
Power on self-tests (POSTs) can be run on demand by an unauthenticated operator by either
power-cycling the module or via the Reboot service. Additionally, they may be executed via Perform
Diagnostic Test or Perform Full Diagnostics services.
Upon the failure of any of the self-tests the module transitions to an error state. All data output via
the data output interface is inhibited while in the error state. No cryptographic operations can be
performed while in the error state. To transition from the error state the module must be power-
cycled.
8.1 POWER ON SELF-TESTS
Firmware Integrity Tests:
The module conducts the following digital signature verifications on power-up.
• PB Bootloader
o RSA 2048 (Cert. #C477) Digital Signature Verification
• HSM Application
o ECDSA P-256 (Cert. #C476) Digital Signature Verification
Algorithm Tests:
The module conducts the following Known Answer Tests (KATs) and Pairwise Consistency Tests
(PWCT) on power-up.
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
20
o AES (Cert. #5954)
o AES-256 ECB Encrypt KAT
o AES-256 ECB Decrypt KAT
o AES-256 KW Encrypt KAT
o AES-256 KW Decrypt KAT
o DRBG (Cert. #C472) 11
o Instantiate KAT
o Generate KAT
o ECDSA (Cert. #C476)
o P-256 Signature Generation and Verification PWCT
o HMAC (Cert. #C464) and SHS (Cert. #C295)
o HMAC-SHA-256 KAT
o KAS-ECC-SSC (Cert. #A1869, C(2e, 0s, ECC CDH))
o KAS-SSC KAT: Primitive “Z” Computation KAT, conformant with IG D.8, Scenario X1
o KDA (Cert. #A1869)
o KDA KAT per IG D.8, Scenario X1
o RSA (Cert. #C477)
o 2048 Signature Generation KAT
o 2048 Signature Verification KAT
Critical Function Tests:
o RTC Test
o BRAM Pattern Test
8.2 CONDITIONAL TESTS
The module conducts the following conditional tests.
o PWCT upon cryptographic key pair generation:
o ECDSA P-224 or P-256 PWCT
o RSA 2048 PWCT
o KAS-SSC (Cert. #A1869, C(2e, 0s, ECC CDH))
o ECC Full Public Key Validation (PKV) per SP 800-56Arev 3: 5.6.2.3.3
o Software/Firmware Load Test:
o ECDSA P-256 Signature Verification (Cert. #C476)
11 Per IG 9.8, the SP 800-90A-compliant DRBG does not perform the test described in AS.09.42 and AS.09.43
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
21
APPENDIX A: REFERENCES
Table 10 – References
Reference Title
Publishing
Entity
Publication
Date
Digital Signature Standard (DSA) – FIPS PUB 186-4 NIST July 2013
Advanced Encryption Standard (AES) – FIPS PUB 197 NIST November 2001
The Keyed-Hash Message Authentication Code (HMAC) – FIPS PUB 198-1 NIST July 2008
Secure Hash Standard – FIPS PUB 180-4 NIST March 2012
Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography - Special Publication 800-56A Revision
3
NIST April 2018
Recommendation for Key-Derivation Methods in Key-Establishment
Schemes - Special Publication 800-56C Revision 1
NIST April 2018
Recommendation for Cryptographic Key Generation - - Special Publication
800-133 Revision 2
NIST June 2020
Recommendation for Block Cipher Modes of Operation, Methods and
Techniques – Special Publication 800-38A
NIST December 2001
Recommendation for Random Number Generation Using Deterministic
Random Bit Generators – Special Publication 800-90A
NIST January 2012
FIPS PUB 140-2, Security Requirements for Cryptographic Modules NIST May 2001
Derived Test Requirements for FIPS PUB 140-2, Security Requirements
for Cryptographic Modules
NIST January 2011
FIPS PUB 140-2, Annex A – Approved Security Functions for FIPS PUB
140-2
NIST January 2018
FIPS PUB 140-2, Annex B – Approved Protection Profiles for FIPS PUB
140-2
NIST December 2016
FIPS PUB 140-2, Annex C – Approved Random Number Generators for
FIPS PUB 140-2
NIST January 2016
FIPS PUB 140-2, Annex D – Approved Key Establishment Techniques for
FIPS PUB 140-2
NIST May 2018
Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
Module Validation Program
NIST December 2019
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
22
APPENDIX B: ABBREVIATIONS AND DEFINITIONS
Table 11 – Abbreviations and Definitions
Term Definition
AES Advanced Encryption Standard
BRAM Battery Backed RAM
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CO Crypto Officer
CSP Critical Security Parameters
CVL Component Validation List
DAL Device Abstraction Layer
DH Diffie-Hellman
DRBG Deterministic Random Bit Generator
DSA Digital Signature Algorithm
ECB Electronic Code Book
ECC CDH Elliptic Curve Cryptography Cofactor Diffie-Hellman
EC-DH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EFP Environmental Failure Protection
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FIPS Federal Information Processing Standards
HMAC Hashed Message Authentication Code
HSM Hardware Security Module
KAS Key Agreement Scheme
KRA Key Root Authority
NDRNG Non-Deterministic Random Number Generator
NVM Non-Volatile Memory
PB Pitney Bowes
POST Power-on Self-test
PSD Postal Security Device
PSS Probabilistic Signature Scheme
PVD Postage Value Download
RAM Random Access Memory
FIPS 140-2 Non-Proprietary Security Policy for X4i Hardware Security Module (HSM)
This document may be freely reproduced and distributed, but only in its entirety and without modification
23
Term Definition
ROM Read-Only Memory
RSA Rivest Shamir Adleman
RTC Real Time Clock
SDU Software Download Utility
SHA Secure Hash Algorithm
SSC Shared Secret Computation
SRAM Static RAM