Skip to content

Random Number Generation

ANKASecure sources cryptographic randomness from a single platform-wide DRBG (Deterministic Random Bit Generator) implementation grounded in NIST SP 800-90A Rev. 1.

This page describes the entropy posture that applies to every microservice in the platform and to every consumer of cryptographic randomness inside those services (key generation, IVs, nonces, session identifiers, refresh tokens, JTIs, MFA seeds, streaming master IVs, and HSM key-wrap material).

1. Posture at a glance

Property Value
Mechanism NIST SP 800-90A Rev. 1 Hash-DRBG
Hash function SHA-256
Security strength 256 bits
Capability PR_AND_RESEED (prediction resistance + automatic reseed)
Provider JCA SUN provider, Java 25
Entropy source OS kernel CSPRNG (/dev/urandom on Linux, non-blocking)
Singleton One DRBG-backed SecureRandom instance per JVM, shared across all consumers
Defense-in-depth Every container's JVM sets -Djava.security.drbg.config=Hash_DRBG,SHA-256,256,pr_and_reseed so that any third-party JCA caller in the JVM inherits the same strength

2. Standards alignment

  • NIST SP 800-90A Rev. 1 — Hash-DRBG with SHA-256 is an approved DRBG mechanism. ANKASecure requests the maximum permitted strength (256 bits) for this mechanism.
  • NSA CNSA 2.0 — Hash-DRBG with SHA-256 is an approved RNG mechanism.
  • RFC 5869 — HKDF-SHA256 is used for streaming chunk-IV derivation above the DRBG layer.

3. Entropy paths by deployment

3.1 Standard deployment (container with OS kernel entropy)

The DRBG path is the entropy source for all cryptographic randomness:

  • Initialization: SecureRandom.getInstance("DRBG", DrbgParameters.instantiation(256, PR_AND_RESEED, null))
  • Reseed source: OS kernel entropy pool (/dev/urandom on Linux, non-blocking — suitable for containers, VMs, and bare metal)
  • Reseed event: triggered automatically by the JCA provider; prediction resistance ensures each nextBytes call following a reseed is independent of prior outputs even if the prior internal state was observed

3.2 Deployment with a FIPS-validated HSM

For deployments with physical FIPS-validated HSMs (Thales Luna, AWS CloudHSM, Entrust nShield, YubiHSM and other PKCS#11-compliant devices):

  • Key generation and key-wrap operations source entropy directly from the HSM TRNG (True Random Number Generator) via PKCS#11 C_GenerateRandom.
  • The HSM TRNG is part of the FIPS-validated boundary of the HSM module (Luna and CloudHSM: FIPS 140-2 Level 3; nShield: FIPS 140-2 Level 3).
  • Auto-detection of HSM type at startup determines whether to use the HSM TRNG path or the DRBG fallback path. SoftHSM and unrecognized libraries use the DRBG path conservatively.

For non-key entropy (refresh tokens, JTIs, session IDs, IVs, nonces), the DRBG path remains the source — these bytes do not transit the HSM.

4. Consumer inventory

The shared DRBG handle is consumed by:

Consumer Purpose
JWT key rotation RSA-3072 signing-key generation
Refresh token issuance 16-byte Base64URL token bytes
Refresh token rotation New-token bytes (atomic Lua-bracketed swap)
Account token (JWT JTI) 16-byte Base64URL JTI
PQC session establishment 16-byte session identifier
PQC session encryption AES-GCM IV (12 bytes)
Actor credentials 32-byte client secret
Application client secret 32-byte client secret
MFA enrollment RFC 6238 TOTP HMAC seed (20 bytes)
Streaming master IV AES-GCM master IV per file
HSM key protection Per-wrap IV and DEK bytes (DRBG path on SoftHSM, HSM TRNG on physical HSM)

5. Operational guidance

Environment Notes
Linux production (containers, VMs, bare metal) /dev/urandom is the kernel CSPRNG and is suitable for all DRBG reseeding. No additional configuration required.
Air-gapped / extreme-isolation deployments Deploy with a FIPS-validated HSM. Key-wrap and keygen entropy will source from the HSM TRNG; non-key entropy uses the DRBG path with kernel-pool reseeding.
Custom JVM deployments Operators must not override -Djava.security.drbg.config to a weaker value. The platform refuses to weaken the explicit DrbgParameters.instantiation(256, PR_AND_RESEED, null) call regardless of system-property setting.

6. Verification

The DRBG state is observable at runtime:

GET /actuator/rng-info

Returns the runtime DRBG metadata, including algorithm, provider, security strength (256), and capability (PR_AND_RESEED). Compliance attestations sourced from this endpoint are internally consistent with the runtime DRBG instantiation.

For workspace-wide entropy auditing, see the internal RNG implementation reference for the full consumer call-site inventory and forensic logging schema.