Remote attestation and secure channel of communication

[JamesMenetrey]

Dear WAMR developers,

First, I would like to thank you for integrating librats in the runtime.

When checking the related sample for remote attestation, it looks like the Wasm application may supply a random hash, from which it creates evidence. From my understanding, this evidence is then forwarded to another enclave, which is or is not located on the same system, for verification.

Using your API, I would like to establish a secure communication channel between two enclaves. Usually, we bind a public key with the quote, so the other party knows that the public key originated from a genuine enclave, using a given code measurement.

The only way I have imagined doing it with WAMR would be to generate a public key, hash it and uses that hash to generate the evidence. Afterwards, the third party needs to verify whether the evidence and if trustworthy, extract the code measurement (to check any tampering), and verify that the hash of the received public key matches the hash embedded in the quote.

Nonetheless, I'm wondering whether manually parsing the evidence to extract the code measurement and hash is a good practice.

How did you initially design that WAMR extension to bootstrap a secure communication channel with this API?

Thanks!
Jämes

[JamesMenetrey]

Hello @zeuson0,

I have seen you have been pinged in issue #1670, so your input would be of great help here as well. :)

Thanks!

[zeuson0]

Good question! It makes me realize that my Implementation of librats for wamr is incomplete. Firstly, I would add an input like mrenclave to verify the enclave measurement in the function librats_verify。Furthermore, enclave measurement can only verify the integrity of iwasm, but the integrity of the wasm module also needs to be considered. The establishment of a secure channel should be considered only if both are verified to be untampered. The solution to this problem is to change the function librats_collect to put the wasm module's measurement into the quote automatically.

If the problems above are all solved, you still need to implement the protocol to bootstrap a secure communication channel yourself for the time being because the librats-based TLS protocol rats-tls has not been completed yet. When rats-tls is finished, I will port it to wamr as soon as possible.

[JamesMenetrey]

Thanks for your response! Indeed, I also think this is essential that the RA extension also measures the wasm module, otherwise, anyone can run arbitrary code inside an enclave with a valid quote. Some suggestions of input to check (that come from here):

• check the MRENCLAVE as you have said,
• check the MRSIGNER as we may be interested in verifying the author,
• control the security version and the product ID of the enclave,
• examine whether the debug attribute is present or not.

Regarding the bootstrapping of the secure channel, I have a better understanding now. I think we can live without it for the time being, since we can do it manually.

Do you plan to work on the measurement of the wasm module in the near future, or is it something we should promote to other contributors?

Thanks!

FYI @wenyongh

[zeuson0]

Yes, you are right. I will take your suggestions. Does it meet your needs if I add a callback function that could choose to verify these values as the input of the function librats_verify ?

Following is the declaration of the function:

typedef int(*librats_verify_callback_t)(void* evidence); // We will define the struct of evidence

int librats_verify(const char *evidence_json, const uint8_t *hash, librats_verify_callback_t callback);

[JamesMenetrey]

Either a callback or librats_verify may fill a pointer of the evidence structure so that the user code can interact with it directly. For example:

int librats_verify(const char *evidence_json, const uint8_t *hash, void* evidence);  // We will define the struct of evidence

What do you think?

[zeuson0]

I think both are similar solutions. I would choose one that is easier to implement.

[JamesMenetrey]

Solved by @zeuson0 in #1695.