New Architecture of Passport Mode.

[jialez0]

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

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

• Support get_token API
• Support get token from CoCo-AS

AS

• Implement independent service programs and provide HTTPS based RESTful APIs
• Support GetNonce API and support nonce management

KBS

• /resource endpoint support verifying CoCo-AS token

CDH

• Add plugin to support access KMS
• Support get resource from KBS with CoCo-AS token
• Support configure KBS root certificate to enable HTTPS when access KBS.

cc @fitzthum

[Xynnn007]

also cc @mkulke @bpradipt

[mkulke]

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]

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.