Encrypt and authenticate MGS ⇔ SP traffic

[DemiMarie]

This would allow the MGS to verify that it is talking to an SP on a board with a genuine RoT and that the RoT has attested the SP. It would also provide for cryptographic verification of the identity of a sled, thereby solving #141. It would even allow for a sled to keep its identity when it is moved between slots on a rack, or even between racks.

[jgallagher]

👍 Related issue in hubris: oxidecomputer/hubris#723

[DemiMarie]

Some notes (disclaimer: not affiliated with Oxide, merely very excited about it):

• Since Oxide controls both sides of the connection, it is not necessary to use a standard protocol such as TLS. TLS has a large amount of legacy cruft and requires a reliable ordered stream. A simple protocol based on Noise, like WireGuard, would be more suitable.
• The long-term key should be held in the RoT and should not be extractable by the SP. This ensures that the long-term key can only be used by an authorized SP that has authenticated to the RoT. However, the SP can probably be trusted with short-lived session keys, so whether session keys live on the SP or RoT can be determined by non-security factors (such as performance or implementation simplicity).
• The RoT should sign a document that includes the long-term key and a hash of the RoT’s measurements. The MGS can use this to display the firmware version and other information about the SP.
• If the protocol provides mutual authentication (again, like WireGuard does), Authenticate requests from MGS to the SP hubris#723 would be solved as well.
• The MGS’s authorized key should be included in the RoT’s measurements.