FIPS 140-3 Cryptographic Boundary Statement

This page states which cryptographic operations of the platform run inside a FIPS 140-3 validated module and which run in software outside one. It is the boundary an assessor needs to scope a FIPS 140-3, NIST SP 800-53 SC-13 or PCI DSS 3.6 review of a deployment.

ANKASecure is not itself a FIPS 140-3 validated cryptographic module, and no part of the platform holds a certificate from the NIST Cryptographic Module Validation Program (CMVP). FIPS 140-3 validated operation is provided by the HSM or cloud KMS the operator binds as the key-protection backend, and only for the operations listed in §1.

Summary

1. Operations inside the key-protection backend

The key-protection backend holds every KEK as a non-exportable key and performs the KEK operations inside its own boundary.

The KEK type and its assurance depend on the backend, and the operator chooses it. The KEK is held in hardware on a PKCS#11 HSM, on AWS KMS, on Google Cloud KMS at the HSM protection level and on an Azure Managed HSM. On Google Cloud KMS at the SOFTWARE protection level and on an Azure standard vault, it is a software key of the provider, outside any validated hardware module. On an Azure standard vault the KEK is RSA-3072, whose security strength is 128 bits (NIST SP 800-57 Part 1 Rev. 5, Table 2), below the 256 bits of the AES-256 DEK it wraps. A deployment that requires FIPS 140-3 validated key protection binds a module that holds a current CMVP certificate, and on Google Cloud KMS and Azure selects the HSM protection level and the Managed HSM tier respectively. A tenant that binds its own key (BYOK) makes the same choice for its own keys. The protection the platform reports for a tenant's own key is read from the key itself, at bind and then on a schedule: the key's origin on AWS KMS, its primary version's protection level on Google Cloud KMS, and its key type or Managed HSM on Azure. The key is reported as hardware-protected only while the last reading says so and is recent; a software key, a key held in an external key store and an unread key are reported as software.

Wrap IV. On Entrust nShield and AWS CloudHSM the module generates the GCM IV of each wrap. On a Thales Luna partition the operator selects the HSM-generated IV mode (PKCS11_IV_MODE=hsm-appended); under the caller-provided IV mode the IV is drawn from the platform DRBG. See Random Number Generation.

2. Operations in software

These run inside the platform's Java services, in process memory, under the JCA providers named below. None of these providers is a FIPS 140-3 validated module in the platform's configuration.

• Bouncy Castle: the general-purpose distribution bcprov-jdk18on 1.86 (with bcpkix-jdk18on and bcutil-jdk18on in the services that need them), registered as the providers BC and BCPQC. The platform does not use the Bouncy Castle FIPS distribution (bc-fips). The general-purpose distribution is not a CMVP-validated module, and this applies equally to its implementations of ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS and the other post-quantum algorithms: they implement the FIPS 203, 204 and 205 and SP 800-208 algorithms, and they are not validated implementations of them.
• JDK providers (Java 25): the SUN provider's DRBG, and the default providers that serve a request naming no provider. They run in their default configuration, not as a validated module.

Consequence for an assessment. Every tenant key exists in plaintext only in the memory of a platform service, while it is generated or used, and is zeroized after use. Its confidentiality at rest rests on the two-layer envelope: the outer layer (the private key under the DEK) is computed in software, and the inner layer (the DEK under the KEK) is computed inside the backend. The FIPS 140-3 assurance of a deployment therefore covers the KEK and the DEK wrap, not the generation or use of tenant keys.

3. GCM as the key-wrapping mode

On the PKCS#11 backends the DEK is wrapped with AES-256-GCM (CKM_AES_GCM), not with the AES Key Wrap modes KW or KWP. NIST SP 800-38F §3.1 states that previously approved authenticated-encryption modes are approved for the protection of cryptographic keys, in addition to the KW, KWP and TKW modes it specifies; GCM is approved by SP 800-38D. AES Key Wrap (A256KW, the KW mode of SP 800-38F) is used on the Azure Key Vault Managed HSM tier, and the AWS and Google Cloud KMS backends wrap with their service's own symmetric encryption.

The DEK wrap carries no additional authenticated data and no KMS encryption context. The binding of a wrapped key to its tenant, key identifier, algorithm, key operations, creation time and material version is made by the outer layer: the AES-256-GCM encryption of the private key authenticates that canonical record, the record is rebuilt from the database row and the caller's tenant at every unwrap, and a wrapped key moved to another key or another tenant fails its authentication tag.

Each component of a composite key is wrapped on its own, under a record of its own: the tenant, the parent key identifier joined to the component's role, the component's algorithm, the parent's creation time, the composite key's permitted operations, the parent material identifier and the lineage version of the KEK that wraps the component, which the component row records. A component is therefore bound to one material version and to the KEK version it is wrapped under. A component wrapped under the original record (form 1), with the fixed version 1 and the operation list ["component"], keeps it until its next re-wrap; every new wrap binds the full record.

4. Key generation and NIST SP 800-133

Key generation follows the methods of NIST SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, with the platform DRBG as the random bit generator:

SP 800-133 requires the random bit generator to be an approved RBG. Hash_DRBG with SHA-256 is an approved mechanism, but it runs in the JDK SUN provider, outside a validated module. The platform therefore follows the SP 800-133 methods without the assurance of FIPS 140-3 validated key generation. The KEK is the exception: it is generated inside the key-protection backend by the backend's own generator.

5. What an auditor can check

• Providers: the poms of the services declare bcprov-jdk18on, with bcpkix-jdk18on and bcutil-jdk18on where a service needs them, and no bc-fips artifact; the services register BouncyCastleProvider and BouncyCastlePQCProvider at start-up.
• DRBG: each service's boot banner states the mechanism the running instance reports (Hash_DRBG,SHA-256,256,pr_and_reseed). See Random Number Generation.
• KEK residency: the backend's own audit log (HSM audit, AWS CloudTrail, Google Cloud Audit Logs, Azure Monitor) records the KEK creation and every wrap and unwrap.
• Backend certificate: the CMVP certificate of the bound module and the protection level the operator selected.

Documents and versions

Related pages

• FIPS 140-3, Random Bit Generation and Approved Algorithms
• Random Number Generation
• Envelope Encryption Pattern