sbellem
commented
3 years ago 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.
For demonstration purposes, it may be useful to clearly distinguish between the different phases:
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.