[Teep] [Hackathon 3/3] Implementation experience: bootstrapping trust in TEEP Agent keys using attestation

[Ken Takayama <[e-mail]>]

Dear TEEP WG,

In a previous message I shared some general observations about
error handling in TEEP implementations.

In this message I would like to share a more specific implementation
experience related to attestation-based bootstrap when TEEP Agent
keys are trusted only after successful remote attestation.

While this is only one possible deployment model, we found that
some practical issues arise when combining TEEP-over-HTTP with
remote attestation.

Our TAM implementation is available at:
https://github.com/kentakayama/AttesTAM

Our end-to-end (TEEP Agent - TAM - Verifier) demonstration will be available at:
https://github.com/s-miyazawa/teep-wasm-demo

----------------------------------------------------------------------
Background: Attestation-based bootstrap in our implementation
----------------------------------------------------------------------

In our implementation, we used the Background Check Model and
performed remote attestation within the TEEP Protocol in order
for **the TAM to establish trust in the TEEP Agent’s public key**.

The initial bootstrap flow is summarized as follows:

0. Preparation:
   The TEEP Agent is provisioned with the TAM public key
   (or a trust anchor for the TAM certificate).
   The Verifier is provisioned with reference measurements
   including the TEEP Agent.

1. Agent start:
   The TEEP Agent starts inside the TEE and generates its own
   signing key pair inside the TEE.
   This key is not yet trusted by the TAM.

2. Session initiation:
   The TEEP Agent POSTs an empty message to the TAM over TEEP/HTTP.

3. QueryRequest from TAM:
   The TAM returns a signed QueryRequest with a challenge and
   with the attestation bit set in data-item-requested.

4. Evidence generation:
   The Agent verifies the QueryRequest using the TAM public key
   and requests the TEE to generate Evidence using an attestation key.

   The Evidence binds:
     - the TEEP Agent public key
     - the received challenge

5. QueryResponse from Agent:
   The Agent returns a signed QueryResponse containing the Evidence
   in the attestation-payload.

6. Verification:
   The TAM parses the message, sends the Evidence to the Verifier,
   verifies the QueryResponse signature using the attested key,
   checks the challenge and its freshness, and then stores the
   Agent public key as trusted.

7. Completion:
   The TAM returns an empty response (HTTP 204).

This is one possible profile and does not intend to restrict
other deployment models.

----------------------------------------------------------------------
Implementation note: bootstrap behavior when attestation is used
----------------------------------------------------------------------

In deployments where remote attestation is used to establish trust
in the TEEP Agent public key, attestation operations may be relatively
expensive both computationally and operationally.

If the TAM requests attestation every time the Agent initiates a
connection, Evidence generation and verification may occur more often
than necessary.

During implementation we experimented with the following bootstrap
pattern.

1. When the Agent initiates a connection with an empty message,
   the TAM first returns a QueryRequest containing a token and
   requesting information such as the trusted component list
   (without requesting attestation).

2. The Agent responds with a QueryResponse containing the requested
   information.

3. Since the Agent public key is not yet trusted, the TAM cannot
   verify the response and then proceeds to send a QueryRequest
   requesting attestation with a challenge.

This approach introduces one additional round trip during bootstrap,
but it allows the TAM to avoid requesting attestation unnecessarily
on every connection.

This is only an example implementation pattern discovered during
our implementation work and does not change the protocol semantics.
Other deployment models may choose different approaches.

----------------------------------------------------------------------
Note
----------------------------------------------------------------------

In our prototype implementation the Evidence is currently generated
using a simplified EAT-based format rather than a hardware-generated
SGX Quote.

However, the structure follows the same design pattern used in
hardware attestation systems: binding the Agent public key and
a freshness value (challenge/nonce) to the measured state of the
TEEP Agent.


Best regards,
Ken