FIPS 140-3, Random Bit Generation and Approved Algorithms
This page describes how the platform relates to the NIST standards for cryptographic modules, random bit generation and approved algorithms: which mechanisms the platform implements itself, and which operations run inside the operator's FIPS 140-3 hardware.
Summary
The platform implements NIST-approved algorithms (FIPS 203, 204, 205, 186-5) and the SP 800-90A Hash_DRBG, and FIPS 140-3 validated operation for key protection is provided by the operator's FIPS 140-3 HSM or cloud KMS.
- Random bit generation: one SP 800-90A Rev. 1 DRBG per service process, instantiated at 256-bit security strength with prediction resistance, serves the platform's key generation, IVs, nonces, session keys and generated secrets (§2). Keys are generated from its output with the methods of SP 800-133 Rev. 2 (boundary statement, §4).
- Key protection: the key-encryption key (KEK) is generated, held and used inside the HSM or cloud KMS the operator binds; every data-encryption key is wrapped and unwrapped there (§3).
- Algorithms: the catalogue offers the FIPS 203, 204 and 205 post-quantum algorithms, the FIPS 186-5 and SP 800-186 signature algorithms and curves, the SP 800-208 stateful hash-based signatures, and the CNSA 2.0 algorithms (§4).
- Governance: algorithm availability is set per tenant by policy, so a deployment can restrict itself to the approved subset it needs.
Documents and versions
| Document | Version used | Primary source (checked 2026-10-04) |
|---|---|---|
| FIPS 140-3, Security Requirements for Cryptographic Modules | Final, March 22, 2019 | NIST CSRC |
| SP 800-90A Rev. 1, Random Number Generation Using Deterministic Random Bit Generators | June 2015, the current final; Rev. 2 is at the pre-draft call-for-comments stage (September 2025) with no draft text | NIST CSRC, Rev. 2 call |
| SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation | January 2018 | NIST CSRC |
| SP 800-90C, Recommendation for Random Bit Generator (RBG) Constructions | Final, September 2025 | NIST CSRC |
| FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) | Final, August 13, 2024 | NIST CSRC |
| FIPS 186-5, Digital Signature Standard | Final, February 3, 2023 | NIST CSRC |
| SP 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters | Final, February 2023 | NIST CSRC |
| SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes | Final, October 2020 | NIST CSRC |
| SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation | June 2020 | NIST CSRC |
1. FIPS 140-3 and the platform
FIPS 140-3 specifies the security requirements for a cryptographic module; its §6 aligns the requirements with ISO/IEC 19790:2012(E), tested under ISO/IEC 24759:2017(E) as modified by the SP 800-140 series.
The platform's own role is the cryptographic service around the module: algorithm selection and policy, key lifecycle, envelope encryption, JOSE serialization and audit. The FIPS 140-3 module of a deployment is the HSM or cloud KMS the operator binds as the key-protection backend, and it performs the operations listed in §3. For a deployment that requires FIPS 140-3 operation, the operator binds a module that holds a current FIPS 140-3 certificate from the NIST Cryptographic Module Validation Program, and on Google Cloud KMS and Azure selects the HSM protection level and the Managed HSM tier respectively.
2. Random bit generation
2.1 Mechanism and parameters
DrbgRandomNumberGenerator (ankasecure-common-infrastructure) obtains a JCA DRBG instance with DrbgParameters.instantiation(256, PR_AND_RESEED, null). On the Java 25 runtime of the service images the JDK's SUN provider runs it as Hash_DRBG with SHA-256, and the instance reports itself as Hash_DRBG,SHA-256,256,pr_and_reseed.
| Parameter | Value | SP 800-90A Rev. 1 |
|---|---|---|
| Mechanism | Hash_DRBG | §10.1.1 |
| Hash function | SHA-256 | §10.1, Table 2 |
| Security strength | 256 bits, the highest Hash_DRBG with SHA-256 supports | §8.4, Table 2 |
| Prediction resistance | Requested on every generate call (PR_AND_RESEED) | §8.8 |
| Start-up checks | Before first use the instance must produce non-zero output and two distinct consecutive outputs; a failure stops the service (DrbgRandomNumberGenerator.validate) | — |
2.2 The consumers the shared DRBG serves
Each service process holds one shared instance, reached through CryptoRandomProvider. Its consumers, by class, on the platform's main sources:
| Purpose | Consumers |
|---|---|
| Asymmetric and symmetric key generation | KeyGenerationService, AsymmetricAlgorithmSupport (core-api); DeploymentSecretCustodyService (admin-api, including the RSA-3072 token signing keys); SigningAlgorithm (ankasecure-common-security, handed the DRBG by admin-api: the Ed25519 projection signing keys) |
| IVs, nonces and content-encryption keys on the encryption paths | CipherInitializer, CompositeJweCoreEncryptor, KeyWrapJweEncrypter, EcdhDirectEncrypter, EcdhEsKeyWrapper, HybridEncryptionUtil, ChunkIvDerivation, Pkcs7RandomFill, CryptoUtils (core-api) |
| Data-encryption keys and the IVs of local AEAD steps in the key-protection backends | Pkcs11KeyProtector, AwsKmsKeyProtector, GcpKmsKeyProtector, AzureKvKeyProtector and their local AEAD helpers (ankasecure-common-keyprotection) |
| PQC session keys | PqcTransportCipher (auth-api, admin-api); AsymmetricCryptoService, SymmetricCryptoService (pqc-handshake-api) |
| GCM nonces of values sealed at rest | PqcSessionKeyWrapper (ankasecure-common-infrastructure), which wraps PQC session keys before they are stored in Valkey; NotificationOutboxSealer (admin-api), which seals account-recovery notifications at rest |
| Generated secrets and tokens | ClientSecretGenerator, ActorCredentialService, MfaService, AccountTokenProvider, HumanUserServiceImpl, TenantProvisionServiceImpl (admin-api); refresh tokens through auth-api's CryptoRandomConfig bean; SecureUuidGenerator, PasswordGenerator (ankasecure-common-infrastructure) |
The keys PqcSessionKeyWrapper and NotificationOutboxSealer use are not generated there: the session key comes from the key exchange, and both wrapping keys are Docker Swarm secrets.
2.3 Streaming IVs
For streamed AES-GCM, ChunkIvDerivation draws one master IV per stream from the DRBG and derives each chunk's IV from it with HKDF-SHA256 (RFC 5869), so no IV repeats within a stream.
3. Operations inside the operator's FIPS 140-3 module
| Operation | Where it runs | Evidence |
|---|---|---|
| KEK generation | Inside the module: PKCS#11 C_GenerateKey with CKM_AES_KEY_GEN (AES-256) on Thales Luna, AWS CloudHSM and Entrust nShield; AWS KMS CreateKey (SYMMETRIC_DEFAULT); Google Cloud KMS createCryptoKey at the configured protection level; an OCT-HSM key on an Azure Key Vault Managed HSM | Pkcs11NativeWrapperFFM (CKM_AES_KEY_GEN), AwsKmsKeyProtector, GcpKmsKeyProtector, AzureKvConfig.Tier.MANAGED_HSM |
| KEK custody | Inside the module; the KEK is never exported | same |
| DEK wrap and unwrap | Inside the module: PKCS#11 AES-GCM, KMS Encrypt and Decrypt, Azure wrapKey and unwrapKey | Pkcs11KeyProtector and the cloud adapters |
| Wrap IV on AWS CloudHSM | Generated by the module: the profile derives the HSM-generated IV mode (hsm-generated) and refuses a caller-supplied IV, as AWS requires | The vendor profile of the cloudhsm PKCS#11 driver (ankasecure-common-keyprotection) |
| Wrap IV on Entrust nShield | Generated by the module: the profile derives the module-generated IV prepended to the ciphertext (hsm-prepended), as Entrust documents for C_Encrypt with CKM_AES_GCM | The vendor profile of the nshield PKCS#11 driver (ankasecure-common-keyprotection) |
| Wrap IV on Thales Luna | Generated by the module when the operator selects an HSM IV mode (PKCS11_IV_MODE=hsm-appended), as a Luna FIPS partition requires; drawn from the DRBG under the caller-provided mode | The vendor profile of the luna PKCS#11 driver |
PKCS#11 vendor profiles: Thales Luna, AWS CloudHSM, Entrust nShield, and SoftHSM for development and test. Cloud KMS backends: AWS KMS, Google Cloud KMS and Azure Key Vault.
4. Algorithm catalogue
The catalogue holds 89 single-algorithm profiles and 41 composite (hybrid) pairings (AlgorithmCatalogue, CompositeAlgorithmCatalogue, ankasecure-common-algorithms). 76 profiles are RECOMMENDED and 13 EXPERIMENTAL.
| Group | Count | Members |
|---|---|---|
| Post-quantum KEM | 23 | ML-KEM ×3, HQC ×3, FrodoKEM ×2, Classic McEliece ×2, BIKE ×3, SABER ×3, NTRU ×2, NTRU Prime ×2, SMAUG-T ×3 |
| Post-quantum signature | 16 | ML-DSA ×3, SLH-DSA ×6, Falcon ×2, XMSS and XMSS^MT, LMS ×2 and HSS |
| Classical asymmetric | 17 | P-256, P-384, P-521, brainpoolP256r1/P384r1/P512r1, RSA-2048 to RSA-8192 (×5), X25519, X448, Ed25519, Ed448, SM2, GOST R 34.10-2012 |
| Symmetric AEAD | 19 | AES-GCM ×3, AES-CCM ×3, ChaCha20-Poly1305, Camellia-GCM ×3, SEED-GCM, SM4-GCM, SM4-CCM, ARIA-GCM ×3, ARIA-CCM ×3 |
| MAC | 14 | CMAC-AES ×3, HMAC-SHA-256/384/512, HMAC-SHA3 ×3, KMAC128, KMAC256, HMAC-SM3, HMAC-Streebog ×2 |
The per-algorithm detail is on the Algorithm Catalog and the Composite Algorithms Catalog.
4.1 NIST-approved algorithms offered
| Standard | Section | Offered |
|---|---|---|
| FIPS 203 | §8 Parameter Sets | ML-KEM-512, ML-KEM-768, ML-KEM-1024 |
| FIPS 204 | §4 Parameter Sets | ML-DSA-44, ML-DSA-65, ML-DSA-87 |
| FIPS 205 | §11 Parameter Sets | SLH-DSA-SHA2-128s/f, -192s/f, -256s/f |
| SP 800-208 | §4 LMS, §5 XMSS | LMS (including HSS), XMSS (including XMSS^MT) |
| FIPS 186-5 | §5 RSA, §6 ECDSA, §7 EdDSA | RSA-2048 to RSA-8192, ECDSA on P-256/P-384/P-521, Ed25519, Ed448 |
| SP 800-186 | §3.2.1 Weierstrass Curves | P-256, P-384, P-521 |
| FIPS 197 with SP 800-38D and SP 800-38C | — | AES-128/192/256 in GCM and CCM |
| FIPS 198-1, SP 800-38B, SP 800-185 | — | HMAC with SHA-2 and SHA-3, CMAC-AES, KMAC |
4.2 CNSA 2.0 algorithms offered
ML-KEM-1024 (FIPS 203), ML-DSA-87 (FIPS 204), AES-256 (AES-GCM-256, AES-CCM-256), SHA-384 and SHA-512, and, for software and firmware signing, the single-tree LMS and XMSS profiles of SP 800-208. The platform's NSA CNSA 2.0 compliance pack states the full CNSA 2.0 definition with its sources and calendar.
5. JOSE
- JWS (RFC 7515):
JwsBuilder,CustomJwsSignerandCustomJwsVerifier(classical and post-quantum),GenericMacJwsSigner(HMAC, CMAC, KMAC). - JWE (RFC 7516):
JweBuilder,JweCoreEncryptor,JweDecryptor,KeyWrapJweEncrypter. - Algorithm identifiers: the RFC 7518 identifiers for classical algorithms, and platform-defined identifiers for post-quantum and regional algorithms.
- JWT (RFC 7519):
iss,aud,exp,nbf,iatandjti, plus the platform's tenant claim. Every token the platform accepts must carryexp.
6. Cryptographic providers
Bouncy Castle bcprov-jdk18on 1.86 (with bcpkix-jdk18on), registered at start-up as the providers BC and BCPQC (SecureApiApplication), generates every tenant key and performs the operations on it, classical and post-quantum alike; the JDK's SUN provider supplies the DRBG. This is the general-purpose Bouncy Castle distribution, not the Bouncy Castle FIPS distribution, and neither it nor the JDK providers run as a FIPS 140-3 validated module. Which operations run inside the operator's validated module and which run in software is stated in the FIPS 140-3 Cryptographic Boundary Statement.
7. What an auditor can check
- DRBG: each service's boot banner states the JCA provider, the mechanism the running instance reports (
Hash_DRBG,SHA-256,256,pr_and_reseed) and its strength (256-bit). See Random Number Generation. - Algorithm counts: the algorithm catalogue endpoints list every profile.
- KEK residency: the key-protection backend's own audit log (HSM audit, AWS CloudTrail, Google Cloud Audit Logs, Azure Monitor) records the key creation and the wrap and unwrap operations.