Key Storage Locations Limited
Effective: March 17, 2026 · DCF-271
1. Purpose
This document defines H33.ai's policy for the storage, management, and rotation of all cryptographic keys and credentials. All cryptographic material must be stored in approved, access-controlled locations to prevent unauthorized access, disclosure, or compromise. This policy is critical given H33.ai's role as a post-quantum cryptographic infrastructure provider, where key security directly impacts customer trust and data protection.
2. Policy Statement
All cryptographic keys used by H33.ai are stored exclusively in approved, access-controlled locations. No keys, secrets, or credentials are stored in source code, configuration files committed to version control, or unencrypted storage media. This policy applies to all key types across the H33 cryptographic engine, Auth1 authentication service, and supporting infrastructure.
3. Key Inventory
| FHE Keys (BFV) | BFV public/secret key pairs used for fully homomorphic encryption. Generated per session using CSPRNG (rand crate). Stored only in encrypted process memory during the session lifetime. Never persisted to disk. Secret keys are in NTT form; public keys (pk0/pk1) are in pipeline NTT form. Key material is zeroed on drop. |
| Dilithium Signing Keys | ML-DSA (Dilithium) post-quantum signing keys used for batch attestation (1 signature per 32-user FHE batch). Stored in AWS Secrets Manager. Rotated annually. Used for sign+verify operations at 291 µs per batch. |
| Kyber Key Exchange Keys | ML-KEM (Kyber) post-quantum key encapsulation keys used in hybrid encryption (Kyber + AES-256-GCM). Ephemeral, per-session. Generated for each key exchange operation and discarded after use. Never persisted. |
| TLS Certificates | X.509 certificates for HTTPS endpoints (h33.ai, auth-api.z101.ai). Managed by AWS Certificate Manager (ACM). Auto-renewed 60 days before expiration. Private keys are generated and stored within ACM (never exported). |
| Database Encryption Keys | Encryption keys for RDS PostgreSQL at-rest encryption. Managed by AWS RDS using AES-256. Keys are stored in AWS KMS and never accessible to H33.ai personnel directly. |
| S3 Encryption Keys | Server-side encryption keys for S3 buckets (log archival, backups). Uses SSE-S3 (AWS-managed) or SSE-KMS (customer-managed KMS key) depending on bucket sensitivity. KMS keys managed via IAM policies. |
| Auth1 JWT Signing Keys | HMAC or RSA keys used to sign and verify JWT authentication tokens. Stored in AWS Secrets Manager. Rotated annually. Injected into Elastic Beanstalk environment at deploy time. |
| Customer API Keys | API keys issued to H33.ai customers (e.g., auth1_pk_*, ck_live_*). Hashed (SHA-256) in PostgreSQL. Plaintext is shown to the customer once at issuance and never stored by H33.ai. Customers can rotate keys at any time via the dashboard. |
| Stripe / Twilio Keys | Third-party API credentials for payment processing and SMS delivery. Stored in AWS Secrets Manager. Injected into Elastic Beanstalk environment variables at deploy time. Never committed to source code. |
| SSH Keys | SSH keys for EC2 instance access (e.g., benchmark hosts). IAM-managed, individual keys per authorized user. Stored in AWS Systems Manager Parameter Store (encrypted). Access logged via CloudTrail. |
4. Approved Storage Locations
The following are the only approved locations for cryptographic key and credential storage:
- AWS Secrets Manager: Primary credential store for long-lived secrets (Dilithium keys, JWT signing keys, third-party API keys). Supports automatic rotation, versioning, and fine-grained IAM access control. All access logged via CloudTrail.
- AWS Certificate Manager (ACM): TLS certificate and private key management. Private keys are generated within ACM and never leave the service.
- AWS KMS: Master keys for RDS and S3 encryption. Supports automatic key rotation (annual for AWS-managed CMKs).
- Process memory (encrypted): FHE session keys (BFV public/secret) and ephemeral Kyber keys. Exist only during the active session in Rust process memory. Zeroed via
Dropimplementations when the session ends. - PostgreSQL (hashed): Customer API keys stored as SHA-256 hashes. Lookup-only; original plaintext is irrecoverable from the hash.
5. Prohibited Storage Locations
Cryptographic keys and credentials must never be stored in the following locations:
- Source code repositories: No secrets, API keys, passwords, or private keys in any file committed to GitLab (including comments, test fixtures, and documentation).
- Environment files committed to git:
.envfiles are in.gitignore. Environment variables are injected at deploy time via Elastic Beanstalk configuration or Secrets Manager. - Unencrypted local storage: No keys stored on local disk in plaintext, including developer workstations, USB drives, or external storage.
- Email or chat: Keys must never be transmitted via email, Slack, or any messaging platform. Secure sharing uses AWS Secrets Manager or one-time share links with automatic expiration.
- Documentation or wikis: No credentials in Confluence, Notion, Google Docs, or any documentation platform.
- Client-side storage: No secrets in browser localStorage, sessionStorage, or cookies (Auth1 uses httpOnly cookies for JWT tokens, but the signing key is server-side only).
- Container images: No secrets baked into Docker images or container layers.
6. Access Control
Access to cryptographic keys and credential stores is controlled through AWS IAM policies:
- Principle of least privilege: IAM policies grant access only to the specific secrets and KMS keys required for each role or service.
- MFA required: Console access to Secrets Manager and KMS requires multi-factor authentication.
- Service roles: EC2 instances and Elastic Beanstalk environments access secrets via IAM instance roles, not embedded credentials.
- No root account access: The AWS root account is not used for day-to-day operations. Root access requires MFA and is reserved for billing and account-level operations only.
7. Key Rotation Schedule
| FHE Session Keys | Per session — New key pair generated for each authentication batch. No rotation needed; keys are ephemeral. |
| Kyber KEM Keys | Per session — Ephemeral, generated per key exchange. No rotation needed. |
| Dilithium Signing Keys | Annually — Rotated via Secrets Manager with versioning. Old version retained for 90 days for signature verification of in-flight batches. |
| Auth1 JWT Signing Keys | Annually — Rotated via Secrets Manager. Old key retained for token validation until all issued tokens expire (maximum 24 hours). |
| TLS Certificates | Auto-renewed — ACM renews certificates 60 days before expiration. No manual intervention required. |
| Database Encryption (KMS) | Annually — AWS-managed CMK automatic rotation. |
| Customer API Keys | On demand — Customers can rotate via dashboard at any time. Recommended annually. |
| Third-Party Keys | Quarterly — Stripe and Twilio API keys rotated quarterly via Secrets Manager. |
| SSH Keys | Annually — Individual SSH keys rotated annually. Immediate revocation on personnel departure. |
8. Monitoring
- CloudTrail: All AWS Secrets Manager access events (GetSecretValue, PutSecretValue, RotateSecret) are logged and monitored. Anomalous access patterns trigger alerts via DataDog.
- KMS key usage: CloudTrail logs all KMS Encrypt/Decrypt/GenerateDataKey calls. Unusual volume or off-hours access generates CISO alerts.
- Pre-commit hooks: GitLab pre-commit hooks scan staged files for patterns matching API keys, passwords, private keys, and tokens. Commits containing detected secrets are blocked.
- GitLab secret detection: CI pipeline includes a secret detection stage that scans all changes for credentials before merge.
9. Review Schedule
- Quarterly: Review of key inventory, access permissions, and rotation compliance. Verify no unauthorized key storage locations exist.
- On personnel change: Immediate review of key access permissions. Revoke access for departing personnel within 24 hours.
- Annual: Comprehensive key management audit as part of SOC 2 and HIPAA compliance cycles.
Questions?
Contact the Security Officer at security@h33.ai or the Compliance team at compliance@h33.ai.
H33.ai, Inc. · 11533 Brighton Knoll Loop, Riverview, FL 33579 · 813-464-0945