https://github.com/pluto/caratls
https://github.com/pluto/caratls
Last synced: about 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/pluto/caratls
- Owner: pluto
- License: apache-2.0
- Created: 2024-12-07T05:26:28.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-02-07T22:26:36.000Z (over 1 year ago)
- Last Synced: 2025-02-07T22:30:32.733Z (over 1 year ago)
- Language: Rust
- Size: 42 KB
- Stars: 8
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# caratls
## WORK IN PROGRESS
**tldr**: caratls (Certificate Authority trusted Remote Attestation TLS) lets a browser connect directly to a TEE using a Root CA-signed certificate (e.g., from Let's Encrypt), then encapsulates a second TLS session inside the outer session. This inner TLS session is bootstrapped with TEE-generated self-signed certificates and supports channel binding, ensuring strong trust with the TEE even if the outer certificate is compromised.
```
Outer TLS session trusted by Root CA (ie Let's Encrypt)
..encapsulates TLS session with TEE bootstrapped self-signed certificate
...verifies TEE attestation token inline
...use TlsStream> for regular client/server comms
```
## Motivation
- **Direct Browser Compatibility**: Browsers only trust CA-signed certificates by default. Hence, we first establish a standard HTTPS/WSS connection using a Let's Encrypt certificate.
- **TEE Bootstrapping**: Once the outer TLS session is set up, we initiate an inner TLS session with self-signed, TEE-generated keys. This inner session includes remote attestation to verify the TEE identity.
- **Secure "Inner" TLS**: If the outer certificate is compromised or reused across multiple TEEs, the inner session still provides end-to-end security anchored in the TEE.
- **Scalability**: Managing a single CA-signed cert per domain (e.g., `api.example.com`) avoids [Let's Encrypt rate-limit issues](https://letsencrypt.org/docs/rate-limits/) and complicated certificate distribution across many TEEs.
## Concept
1. **Outer TLS**
- Negotiated using a Let's Encrypt cert (or any other Root CA-signed certificate).
- Allows standard HTTPS/WSS connections from browsers.
2. **Inner TLS**
- Encapsulated inside the outer TLS stream (`TlsStream>`).
- Uses self-signed, TEE-bootstrapped certificates.
- Performs channel binding (EKM or key attestation) to prove the session is securely terminated in the TEE.
3. **TEE Attestation**
- Verified inline during the inner TLS handshake.
- Confirms the TEE’s authenticity and ties it to the self-signed cert.
## Approaches
- **EKM-Based**:
The TEE attestation includes an Extracted Key Material (EKM) nonce derived from the inner TLS handshake, thereby binding the attestation to that specific session.
- **Key Attestation**:
The TEE directly attests the ephemeral key used in the inner TLS session, typically by signing the public key or embedding it in the TEE's quote/report.
Both approaches ensure a strong channel binding between the TEE and the client.
Currently this crate only implements an EKM-based approach for Google Confidential Space.
## Usage
```rust
// Server/ TEE side
let token_generator = DummyTokenGenerator::new()
let tee_tls_acceptor = TeeTlsAcceptor::new(token_generator, ...);
let tee_tls_stream = tee_tls_acceptor.accept(tls_stream).await?;
// Client side
let token_verifier = DummyTokenVerifier::new()
let tee_tls_connector = TeeTlsConnector::new(token_verifier, ...);
let tee_tls_stream = tee_tls_connector.connect(tls_stream).await?;
```
The `tls_stream` in both cases is already an outer TLS connection (e.g., from Let's Encrypt) which then encapsulates the secure TEE-bootstrapped inner TLS connection.
## Development
caratls is organized into multiple crates:
* `server & client`: Split for better dependency control (e.g., WASM/iOS target support on the client side).
* `ekm` and `key`: Different crates implement either EKM-based or Key-Attestation based channel binding.