remote attestation protocols
2022-05-15 · 8 min read
See also: intel SGX > remote attestation
Related slides: CCC-Attestation/meetings - Discussion Wrap up
- An application running inside a Trusted Execution Environment (TEE) proves various assertions about itself to a remote party.
- These assertions might include claims like
- At the end of the attestation protocol, we should have a bidirectional secure channel established between both endpoints. We might use this channel to provision secrets, issue commands, etc...
Protocol Tradeoffs #
Quote Generation and Verification Frequency #
How often does the enclave need to generate a new quote?
Quote Generation #
- Once per connection
- Once on enclave startup
- TLS Embed Quote in Self-signed Certificate can generate an ephemeral cert once on startup and then serve it to all clients w/o changes.
Quote Verification #
- Once per connection.
- Amortize Quote verification so client only has to do it once.
RTTs to Useful Payload #
How many RTTs until the client can send useful application payloads?
- 1 RTT
- Normal TLS
- Embedded Quote TLS
- 2 RTT (extra application layer handshake step)
- TLS EKM Session Binding
- Is the protocol safe by default?
- How brittle/fail-safe is the protocol implementation?
Support for Client Authentication/Attestation #
- Can an enclave act as the client and present a Quote to the Server?
- Can two enclaves on the same machine efficiently verify each other's Reports?
- If built on TLS, can we do mutual-auth TLS (mTLS)?
Confidentiality vs Support Middleware #
- Most of the protocols terminate the secure channel inside the enclaves, which is by far the safest option, but means we have to forgo application-aware load balancers and reverse proxies, which have become standard in most cloud/kubernetes deployments.
- The Attestation in HTTP Headers HTTPA protocol presents an alternative, where the secure channel is moved up to the HTTP layer. The TLS session can be terminated at the service provider edge and existing middleware load balancers and reverse proxies can operate as normal on the unprotected parts of the HTTP request.
Different attestation protocols operate at different levels of the transport protocol stack and require varying changes to existing transport protocols. Invasiveness is a qualitative statement about the changes to existing libraries needed before a new client language can be supported.
As an upper bound, changing the TCP protocol handshake would be incredibly invasive and would likely require maintaining Linux kernel patches or running a custom user-space TCP stack. Supporting locked down platforms like Android or iOS would be... challenging to say the least.
In contrast, a hypothetical lower bound would probably be a default TLS config (i.e., no custom verifiers, no self-signed certs, default global CA set), since that would be supported "out-of-the-box" on every major platform.
TLS Configs by Invasiveness and Availability #
If you don't control the client libraries connecting to the enclaves, it's important to stay on the TLS happy path. Different platforms and client libraries allow configuring TLS to varying levels. Staying on the happy path is important for ease-of-implementation and time-to-market. TLS configurations in order from most to least easy/available:
- default configuration (available everywhere)
- This means the enclave needs a cert rooted at a global CA, e.g., Let's Encrypt.
- custom root CA cert (available everywhere, slightly more complicated)
- The client pins a specific root CA cert for this connection.
- The root CA cert is probably provisioned into the enclave out-of-band or provisioned with one of the other bespoke attestation protocols. Ideally, you can keep the provisioning step out of the steady-state client path or do it only once.
- export keying material (rare availability, if exists then only application layer changes)
- Used in TLS Exported Keying Material Session Binding. Requires a fresh Quote generated for every new TLS session.
- A KDF-like API over the negotiated TLS session shared secret. In other words, client and server can non-interactively derive identical secrets from the TLS session.
- Only ever seen this API exposed in
rustls. See: rustls::ClientConnection::export_keying_material.
- custom cert verifier, custom cert extensions (ok availability, dangerous and large engineering effort)
- Used in TLS Embed Quote in Self-signed Certificate.
- Requires completely replacing the existing cert verifier. Client code needs to be able to parse the X509 cert extensions containing the Quote.
- See: rustls::client::DangerousConfig::set_certificate_verifier
- See: mbedtls::ssl::Config::set_verify_callback
- modified TLS implementation (completely bespoke, requires standardization)
- Requires modifying the TLS handshake or core state machine.
- Non-starter for almost all projects.
- See: TLS CBOR Web Token CWT certs with Entity Attestation Token EAT
For a decent overview of lowest common denominator TLS configurations, see the Rust reqwest::ClientBuilder API. Take note of which APIs are supported on which TLS feature flags.
TLS Embed Quote in Self-signed Certificate #
- See: CCC-Attestation/meetings - RA-TLS slides
- See: gramineproject/gramine - RA-TLS mbedtls
- See: CCC-Attestation/meetings - OpenEnclave Attested TLS
- See: 2018 - Integrating Intel SGX Remote Attestation with TLS
TLS Exported Keying Material Session Binding #
Client and Server open a standard TLS connection, then derive a secret from the TLS session shared secret. The Client then requests a Quote from the Server. The Quote must bind to the derived shared secret or the Client will reject it. Once the Client verifies the Quote, you have a secure channel.
Delegate Quote Verification and Mint an X509 Cert for Enclave #
Attest CA Provisioning Enclave #
- Oasis (sort of)
Attestation in HTTP Headers (HTTPA) #
Most modern services are horizontally scaled and run behind a series of load balancers, reverse proxies, and TLS termination endpoints. These middleware services usually terminate TLS at the provider's edge and then inspect or operate on the HTTP request/response to route traffic, cache responses, check user authentication/authorization, track metrics, attach tracing info, etc, etc...
The other protocols described in this note will terminate the TLS session inside the destination enclave service. The security model is definitely clearest when terminating at the destination; however, we also lose out on all the functionality provided by these middlewares and must replicate or otherwise go without them in the enclave service.
In contrast, this proposal runs an attestation protocol over HTTPS in a standard TLS session, which can be terminated normally at the edge. Both parties effectively do a key exchange over HTTP headers. Once negotiated, parts of subsequent HTTP requests can be protected via the shared secrets. The middlewares can continue to operate on the unprotected parts of the HTTP request as normal.
- See: HTTPA/1.1: HTTPS Attestable Protocol
- See: HTTPA/2: a Trusted End-to-End Protocol for Web Services
- See: HTTPA - APNIC blog post
Enclave Key Exchange Protocol (EKEP) #
A modified version of Google's internal mutual-auth secure transport protocol (ALTS). Like a stripped down TLS handshake over gRPC.
- See: project-oak/oak - remote attestation
- See: asylo.dev - EKEP
- See: cloud.google.com - ALTS Handshake Protocol
TLS CBOR Web Token (CWT) certs with Entity Attestation Token (EAT) #
Normal TLS implementations usually exchange X509 certs. Some even support raw pubkey-only key exchange (no cert). This protocol proposes a new CWT cert format, along with an Entity Attestation Token (EAT) format inside the CWT cert.
Requires deeply invasive changes to TLS client libraries, who almost always assume X509 certs. Very far off the happy path IMO.