Remote Attestation and Remote Control wiki page about sgx-lkl HOT 4 CLOSED

Hi Dmitrii,

thanks a lot for your comments/questions. I'll try to reply to them now and then also update the wiki to make things clearer.

1. Yes, they are under the control of the OS. The idea should be that the nonce is provided to whoever launches the enclave externally though and gives you a guarantee that when you receive a report with the nonce attached that it's fresh and not a quote/report that has been generated previously for an already running enclave. How that nonce is provided to the untrusted host (maybe it's a VM under your own control, maybe it's a cloud provider that launches the enclave for you and has some API for it) is out of scope of SGX-LKL itself I would say.

2. Yes, your understanding is correct! The key pair is generated inside the enclave on startup. Only the public key is attached to the report. Same as with RA-TLS.

3. Yes, Wireguard is part of the kernel (LKL). Currently we patch the kernel sources to include it, but it has been proposed for inclusion in the Linux kernel for a while, so in the long term it will be part of the kernel and with that of LKL, so we won't even have to do that. There is no need to make any changes to the application.

4. Wireguard is not TLS, it's a separate protocol (see https://www.wireguard.com). In general, there TLS is not required at all with SGX-LKL. Of course, if your application uses TLS that's possible too. You are right that it's a multi-step process, but it's actually the other way around. First, the quote (or attestation verification report) is retrieved and verified, then the connection/VPN is established by adding the enclave's public Wireguard key to the local Wireguard device.

There were a number of reasons for choosing Wireguard and this multi-step process:

1. Wireguard is part of the kernel (or rather will be soon) and therefore is already available to us as part of LKL.
2. It's layer 3 which means SGX-LKL can protect network traffic for any transport layer protocol including TCP and UDP.
3. SGX-LKL can protect the confidentiality of applications running in top of it. In order to that, you first provide an encrypted/integrity-protected disk image to SGX-LKL at startup. Then you retrieve the quote and do the remote attestation and establish a secure channel, and only then you provide the enclave with a disk encryption key and application arguments. At the time of attestation, the application itself might not even run yet. Keep in mind that executables are loaded by SGX-LKL at runtime and are not part of the enclave measurement.

That said, if you only care about the integrity of your executable, it would definitely be good to have a way of starting an application right away and then proving it's integrity as part of the remote attestation process, e.g. by including the root hash of the disk image in the report data. Right now, that's not yet supported.

I guess the above also outlines the differences to RA-TLS. Do those points make sense?

I'm also adding a sequence diagram to the Wiki page (https://github.com/lsds/sgx-lkl/wiki/Remote-Attestation-and-Remote-Control). Let us know if anything is unclear or you have any other questions!

from sgx-lkl.

Thanks for quick and informative replies, Christian!

I should have first read about WireGuard, sorry. I assumed it's similar to OpenVPN, but now I understand it much better (very cool stuff!).

I also misunderstood the idea of the nonce. In your case, the nonce is generated by and/or known to the verifier (client) beforehand, so the attacker changing the nonce to old/random value has a consequence of the client rejecting the communication with such a manipulated server (because the expected-by-client nonce is different from the received one).

Do I understand correctly that your WireGuard-based RA solution doesn't rely on X.509 and PKI at all? (Apart from talking to IAS which happens over the normal TLS+X.509 protocol.) It seems that you only need to embed the server's public key + nonce into the SGX quote, send it to the client, who verifies the SGX quote and enclave measurements and finally establishes a WireGuard connection using the extracted server's public key.

This is a very interesting approach, and quite different from RA-TLS (which has the primary goal of working on top of existing TLS code of server/client with minimal changes). I hope to see the paper soon :)

from sgx-lkl.

Yes, that's all correct :) Right now it also relies on the fact that it will accept exactly one Wireguard peer configuration at startup in release mode. That means you provide the trusted client's public key at startup. Then, after attestation, with the enclave's public key you try to establish a secure connection. If you can, you can be sure that you are the only one that is able to talk to the enclave at that point. You can then add additional peers, or of course if your application needs to be accessible by many other hosts and it has support for TLS (e.g. a webserver) still use TLS for the application itself.

from sgx-lkl.

Thanks for informative replies, closing this issue.

from sgx-lkl.