Fáfnir

Org-Key Sealed Secrets

Problem

Tools deployed by MDM need secrets: API client secrets, bearer tokens, keys for a gateway. Configuration profiles are a poor place for them. Anyone on the Mac can read managed preferences, the MDM console shows them to every admin with read access, and they end up in exports, screenshots and support tickets.

Context & forces

• MDM is still the right channel: it already decides which Macs get which configuration.
• Admins must be able to produce encrypted values without special tooling or the private key.
• The private key must never be extractable from a managed Mac.
• Several tools from the same organisation should not each require their own key rollout.
• Values for one tool must not be usable by another by accident.

Solution

Create one organisation key pair, once. Deploy its identity (certificate and private key) to the Macs through an MDM certificate payload in the System keychain, non-exportable. Share only the public certificate with admins. They encrypt each secret against it and paste the resulting envelope into the profile:

<TOOL>-ENC:v1:<key id>:<sealed bytes>

On the Mac, the tool finds the identity by key id, unseals the value at the moment it needs it (for example when requesting a token), and never writes the plaintext to disk.

 Admin Mac                          MDM                          Managed Mac
 public cert ──▶ encrypt ──▶ TOOL-ENC:v1:… ──▶ profile ──▶ tool ──▶ unseal in keychain
 private key ──(offline vault)                 cert payload (.p12) ──▶ System keychain

For developers

• Envelope: an ephemeral P-256 key agrees a secret with the org key (ECDH), HKDF-SHA256 derives an AES-256-GCM key, and the prefix with key id is authenticated data.
• Domain separation: each tool has its own prefix and its own HKDF info string. One key serves all tools, but a Gimle value can never be decrypted as a Jarl value.
• The key id (a short hash of the public key) selects the key, which makes rotation possible: deploy the new key next to the old one, re-encrypt, then remove the old key.
• Unsealing uses the keychain's key-exchange operation, so the private key stays inside the keychain.
• Encryption works offline: a CLI command, plus a single static HTML page using WebCrypto. The two implementations are tested against each other.
• Partial strings are allowed ("Bearer <TOOL>-ENC:v1:…"), so tokens inside headers work.
• Warn in the UI when a plaintext secret is found where an envelope is expected.
• The same key can also wrap data keys for content at rest (encrypted backups).

Consequences

• Profiles, MDM exports and console screenshots no longer leak secrets.
• One key rollout serves every tool, and adding a tool costs nothing on the Macs.
• It protects the delivery path, not the endpoint. If the tool must write the secret into a file the user can read, a local user can still see it. A vendor credential helper is stronger where one exists.
• Losing every copy of the private key makes encrypted data unreadable. The key belongs in a vault.
• Key rotation is a small operational procedure that admins need to know about.

Known uses

• Mimir decrypts envelopes inside policy fragments and writes the plaintext only into the rendered vendor file. A harness whose secret cannot be decrypted stays at its last applied state.
• Gimle uses envelopes for client secrets of MDM-provisioned instances, and uses the same key to wrap the data key of encrypted backups.
• Jarl uses the same organisation key as Gimle. Admins who deployed Gimle's key profile install nothing new.
• Janus reads encrypted Gimle backups with the organisation key.
• Lynceus uses the same key for the client secrets of managed instances, for the API key of an external AI server (OpenAIAPIKey), and to scan encrypted Gimle backups.

Name

Fáfnir, the dragon who guarded the hoard: the secret stays sealed, guarded by one key, until the right holder comes.