AI Encryption Standards: NIST FIPS 140-3, AES-256-GCM, TLS 1.3, HSM Key Management, and Post-Quantum Readiness for Enterprise AI
Encryption Standards Reference
NIST FIPS 140-3: The Federal Standard for Cryptographic Modules
NIST FIPS 140-3 (Federal Information Processing Standard 140-3), published March 2019 and based on ISO/IEC 19790:2012, is the current US federal standard for cryptographic modules. Organizations deploying AI systems for US federal agencies or regulated industries (banking, healthcare) must use FIPS 140-3 validated cryptographic modules — non-validated implementations, even if they use the same algorithms, do not satisfy FIPS requirements.
FIPS 140-3 defines four security levels: Level 1 (software-only, basic requirements), Level 2 (tamper evidence, role-based authentication), Level 3 (tamper resistance, identity-based authentication, physical or logical separation of interfaces), and Level 4 (complete tamper protection, environmental failure protection). For AI systems handling sensitive federal or regulated data, FIPS 140-3 Level 2 is the minimum acceptable; Level 3 is required for systems handling the most sensitive data.
Key FIPS 140-3 validated components in enterprise AI infrastructure: AWS KMS uses FIPS 140-3 Level 3 validated HSMs (in us-east-1, us-west-2, and GovCloud regions); Azure Key Vault Premium uses FIPS 140-3 Level 3 validated Marvell LiquidSecurity HSMs; Google Cloud KMS FIPS 140-3 Level 1 validated for software keys, Level 3 for Cloud HSM keys. Organizations requiring FIPS 140-3 Level 3 should use dedicated HSM options (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM).
AES-256-GCM (Authenticated Encryption)
AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode) is the standard for AI data-at-rest encryption. GCM mode provides both encryption and authentication (AEAD), preventing tampering. Key length: 256 bits. Block size: 128 bits. NIST SP 800-38D approved.
TLS 1.3 (Transport Security)
TLS 1.3 (RFC 8446, 2018) eliminates the weak cipher suites of TLS 1.2, requires Perfect Forward Secrecy (PFS), and reduces handshake latency (1-RTT vs 2-RTT for TLS 1.2). All AI system communications must use TLS 1.3; TLS 1.2 is acceptable only where 1.3 is not supported, with cipher suite restrictions.
KMIP (Key Management)
OASIS Key Management Interoperability Protocol (KMIP) is the standard for enterprise key management. KMIP-compliant KMS solutions (Thales CipherTrust, HashiCorp Vault, AWS KMS KMIP endpoint) enable centralized key management across AI infrastructure components.
Key Management Architecture for Multi-Tenant AI Systems
Encryption key management is the critical control for multi-tenant AI systems. If all tenants' data is encrypted with the same key, a key compromise exposes all tenants' data. If each tenant's data is encrypted with a unique, tenant-specific key, a key compromise exposes only one tenant's data. Per-tenant key isolation is the architectural pattern required for enterprise SaaS AI systems.
Key hierarchy for multi-tenant AI: The recommended key hierarchy has three levels: (1) Customer Master Key (CMK) — unique per tenant, stored in HSM, used to derive or wrap data encryption keys; (2) Data Encryption Keys (DEKs) — unique per data category (conversation history, RAG documents, audit logs), wrapped by the CMK, used for actual data encryption; (3) Key Encryption Keys (KEKs) — for envelope encryption, where DEKs are encrypted with KEKs before storage. AWS KMS, Azure Key Vault, and Google Cloud KMS all support this hierarchy.
Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK): Enterprise customers with the highest compliance requirements may require BYOK — using their own CMK managed in their own HSM rather than the AI vendor's KMS. BYOK allows the customer to rotate, revoke, or destroy their CMK, which effectively destroys access to all their data in the AI system (crypto shredding for GDPR right to erasure). HYOK goes further: the key never leaves the customer's HSM, requiring the AI vendor to request key material for each encryption/decryption operation. HYOK provides the strongest control but adds latency (50-100ms per operation) and complexity.
Post-Quantum Cryptography: Planning for AI Systems
Quantum computers running Shor's algorithm can theoretically break RSA, ECDSA, and ECDH — the public-key algorithms currently used for TLS key exchange and digital signatures. While quantum computers capable of breaking current cryptography don't yet exist, "harvest now, decrypt later" attacks are a present concern: adversaries are recording encrypted traffic today with the intent to decrypt it once quantum computing matures. AI systems that handle long-term sensitive data (patient records, financial data, legal communications) should prioritize PQC migration.
The NIST PQC standards finalized in August 2024: FIPS 203 (ML-KEM) based on CRYSTALS-Kyber for key encapsulation (replacing RSA/ECDH in TLS); FIPS 204 (ML-DSA) based on CRYSTALS-Dilithium for digital signatures (replacing RSA/ECDSA); FIPS 205 (SLH-DSA) based on SPHINCS+ as an alternative signature scheme. NSA published the "Commercial National Security Algorithm Suite 2.0" (CNSA 2.0) in 2022, requiring migration to PQC algorithms by 2030 for systems protecting national security information.
For enterprise AI systems, PQC readiness planning means: inventorying all cryptographic dependencies (TLS configurations, signing certificates, key exchange protocols); identifying which AI data has long-term sensitivity requiring PQC protection first; selecting cloud providers with PQC migration roadmaps (AWS has announced PQC support for AWS KMS and CloudFront); and planning for hybrid classical/PQC deployments that run both algorithm types simultaneously during the migration period.
AI Encryption Implementation Checklist
- AES-256-GCM at restImplement AES-256-GCM encryption for all AI data at rest: conversation history, RAG documents, vector embeddings, audit logs, model weights
- TLS 1.3 in transitEnforce TLS 1.3 for all AI system communications; disable TLS 1.2 and earlier; disable weak cipher suites; implement certificate pinning for critical connections
- FIPS 140-3 validated modulesUse FIPS 140-3 validated cryptographic modules for regulated workloads; verify cloud KMS FIPS validation level (AWS KMS Level 3, Azure Key Vault Premium Level 3)
- Per-tenant key isolationImplement unique encryption keys per tenant (CMK per customer); verify key isolation prevents cross-tenant data exposure in multi-tenant AI deployments
- HSM-based key managementStore master encryption keys in FIPS 140-3 Level 3 validated HSMs; implement key access logging; configure HSM for high availability
- Key rotation policyDefine and implement key rotation schedule: CMKs rotated annually, DEKs rotated quarterly; automate rotation; test decryption with new keys before retiring old keys
- BYOK option for enterpriseOffer Bring Your Own Key capability for enterprise customers with highest compliance requirements; implement crypto shredding for GDPR right to erasure
- Encryption audit loggingLog all key access events: encryption/decryption operations, key rotation, key deletion; forward to SIEM; alert on anomalous key access patterns
- Post-quantum inventoryInventory all cryptographic dependencies in AI system; identify long-term sensitive data requiring PQC priority migration; track cloud provider PQC roadmaps
- Encryption documentationDocument encryption architecture in security policy; include in SOC 2 Type II and ISO 27001 ISMS scope; test encryption controls in annual pen test
Frequently Asked Questions
What is the minimum encryption standard for enterprise AI systems?
The minimum acceptable encryption standard for enterprise AI systems is: AES-256-GCM for data at rest, TLS 1.3 for data in transit, and FIPS 140-3 Level 2 validated cryptographic modules for regulated workloads. For healthcare (HIPAA), FIPS 140-3 validation is explicitly required by HHS guidance. For financial services (PCI DSS 4.0), TLS 1.3 is required for data transmission, and AES-256 is required for stored cardholder data. ISO 27001:2022 Annex A 8.24 (cryptography policy) requires documenting algorithm selection, key management, and implementation standards.
What is per-tenant key isolation and why does it matter for SaaS AI?
Per-tenant key isolation means each customer's data in a multi-tenant AI system is encrypted with a unique encryption key specific to that customer, not a shared key. If the system uses a shared encryption key, a key compromise exposes all customers' data. With per-tenant isolation, a key compromise affects only one customer. Beyond security, per-tenant key isolation enables crypto shredding: when a customer wants to delete their data (GDPR right to erasure, offboarding), destroying their encryption key renders all their data cryptographically inaccessible without the expensive process of physically deleting every record.
Should we use TLS 1.2 or TLS 1.3 for AI system communications?
TLS 1.3 is strongly preferred for all AI system communications. TLS 1.3 eliminated cipher suites known to be weak (RC4, DES, 3DES, export-grade ciphers, MD5, SHA-1 for HMAC), requires Perfect Forward Secrecy (preventing retrospective decryption if a private key is compromised), and is faster (1-RTT handshake vs 2-RTT for TLS 1.2). Where TLS 1.3 support is not available (legacy enterprise systems), TLS 1.2 with restricted cipher suites (only ECDHE+AESGCM or ECDHE+CHACHA20) is acceptable. TLS 1.1, TLS 1.0, and SSL are deprecated and must not be used.
What is the harvest now, decrypt later threat for AI data?
Harvest now, decrypt later (HNDL) is an attack strategy where adversaries intercept and store encrypted data today, with the intention of decrypting it once quantum computers capable of breaking current public-key cryptography become available. For AI systems handling data with long-term sensitivity (patient medical records, financial records, legal communications, classified government data), HNDL attacks are a present threat even though the decryption capability doesn't exist today. NIST's PQC standards (FIPS 203/204/205, finalized August 2024) provide quantum-resistant algorithms to protect against this threat.
What encryption standards does Claire implement?
Claire implements: AES-256-GCM for all data at rest (conversation history, RAG documents, vector embeddings, audit logs); TLS 1.3 for all inter-component and external communications with TLS 1.2 fallback only where required by legacy integration; FIPS 140-3 Level 3 validated AWS KMS for key management; unique CMK per customer for per-tenant key isolation; annual key rotation with automated rotation for DEKs; BYOK support for enterprise customers; and a PQC migration roadmap targeting hybrid classical/ML-KEM deployment by 2026. Encryption architecture documentation is available under NDA.
How Claire Addresses AI Encryption Standards
Claire implements AES-256-GCM at rest, TLS 1.3 in transit, FIPS 140-3 Level 3 HSM key management, and per-tenant key isolation. Our BYOK option allows enterprise customers to control their own encryption keys for maximum data sovereignty. Request our encryption architecture documentation as part of an enterprise security review.