Has anybody seen my keys? A key-hierarchy strategy for rack-level security
summary
To prevent data theft from stolen drives or sleds, the system implements a rack-level security strategy using a Trust Quorum and a hierarchical key structure. This approach uses Shamir's Secret Sharing to distribute a rack secret among multiple nodes, ensuring that no single component holds the full key. By deriving specific encryption keys for each U.2 drive from this central secret, the system ensures that data remains encrypted at rest and can be securely rotated during configuration changes.
key points
- The system employs a Trust Quorum where a rack secret is split into shares; a minimum number of shares (K) must be collected from different sleds to reconstruct the secret, making physical theft of a few drives useless.
- A key derivation function (HKDF) is used to generate unique ZFS encryption keys for every individual U.2 drive based on its hardware identity, preventing a single compromised disk key from exposing other drives.
- To handle rack reconfigurations, the system uses a two-phase commit protocol where a new rack secret wraps the old one, allowing nodes to transition encryption keys without decrypting and re-encrypting massive amounts of data.
who should read it
Security architects and systems engineers designing hardware-level encryption and key management for distributed data center infrastructure.
discussion warm
consensus
The commenters focus on the technical implementation of Oxide's trust quorum approach for secret management. They agree that the mechanism for wrapping old rack secrets under new epoch keys allows for a clean resolution of the distributed systems challenge of ZFS rekeying. The sentiment is generally positive, emphasizing the technical elegance of the technical solution.
top insight
The most valuable perspective is the insight into how wrapping secrets under keys derived from new epochs prevents the need for unlocking secrets before the commit phase. This approach solves the specific tension between requiring dual secrets for ZFS rekeying and ensuring shares are only served for the committed epoch. It provides a practical architectural pattern for reducing risk during key rotation.
Generated by an LLM from the article and thread. Check the sources before relying on it.