Random Number Generation

ANKASecure's platform generator, CryptoRandomProvider, runs a DRBG (Deterministic Random Bit Generator) of NIST SP 800-90A Rev. 1 at 256-bit security strength with prediction resistance. One instance per service process serves key generation, IVs and nonces, content-encryption keys, PQC session keys and the secrets and tokens the platform generates. The operator's HSM or cloud KMS generates and holds the key-encryption key, and on Entrust nShield and AWS CloudHSM it also generates the IV of each key wrap under the IV mode their vendor profiles derive.

1. Posture at a glance

2. Standards alignment

• NIST SP 800-90A Rev. 1 — Hash_DRBG with SHA-256 is an approved DRBG mechanism (§10.1.1). The platform requests 256 bits, the highest strength the mechanism supports with SHA-256 (§8.4), and prediction resistance on every request (§8.8).
• NIST SP 800-133 Rev. 2 — keys are generated from the DRBG's output with its methods: key pairs by the algorithm's own generation procedure with the DRBG passed to the generator (§5), symmetric keys and data-encryption keys from DRBG output, directly or through a key generator fed by the DRBG (§6.1). The DRBG runs in the JDK SUN provider, not in a FIPS 140-3 validated module; see the FIPS 140-3 Cryptographic Boundary Statement.
• RFC 5869 — HKDF-SHA256 derives each streaming chunk IV from a DRBG master IV.
• FIPS 140-3 — the key-encryption key is generated and used inside the operator's FIPS 140-3 module (§3.2).

3. Where each value comes from

3.1 The platform DRBG

• Initialization: SecureRandom.getInstance("DRBG", DrbgParameters.instantiation(256, PR_AND_RESEED, null)) in DrbgRandomNumberGenerator.
• Start-up checks: before first use the instance must produce non-zero output and two distinct consecutive outputs; a failure stops the service.
• Reseeding: requested on every generate call by the PR_AND_RESEED capability; the JDK provider reseeds from the operating-system kernel's random source, which suits containers, VMs and bare metal.

3.2 The operator's HSM or cloud KMS

The module the operator binds as the key-protection backend performs these operations inside its own boundary:

• KEK generation: PKCS#11 C_GenerateKey with CKM_AES_KEY_GEN (AES-256) on Thales Luna, AWS CloudHSM and Entrust nShield; AWS KMS CreateKey; Google Cloud KMS createCryptoKey at the configured protection level; an OCT-HSM key on an Azure Key Vault Managed HSM.
• KEK custody: the KEK stays in the module.
• Wrap and unwrap: every data-encryption key is wrapped and unwrapped inside the module.
• Wrap IV: on Entrust nShield and AWS CloudHSM the module generates the GCM IV of each wrap — the CloudHSM profile derives the HSM-generated IV mode, as AWS requires, and the nShield profile derives the module-generated IV prepended to the ciphertext, as Entrust documents for C_Encrypt with CKM_AES_GCM. On a Thales Luna FIPS partition the operator selects an HSM IV mode (PKCS11_IV_MODE=hsm-appended) and the module generates it. Under the caller-provided IV mode (SoftHSM, a Luna partition configured for it) the IV is drawn from the platform DRBG.

4. Consumers of the platform DRBG

TLS handshakes draw their randomness from the JSSE provider's default SecureRandom, except core-api's client to the license server, whose TLS context is handed the platform DRBG (LicenseClientConfig).

5. Operational guidance

6. Verification

Each service logs what its running generator reports when it initializes it. The boot banner states the JCA provider, the mechanism and the security strength:

║  JCA Provider:  SUN
║  Mechanism:     Hash_DRBG,SHA-256,256,pr_and_reseed
║  Strength:      256-bit

The Mechanism: line is the instance's own report. For the SUN DRBG it has the form <mechanism>,<digest>,<strength>,<capability>; a DRBG from another provider is stated as <JCA algorithm>,<strength>,<capability> (for example DRBG,256,pr_and_reseed).

The FIPS 140-3 and algorithm view of the same facts is on FIPS 140-3, Random Bit Generation and Approved Algorithms.