Add Proxy Attestation example #1849

ipetr0v · 2021-01-27T12:59:10Z

This change adds Proxy Attestation example.
It consists of:

experimental/proxy_attestation: CA that can create signed certificates based on certificate signing requests
examples/proxy_attestation/client: Client that can request the CA root certificate and use it to connect to an Oak application
examples/proxy_attestation/module: Simple example Oak application

Certificate signing requests are created by oak_loader.

Fixes #1860
Ref #1374

ipetr0v · 2021-01-27T13:38:36Z

So looks like rust-openssl doesn't support WASM yet:

tiziano88 · 2021-01-27T13:43:28Z

Why are you trying to use SSL from Wasm?

ipetr0v · 2021-01-27T13:44:29Z

I needed a crate that could create x509 certificates based on a certificate request.

tiziano88 · 2021-01-27T13:45:10Z

But why in Wasm?

ipetr0v · 2021-01-27T13:45:58Z

Because we need to create it inside Oak (i.e. backend server sends Oak a certificate request, and Oak creates a corresponding certificate using its root key).
So Oak application works as a CA.

tiziano88 · 2021-01-27T13:52:11Z

That's not what I was expecting. The CA would be a separate stand-alone binary that has nothing to do with Oak. Its job is to verify remote attestation quotes, and sign certs based on that. The impl of the gRPC server pseudo node would obtain such signature from the CA enclave, and then start listening over gRPC using that cert. No Wasm is involved, and definitely no other Oak-specific functionality.

What is your plan instead?

ipetr0v · 2021-01-27T14:22:21Z

I thought the original idea was to make clients trust that the backend was attested and correct certificates were signed. And in order to enforce that, the CA and the attestor should be in Oak (or at least as a separate app in TEE), so they themselves could be remotely attestable (by clients).

And I tried to make it all in Wasm just to have a Proxy Attestation Service as an Oak application, and not making it a part of Runtime.

tiziano88 · 2021-01-27T14:25:38Z

I thought the original idea was to make clients trust that the backend was attested and correct certificates were signed. And in order to enforce that, the CA and the attestor should be in Oak (or at least as a separate app in TEE), so they themselves could be remotely attestable (by clients).

How would this make them remotely attestable? In fact I think this makes it impossible for a client to make sure that a particular application is actually running in Oak. And additionally, how would the application remotely attest to the CA? Even if it works, the layering of Oak runtime + Oak application seems completely unnecessary and overengineered, and makes the TCB of the CA massive. I thought we agreed that the solution should be minimal and independent of Oak.

ipetr0v · 2021-01-27T15:08:35Z

So neither the CA nor a backend app should use Oak, right?

Also, in the case when a backup application uses Oak, it would still need to create a certificate signing request (using something different from openssl-rust).

tiziano88 · 2021-01-27T15:28:58Z

So neither the CA nor a backend app should use Oak, right?

Correct. The goal is to have a proxy for remote attestation, no more, no less.

Also, in the case when a backup application uses Oak, it would still need to create a certificate signing request (using something different from openssl-rust).

I am not sure what you mean by "backup application", could you clarify?

ipetr0v · 2021-01-27T15:30:53Z

I am not sure what you mean by "backup application", could you clarify?

I have written "backup" instead of "backend" :^)
But basically, it's the application that wants to be attested by the proxy.

tiziano88 · 2021-01-27T15:38:24Z

The Oak loader will generate a cert / key, attest itself to the proxy, get its certificate signed by the proxy (which verifies the remote attestation claim with Intel / AMD, for instance), then use that cert / key to terminate TLS for the gRPC connection of a gRPC server pseudo-node.

This way a client connecting to the Oak loader (running any Oak application) would know that it is talking to a VM that has been remotely attested by the CA enclave. There is still the question of what exactly does the CA enclave do when signing the worker enclave cert, e.g. does it need to put the remote attestation quote in a special field, or does it store it locally, or something else?

ipetr0v · 2021-01-27T15:44:06Z

I don't think the quote should be stored by the Proxy, because after the attestation this quote is only needed by the client - to check that it's talking to a specific application that they intended to. So this quote should be in the TLS certificate used by the backend application.

Also, we probably don't even need a quote, because clients do not operate with backend TEE credentials (such as EPID remote attestation keys and etc.) of the backend application. In our case MRENCLAVE or Image Hash will be enough.

tiziano88 · 2021-01-27T15:48:51Z

I don't think the quote should be stored by the Proxy, because after the attestation this quote is only needed by the client - to check that it's talking to a specific application that they intended to. So this quote should be in the TLS certificate used by the backend application.

Yes, but now we need to find a field in the TLS cert to store it. BTW, have you looked at how Intel does this in SGX? I think we talked about the fact that we should try and be compatible with what they do, if at all possible.

Also, we probably don't even need a quote, because clients do not operate with backend TEE credentials (such as EPID remote attestation keys and etc.) of the backend application. In our case MRENCLAVE or Image Hash will be enough.

Why limit to a single field? Also I don't think it will be enough. For instance, a client may want to know the SGX version number, or whether the enclave is in debug mode, or anything else. We should just leave the quote as it is, and replace its signature with that of the CA enclave, which is also conceptually a simple operation. CA enclave gets a quote, checks the remote attestation signature, then throws it away and replaces it with its own signature.

conradgrobler · 2021-01-27T15:58:20Z

BTW, have you looked at how Intel does this in SGX?

FYI, I think this has quite a bit of detail on the topic: https://arxiv.org/pdf/1801.05863.pdf

tiziano88 · 2021-01-29T16:10:37Z

oak_loader/src/attestation.rs

+    let mut cert_name = X509NameBuilder::new()?;
+    // CN refers to Common Name.
+    // https://tools.ietf.org/html/rfc5280
+    cert_name.append_entry_by_text("CN", &get_tee_measurements())?;


What makes sure that this is putting a real measurement in this field? AFAICT this is completely unrelated to the actual attestation with the proxy, so why would anyone trust it?

The proxy will attest the backend and only sign a certificate that has a correct measurement in it.
But proxy probably should be the one who puts these measurements in the cert (in the end it will be identical cert).

Is it not possible for the CA enclave to add those fields and sign them in its part of the cert, instead of double checking them from the self-signed cert from the worker enclave?

examples/proxy_attestation/module/rust/build.rs

examples/proxy_attestation/client/rust/src/main.rs

experimental/proxy_attestation/src/certificate.rs

tiziano88 · 2021-02-02T21:47:37Z

experimental/proxy_attestation/src/certificate.rs

+const CERTIFICATE_EXPIRATION_INTERVAL_IN_DAYS: u32 = 1;
+const TEST_TEE_QUOTE: &str = "Test TEE quote";
+
+/// Placeholder function for collecting quotes of remotely attested TEEs.


Not sure I understand what quotes this function is supposed to collect. Do you mean it is expected to extract the quote from the remotely attested channel from which the TEE is connecting? If so, I guess this would have something related to the connection as parameter (even if unused for now). If it is really a top-level function with no param, then I think I completely misunderstand how it's supposed to work.

That's correct, TEE quotes will most likely be accessible from the gRPC connection.
But we will most likely not use tonic connection, since after implementing remote attestation we might drop tonic and use a custom gRPC library.
For now added a placeholder tonic::Request parameter.

experimental/proxy_attestation/proto/proxy_attestation.proto

tiziano88 · 2021-02-02T22:01:28Z

experimental/proxy_attestation/src/certificate.rs

+        let subject_alt_name = SubjectAlternativeName::new()
+            .dns("project-oak.local")
+            .dns("localhost")
+            .ip("127.0.0.1")
+            .ip("::1")
+            // `10.0.2.2` is routed to the host machine by the Android emulator.
+            .ip("10.0.2.2")
+            .build(&builder.x509v3_context(Some(&self.root_certificate), None))?;


Do these need to be the actual host names / IPs of the application?

Yes, otherwise tonic shows an error:

transport error: error trying to connect: invalid certificate: CertNotValidForName

Also, added a TODO(#1869) to load CSRs from PEM files (so we wouldn't need to hardcode IPs)