Trust Quorum Key Share Storage Encryption

[andrewjstone]

Per RFD 238, the plan of record is to store trust quorum key-shares on the M.2 devices on each sled. Currently, we implicitly store them unencrypted, but this provides multiple vectors of attack via an online rack, and an offline one. Attackers who gain enough privileges to read one M.2 can more than likely read all M.2s which gives them access to the rack secret. There is no authentication here, and there is no limit to the time that the key shares remain available.

This really is not acceptable, given the level of protection the rack secret provides, and the number of keys we plan to derive and wrap from the rack secret.

While we almost certainly want to store the key shares on the M.2 devices due to size and flexibility, we should store them encrypted, and only provide access to the shares at necessary times and with proper authorization. My current thinking is the following:

1. We store a wrapper key in the RoT that can be used to encrypt the share.
2. The wrapper key is provided to the kernel at boot
3. The bootstrap agent is given the key at boot (or asks the kernel), decrypts the share, and keeps the key and decrypted share around for a limited time (2 minutes ?) until it unlocks its sled, and possibly provides access to other sleds via sprockets.
4. The key and decrypted share are deleted from memory after the limited time
5. When another sled asks via sprockets for the sled's share, the key gets re-requested from the RoT by the bootstrap-agent.
6. Once done with the key and decrypted share, we discard them. We could have bootstrap-agent hold onto it for another 2 minutes in case other sleds are coming online and will be requesting the share. This is to limit overhead of interaction with the SP/RoT.

This is not a perfect solution, but it does add a few extra hurdles for an attacker.

• The attacker now needs to be able to make requests to the RoT and not just read M.2 devices.
• The attacker cannot grab the share from the bootstrap-agent memory at any time, as it is time-limited.

There are a few weaknesses here that could possibly be made stronger, although this solution is never going to be ideal given the automatic nature of rack unlock.

1. The share decryption key is returned raw from the RoT.
2. The key itself is granted to the bootstrap-agent unconditionally

For 1 we could pass the encrypted share to the RoT for decryption and never reveal the key, although this adds overhead.

For 2 we could authenticate the bootstrap-agent using an auth token injected into the illumos kernel at boot and have illumos limit any access to the share key by only allowing the bootstrap-agent to make key requests. We could also ensure that a key or decryption request comes in a timely manner during a sprockets session setup. The kernel will know this, because it has to mediate measurement and signing operations.