| 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 | Certes Networks, Inc. |
flowchart LR
%% Deterministic review-risk graph for Certes 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 Certes 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;Certes Networks, Inc. Certes Java Cryptographic Module Non-Proprietary FIPS 140-3 Cryptographic Module Security Policy Software Version: 2.0.0 Date: 11/26/24 Prepared by: Corsec Security, Inc. Certes Networks, Inc.
12600 Fair Lakes Circle, Suite 210 300 Corporate Center Dr., Suite 140
Fairfax, VA 22033 Pittsburgh, PA 15108 www.corsec.com https://certesnetworks.com/ only in its original entirety (without revision).
only in its original entirety (without revision).
| # | Section | Page |
|---|
| Item | Page |
|---|---|
| Table 1 - Security Levels | 4 |
| Table 2 - Tested Operational Environments | 6 |
| Table 3 - Vendor Affirmed Operational Environments | 9 |
| Table 4 - Approved Algorithms | 16 |
| Claimed | 16 |
| Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation | 18 |
| Table 7 - Ports and Interfaces | 22 |
| Table 8 - Roles, Service Commands, Input and Output | 23 |
| Table 9 - Roles and Authentication | 24 |
| Table 10 - Approved Services | 31 |
| Table 11 - Non-Approved Services | 32 |
| Table 12 - SSPs | 45 |
| Table 13 - Non-Deterministic Random Number Generation Specification | 46 |
| Figure 1- Cryptographic boundary | 5 |
This document defines the Security Policy for the Certes Networks, Inc.'s Certes Java Cryptographic Module , hereafter denoted as the Module. The Module is a cryptographic library and has a Multi-Chip Stand Alone embodiment. The Module meets FIPS 140- 3 overall Level 1 requirements. The SW version is 2.0.0. The FIPS 140-3 security levels for the Module are given in Table 1 as follows: ISO/IEC 24759 Security FIPS 140-3 Section Title Section 6. Number Level
The module checksum, functionality, and versioning can be confirmed by executing the command: java -cp bc-fips-2.0.0.jar org.bouncycastle.util.DumpInfo which should display: Version Info: BouncyCastle Security Provider (FIPS edition) v2.0.0 FIPS Ready Status: READY Module SHA-256 HMAC: 164c8ae41945cb85fdc65666fc4de7301a65d29659ecd455ee5199c7d42d107e Indicating the jar represents the software release BC-FJA 2.0.0 (correlating to “Certes Java Cryptographic Module”), that it has successfully passed all its startup tests, and that the software release is confirmed to have a HMAC of: 164c8ae41945cb85fdc65666fc4de7301a65d29659ecd455ee5199c7d42d107e only in its original entirety (without revision).
The Module is intended for use by US Federal agencies and other markets that require a FIPS 140-3 validated Cryptographic Library. The Module is of type software and the module has a Multi-Chip Stand Alone embodiment; the cryptographic boundary is the Java Archive (JAR) file, bc-fips2.0.0.jar. This module is the only software component within the Cryptographic Boundary and the only software component that carries out cryptographic functions covered by FIPS 140-3. Figure 1 shows the logical relationship of the cryptographic module to the other software and hardware components of the computer. The BC 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) that is the interface to the various physical components of the computer. Figure 1- Cryptographic boundary The cryptographic module was tested on the following operational environments on the generalpurpose computer (GPC) platforms detailed in Table 2, which is also the TOEPP (Tested Operational Environment’s Physical Perimeter) of the module. only in its original entirety (without revision).
# Operating System Hardware Platform Processor PAA/Acceleration
1 VMware Photon OS 4.0 Dell PowerEdge Intel Xeon Gold Without PAA
with JRE 8 on VMware R650 6330 ESXi 8.0
2 VMware Photon OS 4.0 Dell PowerEdge Intel Xeon Gold Without PAA
with JRE 11 on VMware R650 6330 ESXi 8.0
3 VMware Photon OS 4.0 Dell PowerEdge Intel Xeon Gold Without PAA
with JRE 17 on VMware R650 6330 ESXi 8.0
4 VMware Photon OS 5.0 Dell PowerEdge Intel Xeon Gold Without PAA
with JRE 21 on VMware R650 6330 ESXi 8.0 Table 2 - Tested Operational Environments The cryptographic module will remain compliant with the FIPS 140-3 validation when operating on any general-purpose computer (GPC) provided that:
1 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
2 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
3 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
4 Java SE Runtime Environment v21 (21) Generic Hardware Platform
5 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
6 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
7 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
8 Java SE Runtime Environment v21 (21) Generic Hardware Platform
9 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Red Hat Enterprise Linux
10 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
with Red Hat Enterprise Linux
11 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
with Red Hat Enterprise Linux
12 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with Red Hat Enterprise Linux only in its original entirety (without revision).
13 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
14 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
15 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
16 Java SE Runtime Environment v21 (21) Generic Hardware Platform
17 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
18 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
19 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
20 Java SE Runtime Environment v21 (21) Generic Hardware Platform
21 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Linux Oracle RHC
22 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
with Linux Oracle RHC
23 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
with Linux Oracle RHC
24 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with Linux Oracle RHC
25 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Linux Oracle UEK
26 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
with Linux Oracle UEK
27 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
with Linux Oracle UEK
28 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with Linux Oracle UEK
29 Java SE Runtime Environment v17 (1.8) Generic Hardware Platform
30 Java SE Runtime Environment v17 (1.11) Generic Hardware Platform
31 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
32 Java SE Runtime Environment v21 (21) Generic Hardware Platform
33 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
34 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
35 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
36 Java SE Runtime Environment v21 (21) Generic Hardware Platform
37 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Linux Ubuntu only in its original entirety (without revision).
38 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
39 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
40 Java SE Runtime Environment v21 (21) Generic Hardware Platform
41 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
42 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
43 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
44 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
45 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
46 Java SE Runtime Environment v21 (21) Generic Hardware Platform
47 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Microsoft Windows Server
48 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
with Microsoft Windows Server
49 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
with Microsoft Windows Server
50 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with Microsoft Windows Server
51 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
with Microsoft Windows XP
52 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
with Microsoft Windows XP
53 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
with Microsoft Windows XP
54 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with Microsoft Windows XP
55 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
56 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
57 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
58 Java SE Runtime Environment v21 (21) Generic Hardware Platform
59 Java SE Runtime Environment v8 (1.8) Generic Hardware Platform
60 Java SE Runtime Environment v11 (1.11) Generic Hardware Platform
61 Java SE Runtime Environment v17 (1.17) Generic Hardware Platform
62 Java SE Runtime Environment v21 (21) Generic Hardware Platform
with AIX only in its original entirety (without revision).
63 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Cascade
with Red Hat Enterprise Linux Lakes
64 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Cascade
with Red Hat Enterprise Linux Lakes
65 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Sapphire
with Red Hat Enterprise Linux Rapids
66 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Sapphire
with Red Hat Enterprise Linux Rapids
67 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Cascade
68 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Cascade
69 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Sapphire
70 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Sapphire
71 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Cascade
72 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Cascade
73 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Sapphire
74 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Sapphire
75 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel Haswell
76 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel Haswell
77 Java SE Runtime Environment v17 (1.17) Generic hardware platform with Intel
78 Java SE Runtime Environment v21 (21) Generic hardware platform with Intel
with ClevOS Broadwell Table 3 - Vendor Affirmed Operational Environments For the avoidance of doubt, it is hereby stated that 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. The Module implements the Approved and Non-Approved but Allowed cryptographic functions with no security claimed listed in Tables 4 and 5 below. 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. The Module supports both Approved and Non-Approved mode of operation. Please see Section 6.3 for configuration of the Module in Approved mode of operation. Please see Section 11 for initialization steps. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 AES ECB, CBC, Key sizes: 128, 192, 256 bits Encryption, [FIPS 197, SP OFB, CFB8, Decryption 800-38A], AES- CFB128, CTR, FF1 Format FF1 Preserving Encryption [SP 800-38G] A4399 AES-CBC CBC-CS1, Key sizes: 128, 192, 256 bits Encryption, Ciphertext CBC-CS2, Decryption Stealing (CS) CBC-CS3 [Addendum to SP 800-38A, Oct 2010] A4399 CCM N/A Key sizes: 128, 192, 256 bits Generation, [SP 800-38C] Authentication A4399 CMAC AES Key sizes: AES with 128, Generation, [SP 800-38B] 192, 256 bits Authentication A4399 GCM/GMAC1 N/A Key sizes: 128, 192, 256 bits Generation, [SP 800-38D] Authentication A4399 Counter DRBG N/A AES-CTR [SP 800-90Ar1] AES-128, AES-192, AES- DRBG. A4399 Hash DRBG N/A SHA sizes: SHA-1, SHA2- Hash DRBG [SP 800-90Ar1] 224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 A4399 HMAC DRBG N/A SHA sizes: SHA-1, SHA2- HMAC DRBG [SP 800-90Ar1] 224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 GCM encryption with an internally generated IV, see section 2.2 concerning external IVs. IV generation is compliant with IG C.H. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 DSA2 N/A Key sizes: 1024, 2048, 3072 PQG [FIPS 186-4] bits (1024 only for SigVer) Generation, PQG Verification, Key Pair Generation, Signature Generation, Signature Verification A4399 ECDSA N/A Curves/Key sizes: P-192*, P- Public Key [FIPS 186-4] 224, P-256, P-384, P-521, K- Generation, 163*, K-233, K-283, K-409, Signature K-571, B-163*, B-233, B- Generation, 283, B-409, B-571 Signature Verification, Public Key Validation * Curves only used for Signature Verification and Public Key Validation A4399 KDA-HKDF N/A PRFs: HMAC SHA-1, Key Derivation [SP 800-56C- HMAC SHA-224, HMAC rev2] SHA-256, HMAC SHA-384, HMAC SHA-512, HMAC SHA-512/224, HMAC SHA512/256, HMAC SHA3-224, HMAC SHA3-256, HMAC SHA3-384, HMAC SHA3A4399 HMAC N/A SHA sizes: SHA-1, SHA- Generation, [FIPS 198-1] 224, SHA-256, SHA-384, Authentication SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512 DSA signature generation with SHA-1 is only for use with protocols. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 KAS-FFC3 N/A Domain Parameter Key Agreement [SP 800-56A- Generation rev3] Methods/Scheme: 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
strength A4399 KAS-ECC3 N/A Domain Parameter Key Agreement [SP 800-56A- Generation rev3] Methods/Scheme: P-224, P256, P-384, P-521,K-233, K283, K-409, K-571, B-233, B-283, B-409, B-571 ephemeralUnified, fullMqv, fullUnified, onePassDh, onePassMqv, onePassUnified, staticUnified Curves specified above providing between 112 and
strength A4399 KDA, One Step N/A PRFs: SHA-1, SHA-224, Key Derivation [SP 800-56C- SHA-256, SHA-384, SHArev2] 512, SHA-512/224, SHA512/256, SHA3-224, SHA3256, SHA3-384, SHA3-512, HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384, HMAC SHA-512, HMAC SHA512/224, HMAC SHA512/256, HMAC SHA3-224, HMAC SHA3-256, HMAC SHA3-384, HMAC SHA3512, KMAC-128, KMACKeys are not established directly into the module using the key agreement algorithms. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 KDA, Two Step N/A PRFs: HMAC SHA-1, Key Derivation [SP 800-56C- HMAC SHA-224, HMAC rev2] SHA-256, HMAC SHA-384, HMAC SHA-512, HMAC SHA-512/224, HMAC SHA512/256, HMAC SHA3-224, HMAC SHA3-256, HMAC SHA3-384, HMAC SHA3512, KMAC-128, KMACCVL KDF, Existing N/A TLS v1.0/1.1 KDF Key Derivation A4399 ApplicationSpecific4 SHA sizes: SHA2-256 , [SP 800-135- SHA2-384, SHA2-512 rev1] CVL KDF, Existing N/A TLS 1.2 KDF Key Derivation A4399 ApplicationSpecific4 SHA sizes: SHA2-256, [SP 800-135- SHA2-384, SHA2-512 rev1] CVL KDF, Existing N/A SNMP KDF Key Derivation A4399 ApplicationSpecific4 Password Length: 64, 8192 [SP 800-135rev1] CVL KDF, Existing N/A SSH KDF Key Derivation A4399 ApplicationSpecific4 SHA sizes: SHA2-224 [SP 800-135rev1] CVL KDF, Existing N/A X9.63 KDF Key Derivation A4399 Application- Can be used Specific4 along with KASSHA sizes: SHA2-224, [SP 800-135- SHA2-256, SHA2-384, SSC rev1] SHA2-512 CVL KDF, Existing N/A IKEv2 KDF Key Derivation A4399 Application- SHA sizes:SHA-1, SHA2Specific4 224, SHA2-256, SHA2-384, [SP 800-135- SHA2-512 rev1] No parts of the protocols (TLS, SSHv2, X9.63, IKEv2, SRTP, SNMPv3), other than the approved cryptographic algorithms and the KDFs, have been reviewed or tested by the CAVP and CMVP. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) CVL KDF, Existing N/A SRTP KDF Key Derivation A4399 ApplicationSpecific4 [SP 800-135rev1] A4399 KDF, Password- N/A Options: PBKDF with Key Derivation Based Option 1a [SP 800-132] Types: HMAC-based KDF using SHA-1, SHA-224, SHA-256, SHA-384, SHAA4399 KDF, using Counter Mode, Types: CMAC-based Key Derivation Pseudorandom Feedback KBKDF with AES, HMACFunctions5 Mode, Double- based KBKDF with SHA-1, [SP 800-108- Pipeline SHA-224, SHA-256, SHArev1] Iteration Mode 384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 A4399 Key Wrapping AES KW, Key sizes: 128, 192, 256 bits Key Wrapping Using Block KWP (Key establishment Ciphers6 methodology providing 128, [SP 800-38F] 192 or 256 bits of encryption strength) A4399 RSA N/A Key sizes: 2048, 3072, 4096 Key Pair [FIPS 186-4, Generation ANSI X9.31-
#1 v2.1 (PSS and PKCS1.5)] A4399 RSA N/A Key sizes: 2048, 3072, 4096 Signature [FIPS 186-4, Generation ANSI X9.31-
#1 v2.1 (PSS and PKCS1.5)] 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. Keys are not established directly into the module using key unwrapping. only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 RSA N/A Key sizes: 1024, 2048, 3072, Signature [FIPS 186-4, 4096 Verification ANSI X9.31-
#1 v2.1 (PSS and PKCS1.5)] A4399 RSA [FIPS 186- N/A Key sizes: 1024, 1536, 2048, Signature 2, ANSI X9.31- 3072, 4096 Verification
#1 v2.1 (PSS and PKCS1.5)] CVL RSA Decryption N/A 2048 Component Test A4399 Primitive CVL RSA Signature N/A 2048 Component Test A4399 Primitive A4399 KTS-IFC N/A RSA-OAEP with, and Key Transport [SP 800-56B- without, key confirmation. rev2, Section Key sizes: 2048, 3072, 4096 7.2.2] providing between 112 and
strength Key Generation Method: rsakpg2-crt A4399 KAS-IFC N/A RSASVE with, and without, Key Agreement [SP 800-56B- key confirmation. rev2, Section Key sizes: 2048, 3072, 4096 7.2.1] providing between 112 and
strength A4399 Safe Primes N/A Parameter sets: ffdhe2048, Key Generation, [SP 800-56A- ffdhe3072, ffdhe4096, Key Verification rev3] ffdhe6144, ffdhe8192, MODP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192 A4399 SHS N/A SHA sizes: SHA-1, SHA- Digital Signature [FIPS 180-4] 224, SHA-256, SHA-384, Generation, SHA-512, SHA-512/224, Digital Signature SHA-512/256 Verification, nonDigital Signature Applications only in its original entirety (without revision).
CAVP Algorithm Mode/Method Description / Key Sizes(s) / Use / Function Cert and Standard Key Strength(s) A4399 SHA-3, N/A SHA3-224, SHA3-256, Digital Signature SHAKE SHA3-384, SHA3-512, Generation, [FIPS 202] SHAKE128, SHAKE256 Digital Signature Verification, nonDigital Signature Applications A4399 SHA-3 Derived N/A Types: cSHAKE-128, Digital Signature Functions KMAC-128, TupleHash-128, Generation, [SP 800-185] ParallelHash-128, cSHAKE- Digital Signature 256, KMAC-256, Verification, nonTupleHash-256, Digital Signature ParallelHash-256 Applications Vendor CKG using N/A Section 5.1 (Asymmetric Key Generation Affirmed output from from DRBG) IG D.H DRBG7 Section 6.1 (Symmetric from [SP 800-133- DRBG) rev2] Table 4 - Approved Algorithms Algorithm Caveat Use / Function MD5 within TLS Allowed per IG 2.4.A, no MD5 used within a TLS handshake security claimed Table 5 - Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Algorithm/Function Use/Function AES (non-compliant8) 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- non-compliant key agreement methods compliant9) The resulting key or a generated seed is an unmodified output from a DRBG. Support for additional modes of operation. Support for additional key sizes and the establishment of keys of less than 112 bits of security strength. only in its original entirety (without revision).
Algorithm/Function Use/Function DSA (non-compliant10) non-approved digest signatures using DSA DSTU4145 DSTU4145 EC algorithm ECDSA (non-compliant ) non-approved digest signatures using ECDSA EdDSA Ed25519 and Ed448 signature algorithms ElGamal ElGamal key transport algorithm FF3-1 Format Preserving Encryption
Algorithm/Function Use/Function Poly1305 Poly1305 message MAC 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-compliant12) Non-compliant RSA signature schemes RSA KTS (non-compliant13) 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 Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation
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:
11. The module does not output intermediate key values. HMAC algorithms specified in the Approved Algorithms table produce truncated versions of the HMAC in question. The right most bits are truncated as per the NIST SP 800-107 rev1. When the module is used within the context of Java Security Manager or the system/security property org.bouncycastle.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 a non-approved mode by default. From non-approved mode to approved mode: It is a combination of granted permission (a) and request to change mode (b): a. org.bouncycastle.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 indicating within the class (object), instantiating the key, as being created in an approved mode or non-approved mode. Any attempt by a thread within the execution of 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 see if the thread making the request is in the same mode. From approved mode to non-approved 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 “org.bouncycastle.crypto.CryptoServicesPermission unapprovedModeEnabled” granted by the Java Security Manager.
IVs for GCM can be generated randomly, or via a FipsNonceGenerator. Where an IV is not generated within the module the module supports the importing of GCM IVs. 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. 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. In approved mode, importing a GCM IV for encryption that originates from outside the module is non-conformant. 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 “org.bouncycastle.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: only in its original entirety (without revision).
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, 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:
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 14 byte password is unlikely to contain sufficient entropy for most purposes as the standard set of printable characters only allows for as much as 6 bits of entropy per byte, giving a password which for the case of 14 bytes, yields a key that has been generated using 14 * 6 bits, giving only 84 bits of security, 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
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.
The cSHAKE algorithm offers to input string for customizing the output of the cSHAKE function, 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. Below shows the parameter constraints applicable to the module’s implementation. SP800-38G Format-Preserving Encryption Constraints radix in range of 2..216 in range of 2..216 radixminlen >= 1000000 >= 1000000 minlen >= 2 octets 2 octets maxlen < 232 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.
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 SP800-133r2 and compliant with FIPS 186-4 and SP800-90Arev1 for DRBG. The seed used in asymmetric key generation is the direct output of SP800-90Arev1 DRBG.
The Certes Java Cryptographic Module is a software module, and, therefore, control of the physical ports is outside of the module’s scope. The module does provide a set of logical interfaces which are mapped to the following FIPS 140-3 defined logical interfaces: data input, data output, control input, status output, and power. 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 only in its original entirety (without revision).
is single-threaded, and in an error state, the module does not return any output data, only an error value. The module does not implement control output interface. The mapping of the FIPS 140-3 logical interfaces to the module is described in Table 7. Logical Interface Data that passes over port/interface Data Input API input parameters
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 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 being used in approved mode, classes providing implementations of algorithms which 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. Roles, with corresponding service with input and output is specified in Table 8 below: Role Service Input Output CO/User Initialize Module and Run N/A Exception in case of failure Self-Tests on Demand CO/User Show Status N/A Boolean CO/User Info Service N/A Module name and version CO/User Zeroize / Power-off N/A Shutdown indication CO/User Data Encryption Key, Plaintext Ciphertext only in its original entirety (without revision).
Role Service Input Output CO/User Data Decryption Key, Ciphertext Plaintext CO/User MAC Calculation Key, Message MAC CO/User Signature Authentication Key, Message Signature CO/User Signature Verification Key, Message, Signature Boolean CO/User DRBG (SP800-90Arev1) N/A Data Output CO/User Message Hashing Message Hash CO/User Keyed Message Hashing Key, Message Hash CO/User TLS Key Derivation TLS Parameters Data Function CO/User SP 800-108-rev1 KDF KDF Parameters Data CO/User SSH Derivation Function SSH Parameters Data CO/User X9.63 Derivation Function X9.63 Parameters Data CO/User SP 800-56C-rev2 KDM Parameters Data OneStep/TwoStep Key Derivation Function (KDM) CO/User IKEv2 Derivation Function IKEv2 Parameters Data CO/User SRTP Derivation Function SRTP Parameters Data CO/User PBKDF Password, PBKDF Data Parameters CO/User Key Agreement Schemes Key Agreement keys, Data parameters CO/User Key Wrapping Wrapping key, Key Wrapped key CO/User Key Unwrapping Unwrapping Key, Wrapped Key key CO/User Key Generation Key Generation Parameters Key Pair CO/User Key Verification Key Pair Boolean CO/User Entropy Callback N/A Random bits CO/User DRBG Health-Tests N/A N/A CO/User SSP Export Operation SSP Data CO/User Utility N/A N/A Table 8 - Roles, Service Commands, Input and Output
The module supports two distinct operator roles, User and Cryptographic Officer (CO). The cryptographic module implicitly maps the two roles to the services. A user is considered the owner of the thread that instantiates the module and, therefore, only one concurrent user is allowed. only in its original entirety (without revision).
Table 9 lists all operator roles supported by the module. The module does not support a maintenance role and/or bypass capability. The module does not support authentication. Role Authentication Method Authentication Strength CO N/A
Table 10 lists the services and a description of each service with the usage and roles. Services in the module are accessed via the public APIs of the jar file. The ability of a thread to invoke non-approved services depends on whether it has been registered with the module as approved mode only. In approved only mode no non-approved services are accessible. 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 permissions to be configured in the JVM configuration by the Cryptographic Officer or User. 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. only in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs Initialize Module The JRE will call the static N/A N/A CO/User N/A Flag and Run Self- constructor for self-tests on Tests on Demand module initialization Show Status A user can call N/A N/A CO/User N/A Flag FipsStatus.IsReady() at any time to determine if the module is ready. CryptoServicesRegistrar.IsIn ApprovedOnlyMode() can be called to determine the approved mode of operation Info Service A user can call N/A N/A CO/User N/A Flag DumpInfo.main() at any time to display the module version, checksum, and status information Zeroize / Power- SSPs can be zeroized on N/A All SSPs CO/User Z Flag off demand by invoking the destroy() method or power cycle the module. Flag is accessed by calling the method CryptoServicesRegistrar.isInApprovedOnlyMode() - this method will return true if the thread is running in approved mode, false otherwise. in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs Data Encryption Used to encrypt data AES-ECB, AES- AES Encryption Key CO/User E Flag CBC, AES-OFB, AES-CFB8, AES-CFB128, AES-CTR, AESCBC-CS, CCM, GCM, FF1 Data Decryption Used to decrypt data AES-ECB, AES- AES Decryption Key CO/User E Flag CBC, AES-OFB, AES-CFB8, AES-CFB128, AES-CTR, AESCBC-CS, CCM, GCM, FF1 MAC Calculation Used to calculate data CMAC, GMAC AES Authentication Key, HMAC CO/User E Flag integrity codes with CMAC Authentication Key, KMAC Authentication Key Signature Used to generate signatures DSA, ECDSA, DSA Signing Key, EC Signing CO/User E Flag Authentication (DSA, ECDSA, RSA) Key, RSA Signing Key RSA Signature Used to verify digital DSA, ECDSA, DSA Verification Key, EC CO/User E Flag Verification signatures RSA Verification Key, RSA Verification Key in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs DRBG (SP800- Used for random number, IV Counter DRBG, AES Encryption Key, AES CO/User G Flag 90Arev1) output and key generation Hash DRBG, Decryption Key, AES HMAC DRBG Authentication Key, 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, 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 Verification Key, RSA Key Transport Private Key, RSA Key Transport Public Key DRBG Seed, Internal State V and CO/User E C value, and DRBG Key Message Hashing Used to generate message SHS, SHA-3, N/A CO/User N/A Flag digest, SHAKE output SHAKE, SHA-3 Derived Functions (cSHAKE, TupleHash, ParallelHash) in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs Keyed Message Used to calculate data HMAC, HMAC Authentication Key, CO/User E Flag Hashing integrity codes with HMAC SHA-3 Derived KMAC Authentication Key and KMAC Functions (KMAC) TLS Key Used to calculate a value HKDF, KDF, TLS KDF Secret Value CO/User E Flag Derivation suitable to be used for a Existing Function master secret in TLS ApplicationSpecific (TLS KDF) SP 800-108-rev1 Used to calculate a value KBKDF, SP800-108-rev1 KDF Secret CO/User E Flag KDF suitable to be used for a using Value secret key Pseudorandom Functions SSH Derivation Used to calculate a value Existing SSH KDF Secret Value CO/User E Flag Function suitable to be used for a Applicationsecret key Specific (SSH KDF) X9.63 Derivation Used to calculate a value Existing DH Agreement Private Key, EC CO/User G Flag Function suitable to be used for a Application- Agreement Private Key, RSA secret key Specific (X9.63 Signing Key KDF) X9.63 KDF Secret Value CO/User E SP 800-56C-rev2 Used to calculate a value HKDF, KDF One DH Agreement Private Key, EC CO/User G Flag OneStep/TwoStep suitable to be used for a Step, KDF Two Agreement Private Key, RSA Key Derivation secret key Step. Signing Key Function (KDM) SP800-56C-rev2 KDF Secret CO/User E Value in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs IKEv2 Derivation Used to calculate a value Existing IKEv2 KDF Secret Value CO/User E Flag Function suitable to be used for a Applicationsecret key Specific (IKEv2) SRTP Derivation Used to calculate a value Existing SRTP KDF Secret Value CO/User E Flag Function suitable to be used for a Applicationsecret key Specific (SRTP) PBKDF Used to generate a key using KDF, HMAC Authentication Key, CO/User G Flag an encoding of a password Password- KMAC Authentication Key and message hash Based HMAC Authentication Key, CO/User E KMAC Authentication Key, PBDKF Secret Key Agreement Used to calculate key KAS-FFC, KAS- AES Encryption Key, AES CO/User G Flag Schemes agreement values (SP800- ECC, KAS-IFC, Decryption Key, AES 56A-rev3, Diffie-Hellman) SafePrimes Authentication Key, AES Wrapping Key, HMAC Authentication Key, KMAC Authentication Key DH Agreement Private Key, EC CO/User E Agreement Private Key, RSA Key Transport Private Key Key Wrapping Used to encrypt a key value AES KW, AES AES Wrapping Key, HMAC CO/User E Flag (RSA, AES) KWP, KTS-IFC Authentication Key, KMAC Authentication Key, RSA Key Transport Private Key in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs Key Unwrapping Used to decrypt a key value AES KW, AES AES Wrapping Key, HMAC CO/User E Flag (RSA, AES) KWP, KTS-IFC Authentication Key, KMAC Authentication Key, RSA Key Transport Public Key Key Generation Used to generate key pair RSA KeyGen, DRBG Output, DSA Signing Key, CO/User E Flag DSA KeyGen, EC Signing Key, RSA Signing ECDSA KeyGen, Key, DSA Verification Key, EC CKG Verification Key, RSA Verification Key Key Verification Used to verify key pair ECDSA KeyVer EC Signing Key, EC Verification CO/User E Flag Key Entropy Callback Gathers entropy in a passive DRBG, CKG DRBG Seed, Internal State V and CO/User G Flag manner from a user-provided C value, and DRBG Key function DRBG Health- Used to perform checks of DRBG N/A CO/User N/A Flag Tests incoming entropy against Section 4.4 of SP800-90B in its original entirety (without revision).
Approved Access rights Service Description Security Keys and/or SSPs Roles to Keys and/or Indicator14 Functions SSPs SSP Export Returns a CSP as data that N/A AES Encryption Key, AES CO/User R Flag Operation can be used for later output 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 Verification Key, RSA Key Transport Private Key, RSA Key Transport Public Key Utility Miscellaneous utility N/A N/A CO/User N/A Flag functions, does not access CSPs Table 10 - Approved Services The modes of access shown in the table above are defined as:
The Module type is software. The module has a Multi-Chip Stand Alone embodiment; the cryptographic boundary is the Java Archive (JAR) file, bc-fips-2.0.0.jar. 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 integrity is verified using HMAC-SHA2-256. 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. Flag is accessed by calling the method CryptoServicesRegistrar.isInApprovedOnlyMode() - this method will return true if the thread is running in approved mode, false otherwise. in its original entirety (without revision).
CASTs are preformed prior to the first use of services related to the test target. CASTs also run periodically on service invocation. 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 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 in Table 2. Each approved operating system manages processes and threads in a logically separated manner. The Module’s user is considered the owner of the calling application that instantiates the Module within the process space of the Java Virtual Machine. The module optionally uses the Java Security Manager and starts in approved mode by default when used with the Java Security Manager.
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 JVMs entropy source can be configured through setting the security property: securerandom.strongAlgorithms in the JVM's java.security file.
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. See Section 6.3 for further advice. 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.
In default operation the module will start with all algorithms and services enabled. If the module detects that the system property org.bouncycastle.fips.approved_only is set to true the module will start in approved mode and non-approved mode functionality will not be available. If the underlying JVM is running with a Java Security Manager installed the module will be running in approved mode with secret and private key export disabled. When the module is not used within the context of the Java Security Manager, it will start by default in the non-approved mode. Use of the module with a Java Security manager 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 in its original entirety (without revision).
module itself to examine secret and private keys. The basic permissions required for the module to operate correctly with a Java Security manager are indicated by a Y: Available Java Permissions Permission Settings Req Usage RuntimePermission “getProtectionDomain” Y Allows checksum to be carried out on jar. RuntimePermission “accessDeclaredMembers” Y Allows use of reflection API within the provider. PropertyPermission “java.runtime.name”, “read” N Only if configuration properties are used. SecurityPermission "putProviderProperty.BCFIPS" N Only if provider installed during execution. CryptoServicesPermission “unapprovedModeEnabled” N Only if non-approved mode algorithms required. CryptoServicesPermission “changeToApprovedModeEnabled” N Only if threads allowed to change modes. CryptoServicesPermission “exportSecretKey” N To allow export of secret keys only. CryptoServicesPermission “exportPrivateKey” N To allow export of private keys only. CryptoServicesPermission “exportKeys” Y Required to be applied for the module itself. Optional for any other codebase. CryptoServicesPermission “tlsNullDigestEnabled” N Only required for TLS digest calculations. CryptoServicesPermission “tlsPKCS15KeyWrapEnabled” N Only required if TLS is used with RSA encryption. CryptoServicesPermission “tlsAlgorithmsEnabled” N Enables both NullDigest and PKCS15KeyWrap. CryptoServicesPermission “defaultRandomConfig” N Allows setting of default SecureRandom. CryptoServicesPermission “threadLocalConfig” N Required to set a thread local property in the CryptoServicesRegistrar CryptoServicesPermission “globalConfig” N Required to set a global property in the CryptoServicesRegistrar. The JVM's entropy source is checked according to SP 800-90B, Section 4.4 using the suggest 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 by the Cryptographic Officer using the security property: “org.bouncycastle.entropy.factors” which takes a comma separated list of C values, one for 4.4.1 and one for 4.4.2, and a value of H. in its original entirety (without revision).
A user can instantiate the default Approved DRBG for the module explicitly by using SecureRandom.getInstance("DEFAULT", "BCFIPS"), or by using a BouncyCastleFipsProvider 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 strength 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 suggest C values for the Repetition Count Test (Section 4.4.1) and the Adaptive Proportion Test (Section 4.4.2). These values can also be configured by the user using the security property: “org.bouncycastle.entropy.factors” which takes a comma separated list of C values, one for 4.4.1 and one for 4.4.2, and a value of H. For the default the property would be set as: org.bouncycastle.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 6.1 of this Security Policy and will block, or fail, if it is unable to provide the amount of entropy requested.
This section is not applicable as the module is a software module.
This section is not applicable to this module.
All Sensitive Security Parameters (SSPs) used by the Module are described in this section in Table
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number AES 128, 192, 256 AES ECB, DRBG16 Import17, N/A N/A, the destroy() service AES Encryption bits CBC, OFB, Export18 module call or host encryption19 Key CFB8, does not platform power CFB128, CTR, provide cycle FF1, CBC- persistent CS1, CBC- storage CS2, CBCCS3, GCM, CKG A4399 AES 128, 192, 256 AES ECB, DRBG16 Import17, N/A N/A, the destroy() service AES decryption Decryption bits CBC, OFB, Export18 module call or host Key CFB8, does not platform power CFB128, CTR, provide cycle FF1, CBC- persistent CS1, CBC- storage CS2, CBCCS3, GCM, CKG A4399 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). 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. in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number AES 128, 192, 256 AES CMAC, DRBG16 Import17, N/A N/A, the destroy() service AES Authentication bits GMAC, CKG Export18 module call or host CMAC/GMAC Key A4399 does not platform power provide cycle persistent storage AES Wrapping 128, 192, 256 AES KW, DRBG16 Import17, N/A N/A, the destroy() service AES Key bits KWP, CKG Export18 module call or host (128/192/256) A4399 does not platform power key wrapping provide cycle key for KTS persistent storage DH Agreement 112, 128, 152, KAS-FFC, DRBG16 Import17, N/A N/A, the destroy() service Diffie-Hellman Private Key 176, 200 bits CKG Export18 module call or host key agreement A4399 does not platform power provide cycle persistent storage DH Agreement 112, 128, 152, KAS-FFC, DRBG16 Import17, N/A N/A, the Not zeroized, Diffie-Hellman Public Key 176, 200 bits CKG Export18 module public key value key agreement A4399 does not known outside of provide module persistent storage in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number DSA Signing 112, 128 bits DSA Signature DRBG16 Import17, N/A N/A, the destroy() service DSA signature Key Generation, Export18 module call or host generation CKG does not platform power A4399 provide cycle persistent storage DSA 80, 112, 128 DSA Signature DRBG16 Import17, N/A N/A, the Not zeroized, DSA signature Verification bits Verification, Export18 module public key value verification Key CKG does not known outside of A4399 provide module persistent storage EC Agreement 112, 128, 192, KAS-ECC, DRBG16 Import17, N/A N/A, the destroy() service EC (P-224, PPrivate Key 256 bits CKG Export18 module call or host 256, P-384, PA4399 does not platform power 521, K-233, Kprovide cycle 283, K-409, Kpersistent 571, B-233, Bstorage 283, B-409 and B-571) key agreement EC Agreement 112, 128, 192, KAS-ECC, DRBG16 Import17, N/A N/A, the Not zeroized, EC (P-224, PPublic Key 256 bits CKG Export18 module public key value 256, P-384, PA4399 does not known outside of 521, K-233, Kprovide module 283, K-409, Kpersistent 571, B-233, Bstorage 283, B-409 and B-571) key agreement in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number EC Signing 112, 128, 192, ECDSA DRBG16 Import17, N/A N/A, the destroy() service ECDSA (P-224, Key 256 bits Signature Export18 module call or host P-256, P-384, Generation, does not platform power P-521, K-233, CKG provide cycle K-283, K-409, A4399 persistent K-571, B-233, storage B-283, B-409 and B-571) signature generation. EC 80, 112, 128, ECDSA DRBG16 Import17, N/A N/A, the Not zeroized, ECDSA (P-192, Verification 192, 256 bits Signature Export18 module public key value P-224, P-256, Key Verification, does not known outside of P-384, P-521, CKG provide module K-163, K-233, A4399 persistent K-283, K-409, storage K-571, B-163, B-233, B-283, B-409 and B571) signature verification. HMAC/KMA 112-256 bits SHA-1, SHA2, DRBG16 Import17, N/A N/A, the destroy() service Keyed-Hash C SHA3, Export18 module call or host calculation Authentication KMAC, CKG does not platform power (SHA-1, SHAKey A4399 provide cycle 2, SHA-3, persistent KMAC). storage in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number RSA Signing 112, 128, 152 RSA Signature DRBG16 Import17, N/A N/A, the destroy() service RSA signature Key bits Generation, module call or host generation Export18 CKG does not platform power A4399 provide cycle persistent storage RSA 80, 112, 128, RSA Signature DRBG16 Import17, N/A N/A, the Not zeroized, RSA signature Verification 152 bits Verification, module public key value verification Export18 Key CKG does not known outside of A4399 provide module persistent storage RSA Key 112, 128, 152 KTS-IFC, DRBG16 Import17, N/A N/A, the destroy() service RSA key Transport bits CKG module call or host transport and Export18 Private Key20 A4399 does not platform power decryption provide cycle persistent storage RSA Key 112, 128, 152 KTS-IFC, DRBG16 Import17, N/A N/A, the Not zeroized, RSA key Transport bits CKG module public key value transport Export18 Public Key20 A4399 does not known outside of provide module persistent storage RSA key transport using PKCS#1 1.5 padding is deprecated through 2023 and disallowed after 2023. in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number IKEv2 KDF 112, 128, 192, KDF IKEv2 Generated N/A N/A N/A, the destroy() service Key Derivation Secret Value 256 bits A4399 as output of module call or host an IKEv2 does not platform power agreement provide cycle scheme persistent storage PBKDF Secret 112-256 bits PBKDF Generated N/A N/A N/A, the destroy() service Key Derivation Value A4399 as output of module call or host a PBE key does not platform power and a PRF provide cycle persistent storage SP 800-56C- 112, 128, 192, KDA OneStep Generated N/A N/A N/A, the destroy() service Key Derivation rev2 256 bits SP800-56Cr2 as output of module call or host OneStep/TwoS KDA TwoStep an does not platform power tep KDF SP800-56Cr2 agreement provide cycle Secret Value A4399 scheme persistent storage SP 800-108- 112, 128, 192, KDF SP800- Generated N/A N/A N/A, the destroy() service Key Derivation rev1 KDF 256 bits 108 as output of module call or host Secret Value A4399 an does not platform power agreement provide cycle scheme persistent storage SRTP KDF 128, 192, 256 KDF SRTP Generated N/A N/A N/A, the destroy() service Key Derivation Secret Value bits A4399 as output of module call or host an SRTP does not platform power agreement provide cycle scheme persistent storage in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number SSH KDF 80, 112, 128, KDF SSH Generated N/A N/A N/A, the destroy() service Key Derivation Secret Value 192, 256 bits A4399 as output of module call or host an SSH does not platform power agreement provide cycle scheme persistent storage TLS Premaster 384 bits KDF TLS Protocol Import17, N/A N/A, the destroy() service Used to derive Secret Value A4399 version (2 Export18 module call or host keys using TLS bytes) and does not platform power KDF
from a persistent DRBG16 storage TLS KDF 112, 128, 192, KDF TLS Generated N/A N/A N/A, the destroy() service Key Derivation Secret Value 256 bits A4399 as output of module call or host TLS does not platform power agreement provide cycle scheme persistent storage X9.63 KDF 112, 128, 192, KDF ANS 9.63 Generated N/A N/A N/A, the destroy() service Key Derivation Secret Value 256 bits A4399 as output of module call or host an does not platform power agreement provide cycle scheme persistent storage Entropy Input >128 bits N/A N/A Obtained N/A N/A, the destroy() service Random String from the module call or host Number entropy does not platform power Generation source provide cycle persistent storage in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number CTR DRBG 128, 192, 256 N/A N/A Obtained N/A N/A, the Immediately Internal use Seed bits from the module after use or host entropy does not platform power source provide cycle persistent storage CTR DRBG V 128 bits N/A From seed N/A N/A N/A, the reseed() service Internal use Value value module call or host does not platform power provide cycle persistent storage CTR DRBG 128, 192, 256 N/A From N/A N/A N/A, the reseed() service Internal use Key bits DRBG V module call or host value does not platform power provide cycle persistent storage Hash DRBG 112, 128, 192, N/A N/A From N/A N/A, the Immediately Internal use Seed 256 bits external module after use or host entropy does not platform power source provide cycle persistent storage Hash DRBG V 112, 128, 192, N/A From seed N/A N/A N/A, the reseed() service Internal use Value 256 bits value module call or host does not platform power provide cycle persistent storage in its original entirety (without revision).
Key/SSP Strength Security Generation Import/ Establishment Storage Zeroisation Use & related Name/Type Function and Export keys Cert. Number Hash DRBG C 112, 128, 192, N/A From N/A N/A N/A, the reseed() service Internal use Value 256 bits DRBG V module call or host value does not platform power provide cycle persistent storage HMAC DRBG 112, 128, 192, N/A N/A From N/A N/A, the Immediately Internal use Seed 256 bits external module after use or host entropy does not platform power source provide cycle persistent storage HMAC DRBG 112, 128, 192, N/A From seed N/A N/A N/A, the reseed() service Internal use V Value 256 bits value module call or host does not platform power provide cycle persistent storage HMAC DRBG 112, 128, 192, N/A From N/A N/A N/A, the reseed() service Internal use Key 256 bits DRBG V module call or host value does not platform power provide cycle persistent storage DRBG Output 128, 192, 256 N/A DRBG N/A N/A N/A, the destroy() service Used as seed bits module call or host for asymmetric does not platform power key generation provide cycle or for persistent symmetric key storage generation in its original entirety (without revision).
Table 12 - SSPs in its original entirety (without revision).
The module’s use of Non-Deterministic Random Number Generators is determined by the settings described in Section 6.1. Entropy sources Minimum number of bits of Details entropy Passive Entropy 128 As per FIPS 140-3 IG 9.3.A Section 2b, a minimum of 16 bytes is required from the source configured for seed generation for the JVM. The entropy reader will block until the seed generator has provided the minimum number of bytes. Table 13 - Non-Deterministic Random Number Generation Specification
CASTs are performed prior to the first use of services related to the test target. CASTs also run periodically on service invocation. Initial CAST self–tests are available on demand by power cycling the module and then invoking the service related to the test target.
Each time the module is powered up, it performs the pre-operational self-tests to confirm that sensitive data have not been damaged. The pre-operational tests include the Software Integrity test, which verifies the module using HMAC-SHA2-256, and the HMAC and SHS Conditional Cryptographic Algorithm Self-Tests (CAST) which 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. Below are the self-tests implemented: Conditional Cryptographic Algorithm Self-Test:
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 mentioned below: “Failed self-test on encryption: AES” The module can be recovered by power cycling the module which results in execution of preoperational self-tests and conditional cryptographic algorithm self-tests. If the tests pass, then the module will be available for use. its original entirety (without revision).
Vulnerabilities found in the module will be reported on the National Vulnerability Database, located at https://nvd.nist.gov/. Researchers and users are encouraged to report any security related concerns to feedbackcrypto@bouncycastle.org. A PGP public key can be provided if confidentiality is required around the report. Please find the procedures for secure installation, initialization, startup and operation of the module: The module exists as part of the running JVM as such:
The Module implements basic protections to mitigate against timing-based attacks against its internal implementations. There are two countermeasures used. The first 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 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 the private key calculations involved. Lenstra's CRT attack takes its original entirety (without revision).
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. its original entirety (without revision).
Appendix: References and Definitions The following standards are referred to in this Security Policy. X9.31-1998, Digital Signatures using Reversible Public Key Cryptography for the ANSI X9.31 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-3 Digital Signature Standard (DSS) FIPS 186-4 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 Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module IG Validation Program PKCS#1 v2.1 RSA Cryptography Standard PKCS#5 Password-Based Cryptography Standard Personal Information Exchange Syntax StandardRecommendation for the Triple Data PKCS#12 Encryption Algorithm (TDEA) Block Cipher Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext SP 800-38A Stealing for CBC Mode Recommendation for Block Cipher Modes of Operation: The CMAC Mode for SP 800-38B Authentication Recommendation for Block Cipher Modes of Operation: The CCM Mode for SP 800-38C Authentication and Confidentiality Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode SP 800-38D (GCM) and GMAC SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping Recommendation for Block Cipher Modes of Operation: Methods for FormatSP 800-38G Preserving Encryption Recommendation for Pair-Wise Key Establishment Schemes Using Discrete SP 800-56A-rev3 Logarithm Cryptography Recommendation for Pair-Wise Key Establishment Schemes Using Integer SP 800-56B-rev2 Factorization Cryptography SP 800-56C-rev2 Recommendation for Key Derivation through Extraction-then-Expansion SP 800-67-rev2 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher SP 800-89 Recommendation for Obtaining Assurances for Digital Signature Applications Recommendation for Random Number Generation Using Deterministic Random Bit SP 800-90A Generators SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation SP 800-108-rev1 Recommendation for Key Derivation Using Pseudorandom Functions SP 800-132 Recommendation for Password-Based Key Derivation SP 800-133-rev2 Recommendation for Cryptographic Key Generation SP 800-135-rev1 Recommendation for Existing Application
The following are acronyms used in this Security Policy: AES Advanced Encryption Standard API Application Programming Interface BC Bouncy Castle BC-FJA Bouncy Castle FIPS Java API CBC Cipher-Block Chaining CCM Counter with CBC-MAC CDH Computational Diffie-Hellman CFB Cipher Feedback Mode CMAC Cipher-based Message Authentication Code CMVP Crypto 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 Authority DSTU4145 Ukrainian DSTU-4145-2002 Elliptic Curve Scheme EC Elliptic Curve ECB Electronic Code Book ECC Elliptic Curve Cryptography ECDSA Elliptic Curve Digital Signature Authority EdDSA Edwards Curve DSA using Ed25519, Ed448 EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standards 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 key-Hashed Message Authentication Code IG See References JAR Java ARchive JCA Java Cryptography Architecture JCE Java Cryptography Extension its original entirety (without revision).
JDK Java Development Kit JRE Java Runtime Environment JVM Java Virtual Machine IV Initialization Vector 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 Non 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 TCBC TDEA Cipher-Block Chaining TCFB TDEA Cipher Feedback Mode TDEA Triple Data Encryption Algorithm TDES Triple Data Encryption Standard TECB TDEA Electronic Codebook TOFB TDEA Output Feedback TLS Transport Layer Security USB Universal Serial Bus XDH Edwards Curve Diffie-Hellman using X25519, X448 XOF Extendable-Output Function its original entirety (without revision).