Base Attestation #1

New Issue

Open

opened 2025-09-09 02:13:29 +00:00 by ryan · 1 comment

ryan commented

2025-09-09 02:13:29 +00:00

Owner

Client initiates TLS session, proxied from TCP/IP to vsock, with bootproofd
Ensure TLS session is bound properly by performing TLS Channel Binding with EKM as userdata in attestation document, helps with MITM
Client should request data from a service it wants to connect to, such as a HTTPS certfp, or Keyfork signing key
Client can access third-party endpoint or long-lived key to validate attestation

* Client initiates TLS session, proxied from TCP/IP to vsock, with bootproofd * Ensure TLS session is bound properly by performing TLS Channel Binding with EKM as userdata in attestation document, helps with MITM * Client should request data from a service it wants to connect to, such as a HTTPS certfp, or Keyfork signing key * Client can access third-party endpoint or long-lived key to validate attestation

ryan commented

2025-09-21 01:29:16 +00:00

Author

Owner

Change up: Channel binding isn't necessarily a thing anymore because we do not need a secure channel, and are not using attestation to ensure the current channel is secure. New flow is:

Client initiates session with bootproofd (either directly, or by using enclaved as an HTTPS proxy for enclave services.
Client sends a keyfork-frame+cbor encoded nonce to bootproofd
bootproofd contacts all configured attestation providers and provides the nonce and any additionally configured userdata to be signed
bootproofd collects all attestations and returns them to the client
Client then verifies using some form of chain of trust

Expectations are:

Platform (AWS) verifies TPM
TPM verifies TDX/SEV/Nitro

The platform verification should be included as a bootproofd attestation provider.

Change up: Channel binding isn't necessarily a thing anymore because we do not need a secure channel, and are not using attestation to ensure the _current_ channel is secure. New flow is: * Client initiates session with bootproofd (either directly, or by using `enclaved` as an HTTPS proxy for enclave services. * Client sends a keyfork-frame+cbor encoded nonce to bootproofd * bootproofd contacts all configured attestation providers and provides the nonce and any additionally configured userdata to be signed * bootproofd collects all attestations and returns them to the client * Client then verifies using some form of chain of trust Expectations are: * Platform (AWS) verifies TPM * TPM verifies TDX/SEV/Nitro The platform verification should be included as a bootproofd attestation provider.

ryan added this to the Custody Framework project 2025-09-21 01:29:21 +00:00

ryan modified the project from Custody Framework to Verifiable Compute Platform

2025-09-21 01:29:39 +00:00

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/bootproof#1

No description provided.