Key rotation is a fundamental security hygiene practice. Every encryption system, from TLS to disk encryption to database encryption, rotates keys periodically to limit the damage from key compromise and to reduce the amount of data encrypted under any single key. FHE is no exception: the encryption keys used to protect biometric templates, financial records, and medical data must be rotated on a regular schedule.
But FHE key rotation is fundamentally harder than traditional key rotation. When you rotate a TLS certificate, you generate a new key and start using it for new connections. Old connections complete under the old key, and the transition is seamless. When you rotate a database encryption key, you re-encrypt the data at rest with the new key, typically during a maintenance window. The data is briefly decrypted in memory, re-encrypted, and written back.
FHE key rotation cannot use either of these approaches. FHE ciphertexts are not just stored at rest; they are actively used for homomorphic computation. You cannot simply generate a new key and start using it, because existing ciphertexts encrypted under the old key are incompatible with new-key ciphertexts. Homomorphic operations require all operands to be encrypted under the same key. And you cannot re-encrypt by decrypting and re-encrypting, because that requires bringing plaintext data into memory on a server that should never see plaintext.
This creates a genuine operational challenge: how do you rotate FHE keys without decrypting data and without taking the system offline?
Proxy Re-Encryption
The solution is proxy re-encryption (PRE), a cryptographic technique that transforms a ciphertext encrypted under one key into a ciphertext encrypted under a different key, without decrypting it. The transformation is performed by a proxy that holds a re-encryption key, a special key derived from both the old and new encryption keys. The proxy can transform ciphertexts between keys but cannot decrypt them under either key.
In H33's key rotation protocol, the key rotation process works as follows. First, a new FHE key pair is generated on the client side (or in an HSM). Second, a re-encryption key is derived from the old secret key and the new public key. Third, the re-encryption key is sent to the proxy service (which can be H33 or a dedicated re-encryption service). Fourth, the proxy transforms existing ciphertexts from old-key to new-key using the re-encryption key. Fifth, the old key is archived and eventually destroyed after all ciphertexts have been re-encrypted.
The critical security property is that the proxy never possesses either the old secret key or the new secret key. It only possesses the re-encryption key, which enables transformation but not decryption. Even if the proxy is fully compromised, the attacker gains the ability to transform ciphertexts between keys but not to decrypt any ciphertext. The plaintext data remains protected.
The Transition Window
Key rotation is not instantaneous. A large biometric database might contain millions of encrypted templates, and re-encrypting each one takes time. During the transition period, some templates are encrypted under the old key and some under the new key. The system must handle computations involving ciphertexts under both keys.
H33 manages this through a dual-key evaluation mode. During the transition window, the system maintains evaluation keys for both the old and new encryption keys. When a biometric authentication request arrives, the system determines which key the probe ciphertext uses and which key the stored template uses. If both use the same key, the computation proceeds normally. If they use different keys, the system applies proxy re-encryption to transform one ciphertext to match the other before computing.
The dual-key mode adds latency to cross-key computations (approximately 15-20% overhead for the re-encryption step) but does not affect same-key computations. As the background re-encryption job progresses, the proportion of cross-key computations decreases, and the system converges to full new-key operation. Once all templates are re-encrypted, the dual-key mode is deactivated and the old evaluation keys are deleted.
From the client's perspective, the key rotation is invisible. Authentication requests return the same encrypted match/no-match results with the same 74-byte attestation. The only observable change is a temporary slight increase in average latency during the transition window, which resolves once re-encryption completes.
Key Rotation Policies
H33 supports configurable key rotation policies that balance security requirements against operational overhead. The default policy rotates keys every 90 days, which aligns with common compliance frameworks (SOC 2, PCI DSS). High-security policies rotate every 30 days. Custom policies can be configured based on the organization's risk assessment.
The rotation schedule is independent of the rotation execution. When a rotation is triggered, the system begins background re-encryption at a controlled rate that does not impact foreground computation throughput. A million-template database can typically be re-encrypted within hours at a background rate that consumes less than 10% of the system's compute capacity.
Emergency rotation is also supported. If a key compromise is suspected, the system can initiate an immediate rotation that prioritizes re-encryption speed over background impact. Emergency rotation consumes more compute capacity but completes faster, minimizing the window during which the compromised key is active.
Evaluation Key Management
FHE key rotation involves more than just the encryption/decryption key pair. Evaluation keys (relinearization keys and Galois keys) must also be rotated, and these keys are substantially larger. A full set of evaluation keys for BFV with N=4096 can be tens of megabytes. Distributing new evaluation keys to all computation nodes takes time and bandwidth.
H33 stages evaluation key distribution before the encryption key rotation begins. New evaluation keys are pre-distributed to all computation nodes and held in standby. When the encryption key rotation is triggered, the computation nodes switch to the new evaluation keys atomically. This pre-staging eliminates the latency spike that would occur if evaluation key distribution happened during the rotation.
The old evaluation keys are retained during the transition window for dual-key computations. Once all ciphertexts are re-encrypted and the dual-key mode is deactivated, the old evaluation keys are securely deleted from all computation nodes. The deletion is verified through the attestation system, which confirms that no computation node retains old-key material after the rotation completes.
Attestation Continuity
Key rotation must not break the attestation chain. Computations performed under the old key must have valid attestations, and computations performed under the new key must have valid attestations. The transition between keys must not create a gap in attestation coverage.
H33's attestation system is independent of the FHE encryption keys. The Dilithium signing keys used for attestation are separate from the BFV/CKKS encryption keys. When FHE keys rotate, the attestation signing keys remain unchanged (they have their own rotation schedule). This means attestations generated before, during, and after FHE key rotation are all signed with the same attestation key and can be verified with the same public verification key.
The attestation includes a key identifier that specifies which FHE key was used for the computation. This enables auditors to verify that a specific computation was performed under a specific key at a specific time, providing a complete audit trail of key usage across rotation events.
Compliance Implications
Key rotation is not optional for regulated industries. PCI DSS requires cryptographic key rotation at least annually. SOC 2 requires documented key management procedures including rotation. HIPAA requires encryption key management controls that include periodic rotation. NIST SP 800-57 provides detailed guidance on key management lifecycles.
H33's automated key rotation satisfies these requirements without manual intervention. The rotation is policy-driven, logged, attested, and auditable. Compliance teams can configure the rotation schedule, review rotation logs, and verify that all ciphertexts have been re-encrypted under the current key. The audit trail includes timestamps, key identifiers, re-encryption completion status, and attestation verification results.
The zero-downtime aspect is particularly important for healthcare and financial services, where systems must be available 24/7. Traditional key rotation approaches that require maintenance windows are increasingly unacceptable for mission-critical systems. FHE key rotation through proxy re-encryption eliminates the maintenance window entirely, enabling continuous operation with continuous key rotation.
Key rotation is one of the operational challenges that separates production FHE systems from research prototypes. A system that can encrypt and compute but cannot rotate keys is not production-ready. H33 handles key rotation as a core infrastructure concern, invisible to the application developer but critical for the security and compliance of the encrypted data.
Key Rotation in Multi-Tenant Systems
Multi-tenant FHE systems add another dimension to key rotation. Each tenant has its own encryption keys, and tenants may be on different rotation schedules. The system must manage concurrent rotations across tenants without cross-contamination of key material and without affecting the performance of tenants that are not currently rotating.
H33 isolates key rotation per tenant. When one tenant's keys rotate, only that tenant's ciphertexts are re-encrypted. Other tenants' ciphertexts and evaluation keys are unaffected. The background re-encryption job operates on the rotating tenant's data partition without accessing other tenants' partitions, ensuring that key rotation for one tenant does not create side-channel information about other tenants.
The resource allocation for background re-encryption is also per-tenant. Each tenant's rotation job is allocated a configurable fraction of the system's compute capacity, ensuring that no single tenant's rotation dominates the system's resources. This is particularly important in shared infrastructure where tenants have different data volumes and different rotation frequencies.
Emergency rotation in a multi-tenant system must be carefully scoped. If one tenant's key is compromised, only that tenant's keys need emergency rotation. Other tenants' keys are unaffected and do not need accelerated rotation. H33's per-tenant key management ensures that emergency rotation for one tenant does not disrupt service for other tenants.
The operational complexity of multi-tenant key rotation is significant, which is why H33 automates it entirely. Rotation schedules are configured per tenant, background re-encryption runs automatically, evaluation key pre-staging happens transparently, and dual-key mode activation and deactivation are handled by the platform. The tenant administrator sees only the rotation policy configuration and the rotation status dashboard. The cryptographic complexity is invisible.