The Physicality of Trust: Why Your Rack Security is Likely a Lie

Let's be honest: most of what we call 'rack-level security' is just expensive security theater. As Oxide Computer has detailed in its technical documentation, we often spend our lives obsessing over remote code execution and zero-day exploits delivered via a packet, while ignoring the most devastating vulnerability of all: a person with a screwdriver and a few minutes of unsupervised access. In the cybersecurity world, physical access is the ultimate zero-day. If I can touch the hardware, I own the hardware.

When you look at how most data centers are built, the security model is often binary—you're either in the room or you're not. But once a bad actor is inside that perimeter, the 'security' of the individual sleds often evaporates. This is where the concept of a key hierarchy becomes the only thing that actually matters. If your encryption keys are sitting statically on a disk, you don't have security; you have a speed bump.

To understand why most current implementations fail, we have to look at how a truly paranoid architecture is designed. According to a Request for Comments (RFD 301) published by Oxide Computer, authored by Andrew J. Stone, the only way to actually mitigate the 'walk-off' risk—where an attacker simply steals a subset of drives or sleds—is to ensure that no single piece of hardware holds the keys to the kingdom.

Oxide Computer's approach, as detailed in RFD 301, centers on a 'Trust Quorum.' This isn't just a fancy name for a password; it's a structural dependency. By utilizing Shamir secret sharing, Oxide splits a rack-level secret into N unique key shares. These shares are distributed across bootstrap agents via 'sprockets sessions'—secure, point-to-point communication channels that rely on DeviceId and Alias keys stored on a Root of Trust (RoT).

Here is the critical part that most vendors ignore: the rack secret is not a key itself. It is a key-derivation source. To reconstruct this secret, an agent must retrieve K-1 shares from other members of the quorum. Without obtaining K shares, the RFD 301 documentation explicitly states that no information about the rack secret can be learned.

Currently, Oxide Computer reports that these individual shares are stored unencrypted on the M.2 drives of each sled. To a novice, this sounds like a vulnerability. To a defender, it's a calculated risk. The security doesn't come from the encryption of the share, but from the mathematical impossibility of reconstructing the secret without stealing at least K drives—an act that, as the RFD notes, is infeasible without causing significant disruption and taking a massive amount of time during physical access.

But even that isn't enough for a true threat model. Oxide Computer plans to further harden this by 'sealing' these secrets with the RoT, meaning the secrets would only be decrypted during a sled boot. This raises the bar from 'stealing a drive' to 'stealing K whole sleds' and successfully booting them. When you consider the physical weight of multiple server sleds, the 'casual attacker' is effectively neutralized.

This is what a real key hierarchy looks like. It's a tree where the root (the Rack Secret) is fragmented and distributed, and the leaves are the actual encryption keys used for data at rest. Using this shared secret, the system can wrap individual encryption keys for U.2 devices or generate rack-level root certificates for internal services.

According to the RFD 301 table, this hierarchy is designed to protect a variety of critical data points, including Control Plane Data stored in CockroachDB on some U.2 devices, Control Plane Metrics in Clickhouse, and Crucible Extents files across most U.2 devices.

Most companies don't do this. They rely on a single TPM or a centrally managed key that is delivered over a network. If you can compromise the delivery mechanism or find a way to extract that key from memory, the entire rack falls. By contrast, the Trust Quorum model acknowledges that the hardware *will* be touched, and it builds the security into the physical distribution of the secret itself.

If you aren't thinking about your security in terms of spatial locality—asking where the data lives and what physical restrictions prevent it from being moved—you aren't practicing security; you're practicing hope. As Andrew J. Stone notes in the RFD, these determinations must evolve as the system hardens. That is the only acceptable posture: the assumption that the perimeter has already failed, the attacker is in the room, and the only thing standing between them and your data is a mathematically distributed secret that requires a forklift to steal.