| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 7/28/2029 |
| Caveat | When operated in approved mode. No assurance of the minimum strength of generated SSPs (e.g., keys). |
| Vendor | CGI Federal Inc. |
flowchart LR
%% Deterministic review-risk graph for CGI Momentum™ Java Cryptographic Module
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>recovery</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show Status<br/>self-test</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C5 --> I5 --> R5 --> E5
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C5,C6 clue;
class I2,I3,I5,I6 infer;
class R2,R3,R5,R6 risk;
class E2,E3,E5,E6 evidence;flowchart LR
%% Deterministic clue tier for CGI Momentum™ Java Cryptographic Module
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>recovery</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show Status<br/>self-test</i><br/>src: text:keyword"]
C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C5,C6 clueLow;CGI Federal Inc. CGI Momentum™ Java Cryptographic Module Software Version 4.0.0 Document Version 1.0 April 08, 2025 Prepared For: Prepared By: CGI Federal Inc. SafeLogic, Inc.
12601 Fair Lakes Circle 8300 Boone Blvd., Suite 500
Fairfax, VA 22033 Vienna, VA 22182 USA USA https://www.cgifederal.com/ www.safelogic.com
| # | Section | Page |
|---|
| Item | Page |
|---|---|
| Table 1 - Security Levels | 6 |
| Table 2 - Executable Code Sets | 8 |
| Table 3 - Tested Operational Environments – Software/Firmware/Hybrid | 9 |
| Table 4 - Vendor Affirmed Operational Environments – Software/Firmware/Hybrid | 10 |
| Table 5 - Modes of Operation | 14 |
| Table 6 - Approved Algorithms, CAVP Tested | 15 |
| Table 7 - Vendor Affirmed Algorithms | 21 |
| Table 8 - Non-Approved, Allowed Algorithms with No Security Claimed | 22 |
| Table 9 - Non-Approved, Not Allowed Algorithms | 22 |
| Table 10 - SP 800-38G Format-Preserving Encryption Constraints | 26 |
| Table 11 – Non-Deterministic Random Number Generation Specification | 27 |
| Table 12 – Ports and Interfaces | 30 |
| Table 13 - Roles | 31 |
| Table 14 – Approved Services | 32 |
| Table 15 - Non-Approved Services | 45 |
| Table 16 - Sensitive Security Parameters (SSPs) Key Table | 51 |
| Table 17 – Conditional Algorithm Self-Tests | 62 |
| Table 18 – Pairwise Consistency Tests | 63 |
| Table 19 - Available Java Permissions for SecurityManager | 66 |
| Table 20 - References | 70 |
| Table 21 - Acronyms | 72 |
| Figure 1 - Module Block Diagram | 8 |
This document provides a non-proprietary FIPS 140-3 Security Policy for CGI Momentum™ Java Cryptographic Module.
Federal Information Processing Standards Publication 140-3, Security Requirements for Cryptographic Modules, (FIPS 140-3) specifies the latest requirements for cryptographic modules utilized to protect sensitive but unclassified information. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) collaborate to run the Cryptographic Module Validation Program (CMVP), which assesses conformance to FIPS 140. NIST (through NVLAP) accredits independent testing labs to perform FIPS 140 testing. The CMVP reviews and validates modules tested against FIPS
140 criteria. Validated is the term given to a module that has successfully gone through this FIPS 140
validation process. Validated modules receive a validation certificate that is posted on the CMVP’s website. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program.
This non-proprietary cryptographic module Security Policy for CGI Momentum™ Java Cryptographic Module from CGI Federal Inc. (CGI) provides an overview of the product and a high-level description of how it meets the security requirements of FIPS 140-3. This document includes details on the module’s cryptographic capabilities, services, sensitive security parameters, and self-tests. This Security Policy also includes guidance on operating the module while maintaining compliance with FIPS 140-3. CGI Momentum™ Java Cryptographic Module may also be referred to as “the module” in this document.
The CGI website (https://www.cgifederal.com/) contains information on CGI services and products. The CMVP website maintains this FIPS 140 certificate for CGI and the certificate includes CGI contact information.
This document may be freely reproduced and distributed, but only in its entirety and without modification.
Table 1 lists the module’s level of validation for each area in FIPS 140-3. Table 1 - Security Levels Section Security Level Overall Security Level 1 Section 1
Purpose and Use: CGI Momentum™ Java Cryptographic Module is a standards-based cryptographic engine for native Java environments. CGI Momentum™ product suite uses this module as Java JCA/JCE provider thus providing data at rest encryption, transport level encryption, PKI key management, digital signature generation and other crypto operations through a trusted and verified implementation. The module delivers cryptographic services to host applications through a Java language Application Programming Interface (API). Module Type: Software Module Embodiment: Multi-Chip Stand Alone Cryptographic Boundary: The cryptographic boundary is the Java Archive (JAR) file, ccj-4.0.0.jar. The module is the only component within the cryptographic boundary and the only component that carries out cryptographic functions covered by FIPS 140-3. The module classes are executed on the Java Virtual Machine (JVM) using the classes of the Java Runtime Environment (JRE). The JVM is the interface to the computer’s Operating System (OS), which is the interface to the various physical components of the general purpose computer (GPC). As a software cryptographic module, the module operates within the Tested Operational Environment’s Physical Perimeter (TOEPP). The TOEPP physical perimeter is the physical perimeter of the GPC that the module operates on. The TOEPP includes the JVM/JRE, OS, and the GPC. The TOEPP includes the Operational Environment (OE) that the module operates in, the module itself, and all other applications that operate within the OE, including the host application for the module. The external entropy source used by the module is also within the TOEPP. The module’s block diagram is provided in Figure 1, which shows the cryptographic boundary and the logical relationship of the cryptographic module to the other software and hardware components of the TOEPP. The module’s logical interfaces are defined by its API.
Figure 1 - Module Block Diagram
Tested Module Identification
Confirming the Module Checksum, Functionality, and Versioning The module checksum, functionality, and versioning can be confirmed by executing the command: java -cp ccj-4.0.0.jar com.safelogic.cryptocomply.util.DumpInfo which should display: Version Info: CryptoComply® for Java version v4.0.0 FIPS Ready Status: READY Module SHA-256 HMAC: c5f6e9c3593f67ea87f08b91590c7531c53ac2540685b921807c9e82581911ee This display indicates that the JAR represents the software release ccj-4.0.0, that it has successfully passed all its startup tests, and that the software release is confirmed to have the HMAC listed above. Tested Operational Environments - Software, Firmware, Hybrid: The module operates in a modifiable operational environment under the FIPS 140-3 definitions. The cryptographic module was tested on the following operational environments on the GPC platforms detailed in Table 3. Table 3 - Tested Operational Environments
• The module operates on any general-purpose platform/processor that supports the specified operating system as listed on the validation entry. Or the module uses another compatible platform, such as one of the Java SE Runtime Environments (or equivalent OpenJDK Runtime Environments) listed in the table below (Table 4). The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. Table 4 - Vendor Affirmed Operational Environments – Software/Firmware/Hybrid # Operating System Hardware Platform
# Operating System Hardware Platform
# Operating System Hardware Platform
# Operating System Hardware Platform
Modes List and Description: Table 5 - Modes of Operation Name Description Type Status Indicator Approved Only supports Approved CryptoServicesRegistrar.IsInApprovedOnlyMode() mode approved operations can be called to determine the mode of operation. This method will return true for approved mode. Non- Permits operations Non- CryptoServicesRegistrar.IsInApprovedOnlyMode() approved that are not Approved can be called to determine the mode of mode approved operation. This method will return false for nonapproved mode. Mode Change Instructions and Status: In default operation the module will start with all algorithms and services enabled. If the module detects that the system property com.safelogic.cryptocomply.fips.approved_only is set to true the module will start in approved mode and non-approved mode functionality will not be available. The module optionally uses the Java SecurityManager. If the underlying JVM is running with a Java SecurityManager installed the module starts in approved mode by default with secret and private key export disabled. When the module is not used within the context of the Java SecurityManager, it will start by default in the non-approved mode. Refer to Security Policy Section 11.3 for additional information about the Java SecurityManager. Refer to Security Policy Section 11.4.1 for additional information on the module’s mode of operation rules.
The module implements the algorithms specified in the tables below. The module supports both an Approved mode and a Non-approved mode of operation. Please see Security Policy Section 2.4 for additional details on the modes of operation and the configuration of the Approved mode of operation. Please see Security Policy Section 11.1 for Initialization steps.
The module implements the following approved algorithms that have been tested by the Cryptographic Algorithm Validation Program (CAVP). There are algorithms, modes, and keys that have been CAVP tested but not used by the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by the module. Table 6 - Approved Algorithms, CAVP Tested Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name AES A6047 Modes: CBC, CFB8, CFB128, AES [FIPS 197, Encryption, CTR, ECB, FF1, OFB SP 800-38A], Decryption AES FF1 Format Key sizes: 128, 192, 256 bits Preserving Encryption [SP 800-38G] AES CBC A6047 Modes: CBC-CS1, CBC-CS2, [Addendum to Encryption, Ciphertext CBC-CS3 SP 800-38A, Decryption Stealing (CS) Oct 2010] Key sizes: 128, 192, 256 bits AES CCM A6047 Key sizes: 128, 192, 256 bits [SP 800-38C] Generation, Authentication AES CMAC A6047 Key sizes: 128, 192, 256 bits [SP 800-38B] Generation, Authentication AES GCM/GMAC1 A6047 Key sizes: 128, 192, 256 bits [SP 800-38D] Generation, Authentication AES KW, KWP A6047 Modes: AES KW, KWP [SP 800-38F] Key Wrapping (KTS: Key Key sizes: 128, 192, 256 bits Wrapping Using AES2) (key establishment methodology providing 128,
strength) DRBG, Counter A6047 AES 128, AES 192, AES 256 [SP 800-90Ar1] Random Bit DRBG Generation DRBG, Hash DRBG A6047 SHA sizes: SHA-1, SHA-224, [SP 800-90Ar1] Random Bit SHA-256, SHA-384, SHA2-512, Generation SHA-512/224, SHA2-512/256 DRBG, HMAC A6047 SHA sizes: SHA-1, SHA-224, [SP 800-90Ar1] Random Bit DRBG SHA-256, SHA-384, SHA2-512, Generation SHA-512/224, SHA2-512/256 GCM encryption with an internally generated IV, see Security Policy Section 2.6.1 concerning external IVs. IV generation is compliant with IG C.H. Keys are not established directly into the module using key agreement or key transport algorithms.
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name DSA3 A6047 Key sizes: 10244, 2048, 3072 [FIPS 186-4] Key Pair bits Generation, PQG Generation, PQG Verification, Signature Generation, Signature Verification ECDSA A6047 Curves/Key sizes: P-224, P-256, [FIPS 186-5] Key P-384, P-521, K-233, K-283, K- Generation, 409, K-571, B-233, B-283, B- Key 409, B-571 Verification, Signature Generation, Signature Verification ECDSA A6047 Curves/Key sizes: P-192, K-163, [FIPS 186-4] Key B-1635 Verification, Signature Verification HMAC A6047 SHA sizes: SHA-1, SHA-224, [FIPS 198-1] Generation, SHA-256, SHA-384, SHA-512, Authentication SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512 DSA signature generation with SHA-1 is only for use with protocols. Key size only used for Signature Verification Legacy testing for signatures not specified under FIPS 186-5.
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name KAS-ECC6 A6047 Domain Parameter Generation [SP 800-56Ar3] Key Agreement Methods/Schemes: P-224, P-256, P-384, P-521, K233, K-283, K-409, K-571, B233, B-283, B-409, B-571 ephemeralUnified, fullMqv, fullUnified, onePassDh, onePassMqv, onePassUnified, staticUnified Curves specified above providing between 112 and 256 bits of encryption strength KAS-FFC6 A6047 Domain Parameter Generation [SP 800-56Ar3] Key Agreement Methods/Schemes: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, MODP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192 dhHybrid1, MQV2, dhEphem, dhHybrid, OneFlow, MQV1, dhOneFlow, dhStatic Groups specified above providing between 112 and 200 bits of encryption strength KAS-IFC A6047 RSASVE with, and without, key [SP 800-56Br2, Key Agreement confirmation. Section 7.2.1] Key sizes: 2048, 3072, 4096 providing between 112 and 152 bits of encryption strength KDA, HKDF A6047 PRFs: HMAC-SHA-1, HMAC [SP 800-56Cr2] Key Derivation SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA512, HMAC-SHA-512/224, HMAC-SHA-512/256, HMACSHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3Keys are not established directly into the module using key agreement or key transport algorithms.
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name KDA, One Step A6047 PRFs: SHA-1, SHA-224, SHA- [SP 800-56Cr2] Key Derivation 256, SHA-384, SHA-512, SHA512/224, SHA-512/256, SHA3224, SHA3-256, SHA3-384, SHA3-512, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA256, HMAC-SHA-384, HMACSHA-512, HMAC-SHA-512/224, HMAC-SHA-512/256, HMACSHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3512, KMAC-128, KMAC-256 KDA, Two Step A6047 PRFs: HMAC-SHA-1, HMAC- [SP 800-56Cr2] Key Derivation SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA512, HMAC-SHA-512/224, HMAC-SHA-512/256, HMACSHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3512, CMAC-AES128, CMACAES192, CMAC-AES256 KDF, using A6047 Modes: Counter Mode, [SP 800-108] Key Derivation Pseudorandom Feedback Mode, DoubleFunctions7 Pipeline Iteration Mode Types: CMAC-based KBKDF with AES (128, 192, 256) HMAC-based KBKDF with SHA1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 KDF, Existing CVL ANSI X9.63 KDF [SP 800-135r1] Key Derivation Application- A6047 Can be used SHA sizes: SHA2-224, SHA2Specific8 along with KAS256, SHA2-384, SHA2-512 SSC KDF, Existing CVL IKEv2 KDF [SP 800-135r1] Key Derivation Application- A6047 SHA sizes: SHA-1, SHA-224, Specific8 SHA-256, SHA-384, SHA-512 Note: CAVP testing is not provided for use of the PRFs SHA-512/224 and SHA-512/256. These must not be used in approved mode.
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name KDF, Existing CVL SNMP KDF [SP 800-135r1] Key Derivation Application- A6047 Password Length: 64, 8192 Specific8 KDF, Existing CVL SRTP KDF [SP 800-135r1] Key Derivation Application- A6047 AES: 128, 192, 256 Specific8 KDF, Existing CVL SSH KDF [SP 800-135r1] Key Derivation Application- A6047 AES: 128 Specific8 SHA sizes: SHA2-224 KDF, Existing CVL TLS v1.0/1.1 KDF [SP 800-135r1] Key Derivation Application- A6047 SHA sizes: SHA2-256, SHA2Specific8 384, SHA2-512 KDF, Existing CVL TLS 1.2 KDF [SP 800-135r1] Key Derivation Application- A6047 SHA sizes: SHA2-256, SHA2Specific8 384, SHA2-512 KTS-IFC A6047 RSA-OAEP with, and without, [SP 800-56Br2, Key Transport key confirmation. Section 7.2.2] Key sizes: 2048, 3072, 4096 providing between 112 and 152 bits of encryption strength Key Generation Method: rsakpg2-crt PBKDF, Password- A6047 Options: PBKDF with Option 1a [SP 800-132] Key Derivation based Types: HMAC-based KDF using SHA-1, SHA-224, SHA-256, SHA384, SHA-512 RSA A6047 Key sizes: 2048, 3072, 4096 [FIPS 186-5, Key Pair ANSI X9.31- Generation
#1 v2.1 (PSS and PKCS1.5)] RSA A6047 Key sizes: 2048, 3072, 4096 [FIPS 186-5, Signature PKCS #1 v2.1 Generation (PSS and PKCS1.5)] RSA A6047 Key sizes: 2048, 3072, 4096 [FIPS 186-4, Signature ANSI X9.31- Generation 1998] No parts of the protocols (TLS, SNMPv3, SSHv2, X9.63, IKEv2, SRTP), other than the approved cryptographic algorithms and the KDFs, have been reviewed or tested by the CAVP and CMVP
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name RSA A6047 Key sizes: 2048, 3072, 4096 [FIPS 186-5, Signature PKCS #1 v2.1 Verification (PSS and PKCS1.5)] RSA A6047 Key sizes: 1024, 2048, 3072, [FIPS 186-4, Signature
#1 v2.1 (PSS and PKCS1.5)] RSA A6047 Key sizes: 1024, 1536, 2048, [FIPS 186-2, Signature 3072, 4096 ANSI X9.31- Verification
#1 v2.1 (PSS and PKCS1.5)] RSA Decryption CVL Key size: 2048 [SP 800-56Br2] Component Primitive A6047 Test RSA Signature CVL Key size: 2048 [FIPS 186-4] Component Primitive A6047 Test Safe Primes A6047 Parameter sets: ffdhe2048, [SP 800-56Ar3] Key ffdhe3072, ffdhe4096, Generation, ffdhe6144, ffdhe8192, MODP- Key Verification 2048, MODP-3072, MODP4096, MODP-6144, MODP8192 SHA-3, SHAKE A6047 SHA3-224, SHA3-256, SHA3- [FIPS 202] Digital 384, SHA3-512, SHAKE128, Signature SHAKE256 Generation, Digital Signature Verification, non-Digital Signature Applications Legacy testing for signatures not specified under FIPS 186-5 (all moduli for ANSI X9.31, and testing with 1024 or SHA-1 for PSS and PKCS 1.5)
Algorithm Name CAVP Cert Algorithm Properties Reference Use/Function (Implementation) Name SHA-3 Derived A6047 Types: cSHAKE-128, cSHAKE- [SP 800-185] Digital Functions 256, KMAC-128, KMAC-256, Signature ParallelHash-128, ParallelHash- Generation, Digital 256, TupleHash-128, Signature TupleHash-256 Verification, non-Digital Signature Applications SHS A6047 SHA sizes: SHA-1, SHA-224, [FIPS 180-4] Digital SHA-256, SHA-384, SHA-512, Signature SHA-512/224, SHA-512/256 Generation, Digital Signature Verification, non-Digital Signature Applications
Vendor-Affirmed Algorithms: Table 7 - Vendor Affirmed Algorithms Algorithm Algorithm Implementation Reference Name Properties CKG Used for the Other [SP 800-133r2] generation of Cryptographic key symmetric keys and generation CKG using output from DRBG, asymmetric seeds Vendor Affirmed per IG D.H. The resulting key or a generated seed is an unmodified output from a DRBG:
Non-Approved, Allowed Algorithms: Not applicable.
Non-Approved, Allowed Algorithms with No Security Claimed. These algorithms are Allowed in Approved mode. Table 8 - Non-Approved, Allowed Algorithms with No Security Claimed Algorithm Caveat Use/Function MD5 within TLS Allowed per IG 2.4.A, no security claimed MD5 used within a TLS handshake
Non-Approved, Not Allowed Algorithms: Table 9 - Non-Approved, Not Allowed Algorithms Algorithm Use/Function AES (non-compliant10) Non-approved modes for AES ARC4 (RC4) ARC4/RC4 stream cipher Blowfish Blowfish block cipher Camellia Camellia block cipher CAST5 CAST5 block cipher ChaCha20 ChaCha20 stream cipher ChaCha20-Poly1305 AEAD ChaCha20 using Poly1305 as the MAC DES DES block cipher Diffie-Hellman KAS (non-compliant11) non-compliant key agreement methods DSA (non-compliant12) non-FIPS digest signatures using DSA DSTU4145 DSTU4145 EC algorithm ECDSA (non-compliant13) non-FIPS digest signatures using ECDSA Support for additional modes of operation. Support for additional key sizes and the establishment of keys of less than 112 bits of security strength. Deterministic signature calculation, support for additional digests, and key sizes. Deterministic signature calculation, support for additional digests, and key sizes.
Algorithm Use/Function EdDSA Ed25519 and Ed448 signature algorithms ElGamal ElGamal key transport algorithm FF3-1 Format Preserving Encryption
Algorithm Use/Function PRNG X9.31 X9.31 PRNG RC2 RC2 block cipher RIPEMD128 RIPEMD128 message digest RIPEMD160 RIPEMD160 message digest RIPEMD256 RIPEMD256 message digest RIPEMD320 RIPEMD320 message digest RSA (non-compliant15) Non-compliant RSA signature schemes RSA KTS (non-compliant16) Non-compliant RSA key transport schemes SCrypt (non-compliant) SCrypt using non-compliant PBKDF2 SEED SEED block cipher Serpent Serpent block cipher SipHash SipHash MAC SHACAL-2 SHACAL2 block cipher TIGER TIGER message digest Triple-DES Triple-DES cipher Twofish Twofish block cipher WHIRLPOOL WHIRLPOOL message digest XDH X25519 and X448 key agreement algorithms
IVs for GCM can be generated randomly, or via a FipsNonceGenerator. IV generation is compliant with IG C.H. Where an IV is not generated within the module the module supports the importing of GCM IVs. In approved mode, importing a GCM IV for encryption that originates from outside the module is nonconformant. In approved mode, when a GCM IV is generated randomly, the module enforces the use of an approved DRBG in line with Section 8.2.2 of SP 800-38D. Support for additional digests and signature formats, PKCS#1 1.5 key wrapping, support for additional key sizes. Support for additional key sizes and the establishment of keys of less than 112 bits of security strength.
In approved mode, when a GCM IV is generated using the FipsNonceGenerator, a counter is used as the basis for the nonce and the IV is generated in accordance with TLS protocol. Rollover of the counter in the FipsNonceGenerator will result in an IllegalStateException indicating the FipsNonceGenerator is exhausted and (as per IG C.H) where used for TLS 1.2, rollover will terminate any TLS session in process using the current key and the exception can only be recovered from by using a new handshake and creating a new FipsNonceGenerator. A service indicator for IV usage is provided in the module through Java logging. Setting the logging level to Level.FINE for the named logger com.safelogic.cryptocomply.jcajce.provider.BaseCipher will produce a log message when an IV which may have been produced outside the module and/or not from a compliant source is detected. The log message will be of the standard form including the detail: FINE: Passed in GCM nonce detected: <IV value> where <IV value> is a HEX representation of the IV in use. Setting the logging level to Level.FINER will produce an additional log message for any GCM IV which is used if the previous Level.FINE message is not activated. Log messages in this case will show the detail as: FINER: GCM nonce detected: <IV value> where <IV value> is a HEX representation of the IV in use. Per IG C.H, this Security Policy also states that in the event module power is lost and restored the consuming application must ensure that any of its AES GCM keys used for encryption or decryption are re-distributed. The AES GCM mode falls under:
2.6.2 Enforcement and Guidance for Use of the Approved PBKDF (IG D.N conformance)
The PBKDF aligns with Option 1a in Section 5.4 of SP 800-132. In line with the requirements for SP 800-132, keys generated using the approved PBKDF must only be used for storage applications. Any other use of the approved PBKDF is non-conformant. In approved mode the module enforces that any password used must encode to at least 14 bytes (112 bits) and that the salt is at least 16 bytes (128 bits) long. The iteration count associated with the PBKDF should be as large as practical.
As the module is a general purpose software module, it is not possible to anticipate all the levels of use for the PBKDF, however a user of the module should also note that a password should at least contain enough entropy to be unguessable and also contain enough entropy to reflect the security strength required for the key being generated. In the event a password encoding is simply based on ASCII, a 14byte password is unlikely to contain sufficient entropy for most purposes. The standard set of printable characters only allows for as much as 6 bits of entropy per byte. For a 14-byte password, this yields a key that has been generated using 14 * 6 bits of entropy, giving only 84 bits of security, which is well below what is required for a key with the same level of hardness as a 112-bit one. Users are referred to Appendix A (Security Considerations) of SP 800-132 for further information on password, salt, and iteration count selection. The iteration count value is provided by the user and should be appropriate to the way the algorithm is being used. (The memory hard augmentation of PBKDF provided by SCRYPT uses an iteration count of 1). For straight PBKDF with no memory hard support, the iteration count provided by the user should be at point of maximum cost bearable by the user carrying out the key derivation in the normal course of usage. To ensure sufficient whitening of the password in both cases, the module enforces a salt size of
For users interested in introducing memory hardness as a layer on top of the PBKDF the SCrypt augmentation to PBDKF based on HMAC-SHA-256 (as described in RFC 7914) is also available in nonapproved mode.
To customize the output of the cSHAKE function, the cSHAKE algorithm permits the operator to input strings for the Function-Name input (N) and the Customization String (S). The Function-Name input (N) is reserved for values specified by NIST and should only be set to the appropriate NIST specified value. Any other use of N is non-conformant. The Customization String (S) is available to allow users to customize the cSHAKE function as they wish. The length of S is limited to the available size of a byte array in the JVM running the module.
The module supports both FF1 and, in non-approved mode, FF3-1 format preserving encryption. Both are modes of AES. Table 10 shows the parameter constraints applicable to the module's implementation, as required by IG C.J. Table 10 - SP 800-38G Format-Preserving Encryption Constraints FF1 FF3-1 radix in range of 2 … 216 in range of 2 … 216 radixminlen ≥ 1,000,000 ≥ 1,000,000
FF1 FF3-1 minlen ≥ 2 octets 2 octets maxlen < 2 octets 2 * floor(logradix(296)) octets maxTlen ≥ 0 octets 8 octets (fixed) An attempt to use the FF1 or FF3-1 without meeting the radixminlen constraint or by exceeding maxlen will result in an IllegalArgumentException. Note: only FF1 should be used in approved mode.
As indicated under CAVP certificate A6047, the module supports TLS 1.2 KDF per RFC 5246, i.e. without using the extended master secret.
Approved HMAC algorithms can produce truncated versions of the specified HMAC. The right-most bits are truncated as per the NIST SP 800-107r1 (see also IG C.L and IG C.D).
The module does not include an entropy source. The module's use of an external Random Number Generator (RNG) is determined by the settings described in the subsections below. Table 11
The module makes use of the JVM's configured SecureRandom entropy source to provide entropy when required. The module will request entropy as appropriate to the security strength and seeding configuration for the DRBG that is using it and for the default DRBG will request a minimum of 256 bits of entropy. In approved mode the minimum amount of entropy that can be requested by a DRBG is 112 bits. The module will wait until the SecureRandom.generateSeed() returns the requested amount of entropy, blocking if necessary.
The JVM’s entropy source can be configured through setting the security property securerandom.strongAlgorithms in the JVM's java.security file.
A user can instantiate the default Approved DRBG for the module explicitly by using SecureRandom.getInstance("DEFAULT", "CCJ"), or by using a CryptoComplyFipsProvider object instead of the provider name as appropriate. This will seed the Approved DRBG from the live entropy source of the JVM with a number of bits of entropy appropriate to the security level of the default Approved DRBG configured for the module. The JVM's entropy source is checked according to SP 800-90B, Section 4.4 using the suggested C values for the Repetition Count Test (Section 4.4.1) and the Adaptive Proportion Test (Section 4.4.2) by default. These values can also be configured using the security property com.safelogic.cryptocomply.entropy.factors. This property takes a comma separated list of C values: one for 4.4.1, one for 4.4.2, and a value of H. For the default, the property would be set as: com.safelogic.cryptocomply.entropy.factors: 4, 13, 8.0 in the java.security property file. An additional option is available using the Approved Hash DRBG and the process outlined in SP 800-90A, Section 8.6.5. This can be turned on by following the instructions in Section 2.3 of the User Guide. The two DRBGs are instantiated in a chain as a "Source DRBG" to seed the "Target DRBG" in accordance with Section 7 of Draft NIST SP 800-90C, where the Target DRBG is the default Approved DRBG used by the module. The initial seed and the subsequent reseeds for the DRBG chain come from the live entropy source configured for the JVM. The DRBG chain will reseed automatically by pausing for 20 requests (which will usually equate to 5120 bytes). An entropy gathering thread reseeds the DRBG chain when it has gathered sufficient entropy (currently 256 bits) from the live entropy source. Once reseeded, the request counter is reset and the reseed process begins again. The “Source DRBG” in the chain is internal to the module and inaccessible to the user to ensure it is only used for generating seeds for the default Approved DRBG of the module. The user shall ensure that the entropy source is configured per Section 2.7.1 of this Security Policy and will block, or fail, if it is unable to provide the amount of entropy requested.
The module performs Cryptographic Key Generation in conformance to FIPS 140-3 IG D.H. The CKG for symmetric keys and seeds used for generating asymmetric keys is performed as per Section 4 of the SP 800-133r2 (using the output of a random bit generator) and is compliant with FIPS 186-5 and SP 800-
90Ar1 for DRBG. The seed used in asymmetric key generation is the direct output of SP 800-90Ar1 DRBG. Refer to Section 9.1 of the Security Policy for SSP generation details.
The module does not perform automatic SSP establishment, it only provides the components to the calling application, which can be used in SSP establishment.
The module implements KDFs from SP 800-135r1 (Recommendation for Existing Application-Specific Key Derivation Functions). These KDFs have been validated by the CAVP and received CVL certificates (A6047). No parts of these protocols, other than the CAVP tested components, have been reviewed or tested by the CAVP and CMVP.
As a software cryptographic module, the module supports logical interfaces only and not physical ports. All access to the module is through the module’s API. The API provides and defines the module’s logical interfaces. The module does not implement a control output interface. As a software module, the power interface is also not applicable. The mapping of the FIPS 140-3 logical interfaces to the module is described in Table 12. Table 12
All interfaces are logically separated by the module’s API. When the module performs self-tests, is in an error state, is generating keys, or performing zeroization, the module prevents all output on the logical data output interface as only the thread performing the operation has access to the data. The module is single-threaded, and in an error state, the module does not return any output data, only an error value.
Not applicable. The module does not support authentication.
The module supports two distinct operator roles, which are the User and Cryptographic Officer (CO). The cryptographic module implicitly maps the two roles to the services. An operator is considered the owner of the thread that instantiates the module and, therefore, only one concurrent operator is allowed. The module does not support a maintenance role and/or bypass capability. Table 13 lists all operator roles supported by the module. Table 13 - Roles Name Type Operator Type Authentication Type Authentication Strength CO Role CO N/A
Table 14 lists the module services and corresponding details. The modes of SSP access shown in the table are defined as:
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Show Status A user can call Flag N/A Boolean N/A N/A CO / N/A FipsStatus.IsReady() at any User time to determine if the module is ready. CryptoServicesRegistrar.IsI nApprovedOnlyMode() can be called to determine the approved mode of operation Info Service A user can call Flag N/A Module N/A N/A CO / N/A DumpInfo.main() at any name and User time to display the version, module version, checksum, checksum, and status and status information Zeroize / The module uses the JVM Flag N/A Shutdown N/A All SSPs CO / Z Power-off garbage collector on indication User thread termination
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Data Used to encrypt data Flag Key, Ciphertext AES CBC, AES AES Encryption Key CO / E Encryption Plaintext CFB8, AES User CFB128, AES CTR, AES ECB, AES FF1, AES OFB, AES CBC-CS1, AES CBC-CS2, AES CBC-CS3, AES CCM, AES GCM Data Used to decrypt data Flag Key, Plaintext AES CBC, AES AES Decryption Key CO / E Decryption Ciphertext CFB8, AES User CFB128, AES CTR, AES ECB, AES FF1, AES OFB, AES CBC-CS1, AES CBC-CS2, AES CBC-CS3, AES CCM, AES GCM MAC Used to calculate data Flag Key, MAC AES CMAC, AES Authentication CO / E Calculation integrity codes with Message AES GMAC Key User CMAC, GMAC
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Signature Used to generate digital Flag Key, Signature DSA, ECDSA, DSA Signing Key, CO / E Generation signatures Message RSA EC Signing Key, User RSA Signing Key Signature Used to verify digital Flag Key, Boolean DSA, ECDSA, DSA Verification CO / E Verification signatures Message RSA Key, User Signature EC Verification Key, RSA Verification Key
DRBG (SP Used to generate random Flag N/A Data Counter AES Encryption CO / G 800-90Ar1) numbers, IVs and keys DRBG Key, User output Hash DRBG AES Decryption HMAC DRBG Key, E AES Authentication CO / Key, User AES Wrapping Key, DH Agreement Private Key, DH Agreement Public Key, DRBG Seed, Internal State V and C value, and DRBG Key, DSA Signing Key, EC Agreement Private Key, EC Agreement Public Key, EC Signing Key, HMAC Authentication Key, KMAC Authentication Key, RSA Signing Key, RSA Key Transport Private Key, RSA Key Transport Public Key
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions DRBG Seed, Internal State V and C value, and DRBG Key Message Used to generate a Flag Message Hash SHS, SHA-3, N/A CO / N/A Hashing message digest, SHAKE SHAKE, SHA- User output 3 Derived Functions (cSHAKE, TupleHash, ParallelHash) Keyed Used to calculate data Flag Key, Hash HMAC, HMAC CO / E Message integrity codes with HMAC Message SHA-3 Authentication Key, User Hashing and KMAC Derived KMAC Functions Authentication Key (KMAC) TLS Key Used to calculate a value Flag TLS Data HKDF, TLS KDF Secret CO / E Derivation suitable to be used for a Parameters Existing Value User Function master secret in TLS ApplicationSpecific (TLS KDF)
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions SP 800- Used to calculate a value Flag KDF Data KBKDF using SP 800-108r1 KDF CO / E 108r1 KDF suitable to be used for a Parameters Pseudorando Secret Value User secret key m Functions SSH Used to calculate a value Flag SSH Data Existing SSH KDF Secret CO / E: Derivation suitable to be used for a Parameters Application- Value User Function secret key Specific (SSH KDF) X9.63 Used to calculate a value Flag X9.63 Data Existing DH Agreement CO / G Derivation suitable to be used for a Parameters Application- Private Key, User Function secret key Specific EC Agreement (X9.63 KDF) Private Key, E RSA Signing Key CO / User X9.63 KDF Secret Value
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions SP 800- Used to calculate a value Flag KDM Data HKDF, KDF DH Agreement CO / G 56Cr2 suitable to be used for a Parameters One Step, Private Key, User OneStep/ secret key KDF Two EC Agreement TwoStep Step Private Key, E Key RSA Signing Key CO / Derivation User Function (KDM) SP 800-56Cr2 OneStep/TwoStep KDF Secret Value IKEv2 Used to calculate a value Flag IKEv2 Data Existing IKEv2 KDF Secret CO / E Derivation suitable to be used for a Parameters Application- Value User Function secret key Specific (IKEv2 KDF) SRTP Used to calculate a value Flag SRTP Data Existing SRTP KDF Secret CO / E Derivation suitable to be used for a Parameters Application- Value User Function secret key Specific (SRTP KDF)
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions PBKDF Used to generate a key Flag Password, Data KDF HMAC CO / G using an encoding of a PBKDF Password- Authentication Key, User password and a message Parameters Based KMAC hash Authentication Key E CO / User HMAC Authentication Key, KMAC Authentication Key, PBKDF Secret Value
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Key Used to calculate key Flag Key Data KAS-ECC, AES Encryption CO / G Agreement agreement values Agreement KAS-FFC, Key, User Schemes keys, KAS-IFC, AES Decryption Parameters Safe Primes Key, E AES Authentication CO / Key, User AES Wrapping Key, HMAC Authentication Key, KMAC Authentication Key DH Agreement Private Key, EC Agreement Private Key, RSA Key Transport Private Key Key Used to encrypt a key Flag Wrapping Wrapped AES KW, AES AES Wrapping Key, CO / E Wrapping value key, Key key KWP, KTS-IFC HMAC User Authentication Key, KMAC Authentication Key, RSA Key Transport Private Key
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Key Used to decrypt a key Flag Unwrappin Key AES KW, AES AES Wrapping Key, CO / E Unwrapping value g key, KWP, KTS-IFC HMAC User Wrapped Authentication Key, key KMAC Authentication Key, RSA Key Transport Public Key Key Used to generate a key Flag Key Key Pair RSA KeyGen, DRBG Output, CO / E Generation pair Generation DSA KeyGen, DSA Signing Key, User Parameters ECDSA EC Signing Key, KeyGen, CKG RSA Signing Key, DSA Verification Key, EC Verification Key, RSA Verification Key Key Used to verify a key pair Flag Key Pair Boolean ECDSA EC Signing Key, CO / E Verification KeyVer EC Verification Key User Entropy Gathers entropy in a Flag N/A Random DRBG, CKG DRBG Seed, CO / G Callback passive manner from a bits Internal State V User user-provided function and C value, and DRBG Key DRBG Used to perform checks of Flag N/A N/A DRBG N/A CO / N/A Health Tests incoming entropy against User Section 4.4 of SP 800-90B
SSP Export Returns a CSP as data that Flag SSP Data N/A AES Encryption CO / R Operation can be used for later Key, User output AES Decryption Key, AES Authentication Key, AES Wrapping Key, DH Agreement Private Key, DH Agreement Public Key, DSA Signing Key, DSA Verification Key, EC Agreement Private Key, EC Agreement Public Key, EC Signing Key, EC Verification Key, HMAC Authentication Key, KMAC Authentication Key, RSA Signing Key, RSA Key Transport Private Key, RSA Key Transport Public Key
Approved Keys/SSPs Name Description Indicator Input Output Security Keys / SSPs Roles Access Functions Utility Miscellaneous utility Flag N/A N/A N/A N/A User N/A functions, does not access CSPs
Table 15 - Non-Approved Services Algorithms Name Description Indicator18 Roles Accessed Data Used to encrypt data Flag Triple-DES CO / User Encryption Data Used to decrypt data Flag Triple-DES CO / User Decryption MAC Used to calculate data integrity codes Flag Triple-DES CMAC CO / User Calculation with CMAC DRBG (SP Used to generate random numbers, Flag ctrDRBG-Triple-DES CO / User 800-90Ar1) IVs and keys output Key Used to calculate key agreement Flag Triple-DES CO / User Agreement values Schemes Key Used to encrypt a key value Flag Triple-DES KW CO / User Wrapping Key Used to decrypt a key value Flag Triple-DES KW CO / User Unwrapping Flag is accessed by calling the method CryptoServicesRegistrar.isInApprovedOnlyMode() - this method will return true if the thread is running in approved-only mode, false otherwise. Refer also to Section 2.4 of this Security Policy.
The integrity technique used by the module is HMAC-SHA-256. The integrity technique has received CAVP certificate A6047. The integrity technique is implemented by the module itself. The HMAC of the module JAR file, excluding directories and metadata, is calculated and compared to the expected value embedded within the module’s properties. If the calculated value does not match the expected value, the module raises an error and fails to load. The integrity test can be performed on demand by power cycling the host platform.
Each time the module is powered up, it runs the pre-operational tests to ensure that the integrity of the module has been maintained. Self-tests are available on demand by power cycling the module.
The module operates in a modifiable operational environment under the FIPS 140-3 definitions. The module runs on a GPC running one of the operating systems specified in the approved operational environment list (refer to Section 2.2 of this Security Policy). Each approved operating system manages processes and threads in a logically separated manner. The module’s operator is considered the owner of the calling application that instantiates the module within the process space of the Java Virtual Machine.
The module must be installed as described in Security Policy Section 11.1. No specific configuration options are required for the operational environments. No security rules, settings, or restrictions to the configuration of the operational environment are needed for the module to function in a FIPS-conformant manner.
The requirements of this section are not applicable to the module. The module is a software module and does not implement any physical security mechanisms.
The requirements of this section are not applicable to the module.
All Sensitive Security Parameters (SSPs) used by the module are described in this section in Table 16. All usage of these SSPs by the module (including all SSP lifecycle states) is described in the services detailed in Section 4.3 - Approved Services. Please note that the module does not perform automatic SSP establishment, it only provides the components to the calling application, which can be used in SSP establishment.
Table 16 - Sensitive Security Parameters (SSPs) Key Table Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number AES Encryption 128, 192, 256 AES CBC, DRBG20 Import21, N/A N/A destroy() service AES Key bits AES CFB8, Export22 call or host encryption23 AES platform power CFB128, cycle AES CTR, AES ECB, AES FF1, AES OFB, AES CBCCS1, AES CBC-CS2, AES CBCCS3, AES CCM, AES GCM, CKG A6047 The module does not provide persistent storage Key generator used in conjunction with an approved DRBG Import done via key constructor and/or factory (Electronic Entry) Export done via key recovery using getEncoded() method and followed by separate step to export key details as either plaintext or encrypted (Electronic Entry)
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number AES Decryption 128, 192, 256 AES CBC, DRBG20 Import21, N/A N/A destroy() service AES Key bits AES CFB8, Export22 call or host decryption AES platform power CFB128, cycle AES CTR, AES ECB, AES FF1, AES OFB, AES CBCCS1, AES CBC-CS2, AES CBCCS3, AES CCM, AES GCM, CKG A6047 AES 128, 192, 256 AES CMAC, DRBG20 Import21, N/A N/A destroy() service AES Authentication bits AES GMAC, Export22 call or host CMAC/GMAC Key CKG platform power cycle A6047 The AES GCM key and IV is generated randomly per IG C.H, and the Initialization Vector (IV) is a minimum of 96 bits. In the event module power is lost and restored, the consuming application must ensure that any of its AES GCM keys used for encryption or decryption are re-distributed. Refer to Section 2.6.1 of the Security Policy.
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number AES Wrapping 128, 192, 256 AES KW, DRBG20 Import21, N/A N/A destroy() service AES Key bits AES KWP, Export22 call or host (128/192/256) CKG platform power key wrapping cycle key for KTS A6047 DH Agreement 112, 128, 152, KAS-FFC, DRBG20 Import21, N/A N/A destroy() service Diffie-Hellman Private Key 176, 200 bits CKG Export22 call or host (ffdhe and platform power MODP) key A6047 cycle agreement May be paired with DH Agreement Public Key DH Agreement 112, 128, 152, KAS-FFC, DRBG20 Import21, N/A N/A Not zeroized, Diffie-Hellman Public Key 176, 200 bits CKG Export22 public key value (ffdhe and known outside of MODP) key A6047 module agreement May be paired with DH Agreement Private Key
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number DSA Signing 112, 128 bits DSA DRBG20 Import21, N/A N/A destroy() service DSA signature Key Signature Export22 call or host generation Generation, platform power CKG cycle May be paired with DSA A6047 Verification Key DSA 80, 112, 128 DSA DRBG20 Import21, N/A N/A Not zeroized, DSA signature Verification bits Signature Export22 public key value verification Key Verification, known outside of CKG module May be paired with DSA A6047 Signing Key EC Agreement 112, 128, 192, KAS-ECC, DRBG20 Import21, N/A N/A destroy() service EC key Private Key 256 bits CKG Export22 call or host agreement platform power A6047 cycle May be paired with EC Agreement Public Key
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number EC Agreement 112, 128, 192, KAS-ECC, DRBG20 Import21, N/A N/A Not zeroized, EC key Public Key 256 bits CKG Export22 public key value agreement known outside of A6047 module May be paired with EC Agreement Private Key EC Signing Key 112, 128, 192, ECDSA DRBG20 Import21, N/A N/A destroy() service ECDSA
256 bits Signature Export22 call or host signature
Generation, platform power generation. CKG cycle May be paired A6047 with EC Verification Key EC Verification 112, 128, 192, ECDSA DRBG20 Import21, N/A N/A Not zeroized, ECDSA Key 256 bits Signature Export22 public key value signature Verification, known outside of verification. CKG module May be paired A6047 with EC Signing Key
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number HMAC 112-256 bits HMAC-SHA- DRBG20 Import21, N/A N/A destroy() service Keyed-Hash Authentication 1, HMAC- Export22 call or host Calculation Key SHA-2, platform power HMAC-SHA- cycle 3, CKG A6047 KMAC 112-256 bits KMAC, CKG DRBG20 Import21, N/A N/A destroy() service Keyed-Hash Authentication Export22 call or host Calculation Key A6047 platform power cycle RSA Signing 112, 128, 152 RSA DRBG20 Import21, N/A N/A destroy() service RSA signature Key bits Signature Export22 call or host generation Generation, platform power CKG cycle May be paired with RSA A6047 Verification Key RSA 80, 112, 128, RSA DRBG20 Import21, N/A N/A Not zeroized, RSA signature Verification 152 bits Signature Export22 public key value verification Key Verification, known outside of CKG module May be paired with RSA A6047 Signing Key
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number RSA Key 112, 128, 152 KTS-IFC, DRBG20 Import21, N/A N/A destroy() service RSA key Transport bits CKG Export22 call or host transport and Private Key24 platform power decryption A6047 cycle May be paired with RSA Public Key Transport Key RSA Key 112, 128, 152 KTS-IFC, DRBG20 Import21, N/A N/A Not zeroized, RSA key Transport bits CKG Export22 public key value transport Public Key24 known outside of A6047 module May be paired with RSA Key Transport Private Key IKEv2 KDF 112, 128, 192, KDF IKEv2 Generated as N/A N/A N/A destroy() service Key Derivation Secret Value 256 bits output of an call or host A6047 IKEv2 platform power agreement cycle scheme PBKDF Secret 112-256 bits PBKDF Generated as N/A N/A N/A destroy() service Key Derivation Value output of a call or host A6047 PBE key and a platform power PRF cycle RSA key transport using PKCS#1 1.5 padding is deprecated through 2023 and disallowed after 2023.
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number SP 800-56Cr2 112, 128, 192, KDA Generated as N/A N/A N/A destroy() service Key Derivation OneStep/ 256 bits OneStep SP output of an call or host TwoStep KDF 800-56Cr2, agreement platform power Secret Value KDA scheme cycle TwoStep SP 800-56Cr2 A6047 SP 800-108r1 112, 128, 192, KDF SP 800- Generated as N/A N/A N/A destroy() service Key Derivation KDF Secret 256 bits 108 output of an call or host Value A6047 agreement platform power scheme cycle SRTP KDF 128, 192, 256 KDF SRTP Generated as N/A N/A N/A destroy() service Key Derivation Secret Value bits output of an call or host A6047 SRTP platform power agreement cycle scheme SSH KDF Secret 80, 112, 128, KDF SSH Generated as N/A N/A N/A destroy() service Key Derivation Value 192, 256 bits output of an call or host A6047 SSH platform power agreement cycle scheme
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number TLS Premaster 384 bits KDF TLS Protocol Import21, N/A N/A destroy() service Used to derive Secret Value version (2 Export22 call or host keys using TLS A6047 bytes) and 46 platform power KDF bytes from a cycle DRBG20 TLS KDF Secret 112, 128, 192, KDF TLS Generated as N/A N/A N/A destroy() service Key Derivation Value 256 bits output of TLS call or host A6047 agreement platform power scheme cycle X9.63 KDF 112, 128, 192, KDF ANS Generated as N/A N/A N/A destroy() service Key Derivation Secret Value 256 bits 9.63 output of an call or host agreement platform power A6047 scheme cycle Entropy Input >128 bits N/A N/A Obtained N/A N/A destroy() service Random String from the call or host Number entropy platform power Generation source cycle CTR DRBG Seed 128, 192, 256 N/A N/A From N/A N/A Immediately Internal use bits external after use or host entropy platform power source cycle CTR DRBG V 128 bits N/A From seed N/A N/A N/A reseed() service Internal use Value value call or host platform power cycle
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number CTR DRBG Key 128, 192, 256 N/A From DRBG V N/A N/A N/A reseed() service Internal use bits value call or host platform power cycle Hash DRBG 112, 128, 192, N/A N/A From N/A N/A Immediately Internal use Seed 256 bits external after use or host entropy platform power source cycle Hash DRBG V 112, 128, 192, N/A From seed N/A N/A N/A reseed() service Internal use Value 256 bits value call or host platform power cycle Hash DRBG C 112, 128, 192, N/A From DRBG V N/A N/A N/A reseed() service Internal use Value 256 bits value call or host platform power cycle HMAC DRBG 112, 128, 192, N/A N/A From N/A N/A Immediately Internal use Seed 256 bits external after use or host entropy platform power source cycle HMAC DRBG V 112, 128, 192, N/A From seed N/A N/A N/A reseed() service Internal use Value 256 bits value call or host platform power cycle
Security SSP Name / Function & Import / Use & related Strength Generation Establishment Storage19 Zeroisation Type Cert. Export keys Number HMAC DRBG 112, 128, 192, N/A From DRBG V N/A N/A N/A reseed() service Internal use Key 256 bits value call or host platform power cycle DRBG Output 128, 192, 256 N/A DRBG N/A N/A N/A destroy() service Used as seed bits call or host for platform power asymmetric cycle key generation or for symmetric key generation
Cryptographic Algorithm Self-Tests (CASTs) are performed prior to the first use of services related to the test target. CASTs also run periodically on service invocation. Pairwise Consistency Tests (PCTs) are performed on the corresponding key pairs.
Each time the module is powered up, it performs the pre-operational self-tests to confirm that sensitive data has not been damaged. The pre-operational tests include the software integrity test, which verifies the module using HMACSHA-256. Pre-operational tests also include the HMAC and SHS CASTs that are run prior to the software integrity test to ensure the correctness of the HMAC used. Pre-operational self-tests are available on demand by power cycling the module.
The module performs conditional self-tests when the conditions specified for cryptographic algorithm self-test and pair-wise consistency tests occur. The self-tests implemented are specified below. Table 17
Test Target Description ECDSA Signature Generation KAT (P-256) ECDSA Signature Verification KAT (P-256) HMAC-SHA2-256 HMAC-SHA2-256 KAT HMAC-SHA2-512 HMAC-SHA2-512 KAT HMAC-SHA3-256 HMAC-SHA3-256 KAT KAS-ECC Primitive “Z” Computation KAT (P-256) KAS-ECC Primitive “Z” Computation KAT (B-233) KAS-FFC Primitive “Z” Computation KAT (ffdhe2048) KBKDF KBKDF KAT (Counter, Feedback, Double Pipeline) KDA OneStep KDA OneStep KAT KDA TwoStep KDA TwoStep KAT PBKDF PBKDF KAT (HMAC-SHA2-256) RSA Signature Generation KAT (2048 bits) RSA Signature Verification KAT (2048 bits) RSA Encryption RSA Encryption KAT SP 800-56Br2 (2048 bits) RSA Decryption RSA Decryption KAT SP 800-56Br2 (2048 bits) SHA-1 SHA-1 KAT SHA2-256 SHA2-256 KAT SHA2-512 SHA2-512 KAT SHA-3 SHA-3 KAT (cSHAKE-128) SHAKE256 SHAKE256 KAT ANS 9.63 KDF ANS 9.63 KDF KAT IKEv2 KDF IKEv2 KDF KAT SNMP KDF SNMP KDF KAT SRTP KDF SRTP KDF KAT SSH KDF SSH KDF KAT TLS 1.0 KDF TLS 1.0 KDF KAT TLS 1.1 KDF TLS 1.1 KDF KAT TLS 1.2 KDF TLS 1.2 KDF KAT Table 18
If any of the above-mentioned self-tests fail, the module enters an error state called “Hard Error” state. Upon entering the error state, the module outputs status by way of an exception. An example exception for AES Encryption failure is: “Failed self-test on encryption: AES” The module can be recovered by power cycling, which results in execution of pre-operational self-tests and conditional cryptographic algorithm self-tests. If the tests pass, then the module will be available for use.
Each time the module is powered up, it runs the pre-operational tests to ensure that the integrity of the module has been maintained. Pre-operational self-tests are available on demand by power cycling the module. Initial CAST self-tests are available on demand by power cycling the module and then invoking the service related to the test target.
The module exists as part of the running JVM, and as such:
The JAR file representing the module needs to be installed in a JVM's class path in a manner appropriate to its use in applications running on the JVM. Functionality in the module is provided in two ways. At the lowest level there are distinct classes that provide access to the approved and non-approved services provided by the module. A more abstract level of access can also be gained by using strings providing operation names passed into the module's Java cryptography provider through the APIs described in the Java Cryptography Architecture (JCA) and the Java Cryptography Extension (JCE). When the module is used in approved mode, classes providing implementations of algorithms that are not approved or allowed are explicitly disabled. SSPs such as private and secret keys implement the Destroyable interface. Where appropriate these SSPs can be zeroized on demand by invoking the destroy() method. The return of the destroy() method indicates that the zeroization is complete.
If the underlying JVM is running with a Java SecurityManager installed, the module will be running in approved mode with secret and private key export disabled.
In the presence of a Java SecurityManager approved mode services specific to a context, such as DSA and ECDSA for use in TLS, require specific policy permissions to be configured in the JVM configuration by the Cryptographic Officer or User. The SecurityManager can also be used to restrict the ability of particular code bases to examine CSPs. In the absence of a Java SecurityManager specific services related to protocols such as TLS are available, however must only be used in relation to those protocols.
Use of the module with a Java SecurityManager requires the setting of some basic permissions to allow the module HMAC-SHA-256 software integrity test to take place as well as to allow the module itself to examine secret and private keys. The basic permissions required for the module to operate correctly with a Java SecurityManager are indicated by the Required column of Table 19. Table 19 - Available Java Permissions for SecurityManager Permission Settings Required Usage RuntimePermission getProtectionDomain Yes Allows checksum to be carried out on JAR. RuntimePermission accessDeclaredMembers Yes Allows use of reflection API within the provider. PropertyPermission java.runtime.name, No Only if configuration read properties are used. SecurityPermission putProviderProperty.CCJ No Only if provider installed during execution. CryptoServicesPermission unapprovedModeEnabled No Only if non-approved mode algorithms required. CryptoServicesPermission changeToApprovedModeEnabled No Only if threads allowed to change modes. CryptoServicesPermission exportSecretKey No To allow export of secret keys only. CryptoServicesPermission exportPrivateKey No To allow export of private keys only. CryptoServicesPermission exportKeys Yes Required to be applied for the module itself. Optional for any other codebase. CryptoServicesPermission tlsNullDigestEnabled No Only required for TLS digest calculations. CryptoServicesPermission tlsPKCS15KeyWrapEnabled No Only required if TLS is used with RSA encryption.
Permission Settings Required Usage CryptoServicesPermission tlsAlgorithmsEnabled No Enables both NullDigest and PKCS15KeyWrap. CryptoServicesPermission defaultRandomConfig No Allows setting of default SecureRandom. CryptoServicesPermission threadLocalConfig No Required to set a thread local property in the CryptoServicesRegistrar. CryptoServicesPermission globalConfig No Required to set a global property in the CryptoServicesRegistrar.
The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-3 Level 1 module.
When the module is used within the context of Java Security Manager or the system/security property com.safelogic.cryptocomply.fips.approved_only is set to true, the module will start in approved mode and non-approved services are not accessible in this mode. When the module is not used within the context of Java Security Manager, the module will start in non-approved mode by default. Refer to Security Policy Section 2.4 for additional details.
The transition from non-approved mode to approved mode is a combination of granted permission (a) and request to change mode (b): a) com.safelogic.cryptocomply.crypto.CryptoServicesPermission “changeToApprovedModeEnabled” b) CryptoServicesRegistrar.setApprovedMode(true) The CSPs made available in non-approved mode will not be accessible once the thread transitions into approved mode. The CSPs generated using the non-approved mode cannot be passed or shared with algorithms operating in approved mode, and vice-versa. This is done by an indicator within the class (object) instantiating the key that the key was created in an approved mode or non-approved mode. Any attempt by a thread within the module to use the key in an opposite mode will result in an exception being generated by the module. For example, if an RSA private key has been created in either approved or non-approved mode, then any request to access that key will first need to confirm if the thread making the request is in the same mode.
The module cannot transition from approved mode to non-approved mode. To initiate the module in non-approved mode, either it should not be used in the context of Java Security Manager, or the module should have the permission com.safelogic.cryptocomply.crypto.CryptoServicesPermission unapprovedModeEnabled granted by the Java Security Manager.
Vulnerabilities found in the module will be reported on the National Vulnerability Database, located at the following link: https://nvd.nist.gov/ Researchers and users are encouraged to report any security related concerns to CGI. Contact information can be found on the FIPS 140 certificate for this module.
The module implements basic protections to mitigate against timing-based attacks against its internal implementations. There are two countermeasures used. The first countermeasure is Constant Time Comparisons, which protect the digest and integrity algorithms by strictly avoiding “fast fail” comparison of MACs, signatures, and digests so the time taken to compare a MAC, signature, or digest is constant regardless of whether the comparison passes or fails. The second countermeasure is made up of Numeric Blinding and decryption/signing verification which both protect the RSA algorithm. Numeric Blinding prevents timing attacks against RSA decryption and signing by providing a random input into the operation which is subsequently eliminated when the result is produced. The random input makes it impossible for a third party observing the private key operation to attempt a timing attack on the operation as they do not have knowledge of the random input and consequently the time taken for the operation tells them nothing about the private value of the RSA key. Decryption/signing verification is carried out by calculating a primitive encryption or signature verification operation after a corresponding decryption or signing operation before the result of the decryption or signing operation is returned. The purpose of this is to protect against Lenstra's CRT attack by verifying the correctness of the private key calculations involved. Lenstra's CRT attack takes advantage of undetected errors in the use of RSA private keys with CRT values and, if exploitable, can be used to discover the private value of the RSA key.
Appendix: References and Acronyms The following standards are referred to in this Security Policy. Table 20 - References Abbreviation Full Specification Name ANSI X9.31 X9.31-1998, Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA), September 9, 1998 FIPS 140-3 Security Requirements for Cryptographic modules, March 22, 2019 FIPS 180-4 Secure Hash Standard (SHS) FIPS 186-2 Digital Signature Standard (DSS) FIPS 186-4 Digital Signature Standard (DSS) FIPS 186-5 Digital Signature Standard (DSS) FIPS 197 Advanced Encryption Standard FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program PKCS#1 v2.1 RSA Cryptography Standard PKCS#5 Password-Based Cryptography Standard PKCS#12 Personal Information Exchange Syntax Standard -Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher SP 800-38A Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode SP 800-38B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication SP 800-38C Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping SP 800-38G Recommendation for Block Cipher Modes of Operation: Methods for FormatPreserving Encryption SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography SP 800-56Br2 Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography SP 800-56Cr2 Recommendation for Key Derivation through Extraction-then-Expansion SP 800-67r2 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher SP 800-89 Recommendation for Obtaining Assurances for Digital Signature Applications SP 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators
Abbreviation Full Specification Name SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation SP 800-108r1 Recommendation for Key Derivation Using Pseudorandom Functions SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-132 Recommendation for Password-Based Key Derivation SP 800-133r2 Recommendation for Cryptographic Key Generation SP 800-135r1 Recommendation for Existing Application
The following acronyms are used in this Security Policy. Table 21 - Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface CAST Cryptographic Algorithm Self-Test CBC Cipher-Block Chaining CCM Counter with CBC-MAC CCCS Canadian Centre for Cyber Security CDH Computational Diffie-Hellman CFB Cipher Feedback Mode CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CO Cryptographic Officer CPU Central Processing Unit CS Ciphertext Stealing CSP Critical Security Parameter CTR Counter Mode CVL Component Validation List DES Data Encryption Standard DH Diffie-Hellman DRAM Dynamic Random Access Memory DRBG Deterministic Random Bit Generator DSA Digital Signature Algorithm DSTU4145 Ukrainian DSTU-4145-2002 Elliptic Curve Scheme EC Elliptic Curve ECB Electronic Code Book ECC Elliptic Curve Cryptography ECDSA Elliptic Curve Digital Signature Algorithm EdDSA Edwards Curve DSA using Ed25519, Ed448 EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GCM Galois/Counter Mode GMAC Galois Message Authentication Code GOST Gosudarstvennyi Standard Soyuza SSR/Government Standard of the Union of Soviet Socialist Republics GPC General Purpose Computer HMAC (Keyed) Hashed Message Authentication Code IG Implementation Guidance, see References IV Initialization Vector JAR Java ARchive
Acronym Definition JCA Java Cryptography Architecture JCE Java Cryptography Extension JDK Java Development Kit JRE Java Runtime Environment JVM Java Virtual Machine KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function KW Key Wrap KWP Key Wrap with Padding KMAC KECCAK Message Authentication Code MAC Message Authentication Code MD5 Message Digest algorithm MD5 N/A Not Applicable OCB Offset Codebook Mode OFB Output Feedback OS Operating System PBKDF Password-Based Key Derivation Function PKCS Public Key Cryptography Standards PQG Diffie-Hellman Parameters P, Q and G RC Rivest Cipher, Ron’s Code RIPEMD RACE Integrity Primitives Evaluation Message Digest RSA Rivest Shamir Adleman SHA Secure Hash Algorithm SSP Sensitive Security Parameter TLS Transport Layer Security USB Universal Serial Bus XDH Edwards Curve Diffie-Hellman using X25519, X448 XOF Extendable-Output Function
Prepared By: SafeLogic, Inc. Website: www.safelogic.com Email: sales@safelogic.com Phone: 844-436-2797