search

confidential-containers / trustee

Attestation and Secret Delivery Components
Apache License 2.0
56 stars 81 forks source link

New Architecture of Passport Mode. #306

Open jialez0 opened 7 months ago

jialez0 commented 7 months ago

Co-Author: @jialez0 @peterzcst @jiazhang0 @Xynnn007 @1570005763

Introduction

Currently, in the versions we have released, the use of "passport mode" still needs to be done through KBS. This is because we need to use KBS to provide a RESTful API interface for HTTPS and require the KBS protocol to pass public key and nonce. However, in recent renovations, our AS has gained the ability to independently provide RESTful APIs, and we have introduced the concept of runtime data to more flexibly pass public key and nonce. In addition, our CDH is gradually moving towards perfection.

Therefore, now our passport model can have a more elegant and flexible architecture, and this document comprehensively demonstrates how CDH, AA, AS, and KBS work together under the new architecture.

Architecture

image

What's new

  1. CDH becomes a confidential resource center in TEE. AA no longer undertakes the functions related to resources, but focuses on remote attestation.
  2. KBS and AS are separated in architecture, provide services independently, and have a clear division of labor.
  3. Highly modular, supports multi AS, and supports multi type resource servers (KBS, KMS...)

Implementation

We have completed some features and there are still some features under development.

AA

AS

KBS

CDH

cc @fitzthum

Xynnn007 commented 7 months ago

also cc @mkulke @bpradipt

mkulke commented 7 months ago

The proposed design looks like a good iteration on the current state of affairs (issuer KBS vs resource KBS). Would we still be able to build a consolidated KBS / AttestationService HTTP service (bg check)? This would be useful for simple CoCo deployments in tutorials and for development purposes.

fitzthum commented 6 months ago

Ok, this work has ended up being a little more complicated than I first expected. See this thread. I wonder if we want to reconvene the high-level discussion of the design.

This protocol is a crucial part of the project and I think we need to be really careful when we make changes, especially as more people join the project. In particular I think we need to have a very clear story about the relationship between AS token and KBS token and about the protocols for authenticating with the KBS and the AS.