Has anybody seen my keys? A key-hierarchy strategy for rack-level security
Oxide's RFD 0301 proposes a rack-level key hierarchy using Shamir secret sharing and a trust quorum to protect data-at-rest keys.
Oxide's request for discussion (RFD 0301) lays out a key-hierarchy strategy for rack-level security, deriving keys from a rack secret protected by Shamir secret sharing across a trust quorum of sleds, with keys exchanged over authenticated sprockets sessions. The document maps which keys protect control-plane data, metrics, Crucible extents, and authentication tokens, and defines open questions on key lifecycle, locality, and compromise handling. Future work includes sealing shares with the root of trust so an attacker would need to steal K whole sleds to reconstruct the rack secret.
- Rack secret split into N shares via Shamir secret sharing
- K-of-N trust quorum reconstruction prevents offline theft of encrypted data
- Key hierarchy covers Crucible, CockroachDB, Clickhouse, and internal service certificates
- Planned RoT sealing would decrypt shares only at sled boot
- Vendors
- Oxide Computer
- Products
- Oxide RackCrucibleCockroachDB
- Organizations
- Oxide Computer
From the original article
15 min read at rfd.shared.oxide.computerThere are many different types of secrets inside an oxide rack. At the base of the system we have the DeviceId and Alias keys stored on the RoT and used for platform identity and measurement signing for attestation
By cyb0rg0 · rfd.shared.oxide.computer
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.