Platform / Key Management

Sealed Key Lifecycle

Keys are derived inside the enclave during initialization and never exist in the clear outside it — sealed to the measurement, rotated automatically, and scoped to workload identity.

Key derivation flow

Almure's key derivation model is anchored in the hardware's Provisioning Certification Key (PCK) and the enclave's measurement. During enclave initialisation, the hardware derives an enclave-specific root key using a deterministic KDF that takes the mrenclave and platform identity as inputs. This root key is used to derive workload-scoped data keys on demand. The entire derivation chain happens inside the CPU — no key material is ever visible to host software.

Key lifecycle diagram showing sealed key derivation inside enclave, rotation policy, and scope binding to workload identity
Key lifecycle: derive → seal → bind → rotate → expire.

Sealing policy options

Two sealing modes are available, configurable per workload:

  • Measurement-bound sealing: Sealed data can only be unsealed by an enclave with the exact same mrenclave value. Any code change — including a patch — produces a different measurement and cannot access previously sealed data without explicit migration. Appropriate for workloads where strict code immutability is required.
  • Signer-bound sealing: Sealed data can be unsealed by any enclave signed by the same key (mrsigner), regardless of code version. Enables zero-downtime software updates without key migration between versions. Appropriate for production workloads with regular patching cycles.

Rotation schedule

Almure supports automatic key rotation on a configurable schedule (default: 90 days). Rotation generates new derived keys inside the enclave, re-encrypts the small key-binding metadata, and decommissions old key material without any operator access to key values. The rotation event is logged in the attestation audit trail with the new key generation measurement.

HSM integration

For organisations that require an external Hardware Security Module as the ultimate root of trust, Almure supports a remote root-binding mode. In this configuration, the HSM holds the top-level binding material and the enclave must present a valid attestation quote to the HSM before receiving its derived key seed. The HSM validates the quote against the known mrenclave before releasing the seed — so the key derivation chain becomes: hardware HSM root → attested CPU measurement → workload-scoped data key. No key material transits the network in clear form at any point in this chain.

This configuration is designed with reference to FISC security guidelines for financial institutions that require an external, auditable root of trust for cryptographic key material used in production data processing.

Almure does not claim FISC certification. Key management controls are designed with reference to FISC guidelines for financial system key management. Compliance determination remains with the deploying organisation and its legal team.