mirror of https://github.com/edgelesssys/constellation.git synced 2024-10-01 01:36:09 -04:00

History

Markus Rudy c020f7ac20 cleanup: various minor debugging improvements (#2889 ) * ci: improve constellation_create error message When we hit a timeout due to nodes not coming up, the actual error message is hard to make out because it's buried in a group. With the right formatting, the error message will be highlighted in the UI. Another improvement is to output the state of nodes, which helps debugging the cause of nodes not joining or not becoming ready. * cleanup: use NodeVersionResourceName constant ... instead of literal strings. * ci: correctly notify on e2e upgrade error * atls: report cert extension OIDs on mismatch If the certificate contains an attestation document for SEV-SNP, but the given validator is for Nitro, verifyEmbeddedReport should not claim that there is no attestation document, but that there is no _compatible_ one and what the incompatible ones were.		2024-02-02 16:46:28 +01:00
..
atls_test.go	goleak: ignore rules_go SIGTERM handler	2024-01-22 13:11:58 +01:00
atls.go	cleanup: various minor debugging improvements (#2889 )	2024-02-02 16:46:28 +01:00
BUILD.bazel	attestation: add `awsSEVSNP` as new variant (#1900 )	2023-06-09 15:41:02 +02:00
README.md	attestation: add `awsSEVSNP` as new variant (#1900 )	2023-06-09 15:41:02 +02:00

README.md

Attested TLS (aTLS)

In a confidential computing (CC) environment, attested TLS (aTLS) can be used to establish secure connections between two parties utilizing the remote attestation features of the CC components.

aTLS modifies the TLS handshake by embedding an attestation statement into the TLS certificate. Instead of relying on a Certificate Authority, aTLS uses this attestation statement to establish trust in the certificate.

The protocol can be used by clients to verify a server certificate, by a server to verify a client certificate, or for mutual verification (mutual aTLS).

Client side verification

The client sends a ClientHello message, setting ServerName to a random nonce.
The server generates an attestation statement using the clients nonce and its CC capabilities.
- The attestation is embedded in the server certificate using x509 certificate extensions with an object identifier (OID) to identify the CC attestation type. Take a look at the variant package for implementation details.
The client verifies the attestation statement.
If successful the client can trust the server to be running the expected configuration, and finish the TLS handshake.

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello(nonce)
    Server->>Client: ServerCertificate(AttestationStatement), ServerHelloDone
    Note over Client: Verify Attestation
    Client->>Server: ClientKeyExchange
    Client->>Server: ChangeCipherSpec, Finished
    Server->>Client: #

Server side verification

The client sends a ClientHello message
The server sends back a certificate and a random nonce. The nonce is encoded as the Distinguished Name of an acceptable CA.
The client does not verify the servers certificate, but uses the nonce to generate an attestation based on its CC capabilities.
- The attestation is embedded in the client certificate using x509 certificate extensions with an OID to identify the CC attestation type.
The server verifies the client's attestation statement.
If successful the server can trust the client to be running the expected configuration, and finish the TLS handshake.

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello
    Server->>Client: ServerCertificate, AcceptableCAs(nonce), ServerHelloDone
    Client->>Server: ClientKeyExchange, ClientCertificate(AttestationStatement)
    Client->>Server: ChangeCipherSpec, Finished
    Note over Server: Verify Attestation
    Server->>Client: ChangeCipherSpec, Finished

Mutual aTLS

The client sends a ClientHello message, setting ServerName to a random nonce.
The server generates an attestation statement using the clients nonce and its CC capabilities.
- The attestation is embedded in the server certificate using x509 certificate extensions with an OID to identify the attestation type.
- A nonce is encoded as the Distinguished Name of an acceptable CA.
The client verifies the attestation statement.
The client uses the nonce to generate an attestation based on its CC capabilities.
- The attestation is embedded in the client certificate using x509 certificate extensions with an OID to identify the CC attestation type.
The server verifies the client's attestation statement.
If all verifications were successful, mutual trust in each others configuration is established, and the TLS handshake can be finished.

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: ClientHello(nonce)
    Server->>Client: ServerCertificate(AttestationStatement), AcceptableCAs(nonce), ServerHelloDone
    Note over Client: Verify Attestation
    Client->>Server: ClientKeyExchange, ClientCertificate(AttestationStatement)
    Client->>Server: ChangeCipherSpec, Finished
    Note over Server: Verify Attestation
    Server->>Client: ChangeCipherSpec, Finished