ArkLabsHQ/enclave runs an application in an AWS Nitro Enclave. The image has a measurement, PCR0, which changes when the runtime, the application, or the baked environment changes.
The runtime protects secrets with a KMS key bound to that measurement. A new deployment can inherit those secrets only through a recorded state handover, after a cooldown enforced by its predecessor.
A client must pin the expected PCR0 and verify attestation to confirm that responses come from an enclave that runs the trusted image. The enclave CLI and the Go client verify the Nitro attestation against the expected PCR0.
Replace the URL and PCR0 below with the endpoint and the measurement of the image you trust.
Secrets at deployment
A fresh deployment creates its own secrets. The runtime asks AWS KMS for a random 32-byte master seed. KMS encrypts the response to an attested enclave key, so the operator receives no plaintext seed. The runtime derives application secrets and its storage key from the seed through HKDF-SHA256. It also derives an ACME account key and creates an independent TLS private key inside the enclave (secret derivation). Restarts restore the same secrets, and migrations preserve them. The runtime stores the encrypted seed and TLS key in an attested S3 snapshot. Before it restores state, it verifies the snapshot’s identity, receipts, and retention protection. In production, the KMS key permits decryption only with attestation for that generation’s PCR0 (state lifecycle). An application can also accept an existing secret, such as a key from an earlier system. The image fixes its expected hash or public key, and the runtime checks that commitment before it accepts the supplied value. This check proves which secret the application uses, but previous holders can still know it (inherited secrets).Deploying a new version
Building the enclave
The build packages the application, the enclave runtime, and their fixed configuration into one image. It also produces the image’s PCR0 measurement. A change to any of these inputs changes that measurement (image build). For an upgrade, the image identifies the version it will replace. Build the new image before you request access to the existing deployment’s secrets. Users can inspect the image and its measurement before the handover.Waiting through the cooldown
The operator starts the new version alongside the current version. The current enclave verifies the new enclave’s attestation, then publishes a record of the proposed upgrade. This record identifies the new image by its PCR0. The new version must wait through a cooldown before it can receive the existing secrets. The current image fixes the cooldown’s duration, so the operator cannot shorten it through runtime settings. The cooldown starts when the upgrade record is published. During this period, the current enclave reports the proposed image and the time when the handover becomes possible. The upgrade can be cancelled before the handover (upgrade process).Passing secrets to the new version
After the cooldown, the current enclave encrypts the secrets for the new image’s measurement. The new enclave verifies who sent them, the recorded upgrade, and the restrictions on decryption before it accepts them. The cooldown gives third parties time to inspect the proposed image before it can inherit secrets. Attestation confirms which image runs, but it does not prove that the code is safe.Migration records
Before secrets can pass to a new version, the current enclave records the proposed migration in Amazon S3. This record identifies the proposed image and establishes when its cooldown starts. A cancellation adds another record. The records preserve proposed migrations and cancellations, but they do not, by themselves, prove that secrets changed hands. S3 Object Lock protects these records for ten years in production. Even the account’s root user cannot delete protected versions, overwrite them, or shorten their retention during that period. See S3 Object Lock. The runtime verifies each record’s attestation and retention protection before it accepts it. It checks stored versions so later uploads or delete markers cannot hide retained records (record verification). Check the current migration status through an attestation-verified connection to the enclave. The request above uses/enclave/v1/info. It reports the proposed image, when the cooldown ends, and whether the migration is pending, eligible, or cancelled.
This response reports verified status. It does not return the full migration log, and third parties do not need direct access to S3 to check it.
Clock
OP_CHECKTIME compares a timestamp with the Unix time of the machine that runs the Emulator. The engine reads the Go function time.Now when it starts to run an input (engine.go). The enclave runtime synchronizes that clock with the PTP hardware clock exposed by the hypervisor.
The production clock behavior is:
The clock-source check and synchronization cadence are fixed by the measured image. A change requires a new image with a new PCR0 (clock implementation).
State and recovery
The runtime writes no state to local disk. AWS Systems Manager Parameter Store (SSM) holds the encrypted seed and TLS key, one pair for each generation. A restart or replica with the same PCR0 verifies its state receipt and decrypts that generation’s state. A migration preserves the predecessor’s access to its own state. The predecessor retains its key and ciphertexts, so it can continue to serve or restart. Recovery requires that generation’s image, encrypted state, receipts, and KMS key. The ancestry report describes each ancestor key asexists, pending_deletion, deleted, or unknown. A pending deletion can be cancelled. Only deleted confirms that KMS can no longer decrypt state with that key. An unknown status or an incomplete ancestry does not prove retirement.
A migration preserves the seed. If that seed has been exposed, recovery of secrecy requires a fresh deployment with a new seed.