[FEATURE] Implement Mission Key Management (MKM) component

[podhrmic]

Summary

TODO: elaborate on this ticket

CONOPS

1. MKM is provisioned with two distinct mission keys (this can be during the disk image build time)
2. MKM boots, using the measured boot, but not the attestation
3. MKM awaits attestation requests from each component (MPS, and ideally the Autopilot as well)
4. upon receiving an attestation request, MKM performs attestation
5. if the attestation is successful, the attesting component is whitelisted
6. otherwise the component is blacklisted
7. MKM awaits key distribution requests - the keys are distributed only to the attested (whitelisted) components

Acceptance Criteria

(Define "done". Describe the desired outcome in specific enough terms for the assignee to decide when the issue is resolved)

Do

• CONOPS for the MKM
• detailed task description

[spernsteiner]

MKM awaits attestation requests from each component (MPS, and ideally the Autopilot as well)

Is it necessary to check the attestations up front, or would it be sufficient to check them on the fly when the key is requested? I'm thinking of a protocol like this:

1. Component sends a key request to the MKM
2. MKM responds with a challenge
3. Component obtains an attestation for that challenge and sends it to the MKM
4. MKM responds with the key

MKM awaits key distribution requests - the keys are distributed only to the attested (whitelisted) components

When sending the key, do we need the key to be encrypted in transit? Or can we assume that the communication channel between the component and the MKM is secure/trusted?

[spernsteiner]

Based on in-person discussion with @podhrmic today, we're planning to implement the simple protocol in the comment above. We're considering the network to be trusted for now, so we won't encrypt the keys when sending them to components. (This will be changed later when we move to an untrusted network and start using keys for encrypting data in transit between components, as opposed encrypting only data at rest such as logs.)

For the MKM implementation, we plan to implement it as a select/epoll-based server instead of fork/thread-per-connection, since the epoll version involves an explicit state machine for each connection that we can use to demonstrate CN's state machine verification capabilities.