# Oxide sketches rack-level key hierarchy to keep stolen drives from revealing data
Oxide is outlining a rack-level security design that tries to make stolen hardware far less useful to an attacker. In a recent request for discussion, the company describes a key hierarchy built around a shared rack secret, split across multiple trusted machines, and used to derive the keys that protect storage and internal services. The aim is straightforward: if someone walks away with only part of a rack, they should not be able to recover meaningful data from it.
The design starts with a trust quorum. Rather than keeping one master secret in a single place, Oxide says the rack secret is divided into shares using Shamir secret sharing and distributed across bootstrap agents that sit on trusted sleds. Each agent carries platform identity information tied to the hardware’s root of trust, so peers can verify who they are talking to before any secret shares move. Once enough members are present, they can exchange the required shares over sprockets sessions and reconstruct the rack secret.
That secret is not used directly as a storage key. Instead, it becomes the root of a hierarchy that derives separate keys for different jobs. The note says the rack secret can be used to derive or wrap per-device encryption keys, internal certificates and other protection material. That matters because the company wants different failure modes for different assets. A stolen disk should not unlock the rest of the rack, and a compromised leaf certificate should not expose the entire storage stack.
The note also explains why Oxide is not leaning on hardware-backed full-disk encryption. The company says it wants to avoid the trust and complexity trade-offs that can come with vendor-managed disk encryption, and instead plans to encrypt nearly the entire ZFS pool on each U.2 drive with a per-disk key. The keys are not stored on the disks themselves. In the current design, that means an attacker would need to compromise enough trusted machines to reconstruct the rack secret before any data could be decrypted.
The hierarchy is also meant to work with the rest of the platform. Oxide says the rack secret can help derive root certificates for internal services and leaf certificates for mutual TLS, while also wrapping keys used for customer and control-plane data. In other words, the same shared trust foundation is meant to support both storage protection and service identity. The note says that a future version may seal these secrets with the root of trust so they can only be decrypted during boot, increasing the amount of hardware an attacker would have to steal and successfully power up.
The RFD is careful to frame the design as a working answer rather than a final one. It asks open questions about where secrets should be local, what physical or logical restrictions should apply to moved data, and which keys should derive from which parents. That candor is useful: the document is not marketing copy, but a design attempt to spell out assumptions before the system hardens around them.
For customers and operators, the practical message is that Oxide wants rack security to be collective rather than centralized. No single drive, sled or service should carry enough authority to unlock the whole system. The company’s bet is that distributing trust across a quorum and tying cryptography to hardware identity will make physical theft and partial compromise much less valuable.
Event date: 2026-09-07
