Separate the demo in multiple phases: key gen + sealing + quote gen, sign, verify

[sbellem]

For demonstration purposes, it may be useful to clearly distinguish between the different phases:

1. key generation, sealing, and quote generation (the quote is meant to include the public key)
2. remote attestation verification with Intel (IAS) -- extraction of public key
3. signature of data
4. verification of the signed data, with the public key extracted out of the IAS report

Instead of using the public key that is written to file (secp256r1.pem) file to verify the signature, the demo should use the public key from the report data.

The remote attestation part plays a key role to establish trust in the public key, meaning that the public key was generated in an genuine enclave, with specific characteristics such as MRENCLAVE and MRSIGNER.

[sbellem]

Let's containerize the server and client to make the distinction between the different tasks involved clearer.

The server is responsible for executing the enclave-based application, which includes both trusted and untrusted code:

• (trusted) key generation & sealing
• (trusted) creation of a cryptographic report of the enclave
• (untrusted) quote generation -- see Intel SGX Explained for an explanation of what a quote is
• (trusted) sign sensor data
• (untrusted) publish signed sensor data

The client's main goal is to verify that it is interacting with a genuine enclave which is executed some trusted source code.

• send a request for a quote to the untrusted app -- GET /quote
• send the quote to Intel (IAS)
• verify the authenticity of intel's response (check signature + certs) -- todo: link to docs
• verify that the MRENCLAVE in the verified report matches the trusted MRENCLAVE -- the trusted MRENCLAVE is established by re-building an enclave binary from the trusted source code
• if MRENCLAVEs match, extract the public key out of the report data
• subscribe to the (signed) data feed
• verify the signature of the data -- if it is valid, then trust the data

The first iteration of the prototype can use docker shared volumes for the communication between the server and client.
A second iteration could implement a tiny & lightweight python-based HTTP server, mainly serving two endpoints: GET /quote & GET /sensordata.