Guide · Customer-managed keys

Customer-managed keys (CMK)

CMK in fastpace means a key-encryption key (KEK) generated inside the customer's repo, with the private half never leaving the customer's filesystem. fastpace seals artifacts under that KEK using a standard envelope scheme. This is the engineering story behind the "your data, your keys" line on the pricing page.

Part 1

The scheme: X25519 + AES-256-GCM envelope

fastpace's envelope encryption is the textbook two-key scheme, chosen so customers don't have to take fastpace's word for any of the crypto primitives:

Same shape as AWS KMS / GCP KMS envelope encryption — by design. Customers who already audit those services can pattern-match. Difference: the KEK does not live on a managed service. It lives in fastpace/cmk/ in the customer's repo, protected by filesystem permissions.

Part 2

Lifecycle

Initialise

$ fastpace cmk init
✓ generated new KEK at fastpace/cmk/
  kek.pub  (X25519 public key, 32 bytes)
  kek.priv (X25519 private key, 32 bytes, mode 0600)
  kek.json (key metadata: kid, created_at, alg)

  Next: seal artifacts with `fastpace cmk encrypt <file>` or wire
  the seal hook to encrypt sensitive evidence on egress automatically.

Status

$ fastpace cmk status
KEK present:    fastpace/cmk/kek.{pub,priv,json}
KEK id:         k_4f2a91...
created_at:     2026-05-13T01:22:11Z
algorithm:      x25519 / aes-256-gcm (envelope)
sealed under this KEK: 12 files

Encrypt / decrypt

$ fastpace cmk encrypt secrets/customer-list.csv --out evidence/cust.sealed
✓ sealed under KEK k_4f2a91
  size: 8,402 bytes plaintext → 8,592 bytes envelope

$ fastpace cmk decrypt evidence/cust.sealed --out /tmp/recovered.csv
✓ unsealed

Rotate

fastpace cmk rotate generates a new KEK and re-wraps existing envelopes under the new key. The previous KEK stays accessible (renamed under fastpace/cmk/archive/) so in-flight envelopes signed under the old KEK can still be opened during the rotation window.

Compliance frameworks typically ask for a documented rotation cadence (NIST SP 800-57 suggests ≤ 2 years for long-term KEKs). Set yours and run fastpace cmk rotate on that cadence; the command leaves a signed entry in the audit chain.

Part 3

What it's for

CMK isn't required for fastpace's audit-chain story — the signed evidence trail works without sealing anything. CMK shows up when the customer needs to:

Part 4

The wire format

Every sealed envelope is a deterministic JSON document with a stable schema. Easy to diff in a code review, easy to parse from a third-party tool if a customer ever wants to detach from fastpace: 

{
  "schema":   "fastpace.cmk.envelope/v1",
  "kid":      "k_4f2a91...",
  "alg":      "x25519+hkdf-sha256+aes-256-gcm",
  "wrapped_dek":   "<base64>",
  "ephemeral_pub": "<base64 X25519 pubkey>",
  "nonce":    "<base64 96-bit>",
  "ciphertext": "<base64>",
  "tag":      "<base64 128-bit GCM tag>",
  "aad":      "<optional bound context>"
}

No proprietary header bits. No fastpace-internal serialization. A determined customer can take the published scheme and unseal with openssl + a small wrapper — fastpace's CLI is a convenience layer, not the only way in.

Part 5

Compliance posture

QuestionAnswer
Where does the private KEK live? fastpace/cmk/kek.priv in the customer's repo, mode 0600
Does fastpace ever transmit the private KEK? No. No fastpace process reads it for transport; license validation does not touch fastpace/cmk/
What encryption primitives are used? X25519 (RFC 7748) for ECDH + HKDF-SHA-256 (RFC 5869) for KDF + AES-256-GCM (FIPS 197 / SP 800-38D) for AEAD
How is rotation handled? fastpace cmk rotate — new KEK, re-wraps existing envelopes, archives the old KEK, leaves a signed audit-chain entry
Can a customer egress without fastpace? Yes. The envelope schema is documented; any X25519 + HKDF + AES-GCM toolchain can unseal
Next

Related