Castle reference architectures/Hybrid

Split seed custody with enclave code generation

TOTP seeds are split between a customer share and a cloud share. Only a Nitro Enclave with a valid PCR set can reconstruct the seed, generate codes for the approved window, and encrypt them to the requestor’s device.

Split key sharesNitro EnclaveAWS KMSECIES + AEADS3 object expiryDevice keypairs
Customer share
Cloud share · KMS
Access service
Two shares · one enclave
CastleCastle cannot see seeds
Policy satisfiedREQUIRED
Share decryptionIN ENCLAVE
TOTP generationRFC 6238
Chunk encryptionECIES
Encrypted chunksS3 · presigned URLsRequestor deviceCodes out, never seeds
Seed destroyed after generationChunks expire automaticallyAAD binds chunk to device and window

Dataflow

01

At enrollment the app splits the TOTP seed into a customer share, encrypted to enclave then enterprise keys, and a cloud share encrypted under AWS KMS, decryptable only by an enclave with a valid PCR set.

02

When a policy is satisfied, the customer share is decrypted and posted; the enclave fetches and decrypts both shares and reconstructs the seed.

03

The enclave computes RFC 6238 codes covering the approved window, accounting for clock drift, in chunks of at most 24 hours.

04

Each chunk is encrypted to the requestor’s device key with single shot ECIES and AEAD. The associated data binds the ciphertext to the enterprise, user, device, resource, request, and window.

05

Chunks land in S3 under a structured key scheme with object expiry; the access service hands the client presigned URLs.

06

The device fetches, decrypts locally, and displays codes with a live countdown. Expired chunks vanish from S3 and the device; the seed material in the enclave is destroyed after generation.

Components

Key hierarchy

Enterprise, user, and device keypairs (NIST P 256, single shot ECIES) with layered wrapping: enterprise key wraps shares, user key unwraps chunks, device key unwraps the user key.

Nitro Enclave runtime

Reuses the Bunker enclave architecture with KMS gating. The sole trusted execution environment for seed reconstruction.

Code distribution layer

Stateless S3 delivery of encrypted chunks via presigned URLs, self cleaning through object expiry.

AEAD binding

Associated data ties every ciphertext to its session, device, and policy, so chunks cannot be replayed elsewhere.

Access service

Orchestrates the flow without ever touching plaintext: policy checks, enclave coordination, URL generation.

Security considerations

Castle cannot access customer seeds: servers and operators are never in the trust path, and only an attested enclave can reconstruct.

A compromised distribution layer leaks only ciphertext bound to specific devices and windows.

The layered wrapping supports device revocation and role changes with minimal recomputation and no seed re enrollment.

Codes are the only artifact that leaves the enclave, and they expire on a fixed clock. The blast radius of any single leak is one account for one window.

Deploy this architecture

Walk through the trust model, policy design, and rollout with our security and solutions team.

Learn moreAll architectures