[Attestation Service] Change the API of CoCo-AS

Cargo.toml

@@ -26,6 +26,7 @@ cfg-if = "1.0.0"
 chrono = "0.4.19"
 clap = { version = "4", features = ["derive"] }
 env_logger = "0.10.0"
+hex = "0.4.3"
 kbs-types.path = "attestation-service/as-types"
 log = "0.4.17"
 prost = "0.11.0"

attestation-service/README.md

@@ -1,18 +1,20 @@
 # Attestation Service
 
-Attestation Service (AS for short) is a general function set that can verify TEE evidence.
+Attestation Service (AS for short, also known as CoCo-AS) is a general function set that can verify TEE evidence.
 With Confidential Containers, the attestation service must run in an secure environment, outside of the guest node.
 
-With remote attestation, Attesters (e.g. the [Attestation Agent](https://github.com/confidential-containers/attestation-agent)) running on the guest node will request a resource (e.g. a container image decryption key) from the [Key Broker Service (KBS)](https://github.com/confidential-containers/kbs)).
+With remote attestation, Attesters (e.g. the [Attestation Agent](https://github.com/confidential-containers/guest-components/tree/main/attestation-agent)) running on the guest node will request a resource (e.g. a container image decryption key) from the [Key Broker Service (KBS)](https://github.com/confidential-containers/kbs).
 The KBS receives the attestation evidence from the client in TEE and forwards it to the Attestation Service (AS). The AS role is to verify the attestation evidence and provide Attestation Results token back to the KBS. Verifying the evidence is a two steps process:
 
 1. Verify the evidence signature, and assess that it's been signed with a trusted key of TEE.
 2. Verify that the TCB described by that evidence (including hardware status and software measurements) meets the guest owner expectations.
 
 Those two steps are accomplished by respectively one of the [Verifier Drivers](#verifier-drivers) and the AS [Policy Engine](#policy-engine). The policy engine can be customized with different policy configurations.
 
+In addition, CoCo-AS can also run independently as a remote attestation service which receives TEE evidence and returns the verification results as a token.
+
 The AS can be built as a library (i.e. a Rust crate) by other confidential computing resources providers, like for example the KBS.
-It can also run as a standalone binary, in which case its API is exposed through a set of [gRPC](https://grpc.io/) endpoints.
+It can also run as a standalone binary, which exposes APIs in gRPC way.
 
 # Components
 
@@ -23,7 +25,7 @@ The AS can be built and imported as a Rust crate into any project providing atte
 As the AS API is not yet fully stable, the AS crate needs to be imported from GitHub directly:
 
 ```toml
-attestation-service = { git = "https://github.com/confidential-containers/attestation-service", branch = "main" }
+attestation-service = { git = "https://github.com/confidential-containers/kbs", branch = "main" }
 ```
 
 ## Server
@@ -37,8 +39,8 @@ This project provides the Attestation Service binary program that can be run as
 Build and install AS components:
 
 ```shell
-git clone https://github.com/confidential-containers/attestation-service
-cd attestation-service
+git clone https://github.com/confidential-containers/kbs
+cd kbs/attestation-service
 make && make install
 ```
 
@@ -68,24 +70,13 @@ please refer to [the doc](./rvps/README.md#run-mode) for more details.
 
 ### Evidence format:
 
-The attestation evidence is included in a [KBS defined Attestation payload](../kbs/docs/kbs_attestation_protocol.md#attestation):
-
-```json
-{
-    "tee-pubkey": $pubkey,
-    "tee-evidence": {}
-}
-```
-
-- `tee-pubkey`: A JWK-formatted public key, generated by the client running in the HW-TEE.
-For more details on the `tee-pubkey` format, see the [KBS protocol](../kbs/docs/kbs_attestation_protocol.md#key-format).
-
-- `tee-evidence`: The attestation evidence generated by the HW-TEE platform software and hardware in the AA's execution environment.
-The tee-evidence formats depend on the TEE and are typically defined by the each TEE verifier driver of AS.
-
-**Note**: Verification Demander needs to specify the TEE type and pass `nonce` to Attestation-Service together with Evidence,
-Hash of `nonce` and `tee-pubkey` should be embedded in report/quote in `tee-evidence`, so they can be signed by HW-TEE.
-This mechanism ensures the freshness of Evidence and the authenticity of `tee-pubkey`.
+The evidence format is different from TEE to TEE. Please refer to the concrete code definition for the specified format.
+- Intel TDX: [TdxEvidence](./verifier/src/tdx/mod.rs)
+- Intel SGX: [SgxEvidence](./verifier/src/sgx/mod.rs)
+- AMD SNP: [SnpEvidence](./verifier/src/snp/mod.rs)
+- Azure SNP vTPM: [Evidence](./verifier/src/az_snp_vtpm/mod.rs)
+- Arm CCA: [CcaEvidence](./verifier/src/cca/mod.rs)
+- Hygon CSV: [CsvEvidence](./verifier/src/csv/mod.rs)
 
 ### Attestation Results Token:
 
@@ -99,31 +90,34 @@ Claims format of the attestation results token is:
 ```json
 {
     "iss": $issuer_name,
-    "jwk": $public_key,
+    "jwk": $public_key_used_to_sign_the_token,
     "exp": $expire_timestamp,
     "nbf": $notbefore_timestamp,
-    "tee-pubkey": $pubkey,
+    "policy-ids": $policy_ids_used_to_verify_the_evidence,
     "tcb-status": $parsed_evidence,
-    "evaluation-report": $report
+    "evaluation-reports": $reports_of_every_policy_specified,
+    "reference-data": $reference_data_used_to_check,
+    "customized_claims": $customized_claims,
 }
 ```
 
 * `iss`: Token issuer name, default is `CoCo-Attestation-Service`.
 * `jwk`: Public key to verify token signature. Must be in format of [JSON Web Key](https://datatracker.ietf.org/doc/html/rfc7517).
 * `exp`: Token expire time in Unix timestamp format.
 * `nbf`: Token effective time in Unix timestamp format.
-* `tee-pubkey`: A JWK-formatted public key, generated by the client running in the HW-TEE.
-For more details on the `tee-pubkey` format, see the [KBS protocol](../kbs/docs/kbs_attestation_protocol.md#key-format).
 * `tcb_status`: Contains HW-TEE informations and software measurements of AA's execution environment. The format is in the [doc](./docs/parsed_claims.md).
-* `evaluation-report` : The output of the policy engine, it is AS policy's evaluation opinion on TEE evidence.
+* `policy-ids`: The OPA policy ids used to verify the evidence.
+* `evaluation-reports` : The outputs of the policy engine, they are AS policies' evaluation opinion on TEE evidence.
+* `reference-data`: Reference values in a map used to enforce the OPA policy.
+* `customized_claims`: Customized claims whose integrity is protected by binding its digest into the evidence. It will be a JSON map.
 
 ## Verifier Drivers
 
-A verifier driver parse the HW-TEE specific `tee-evidence` data from the received attestation evidence, and performs the following tasks:
+A verifier driver parse the HW-TEE specific attestation evidence, and performs the following tasks:
 
-1. Verify HW-TEE hardware signature of the TEE quote/report in `tee-evidence`.
+1. Verify HW-TEE hardware signature of the TEE quote/report in the evidence.
 
-2. Resolve `tee-evidence`, and organize the TCB status into JSON claims to return.
+2. Resolve the evidence, and organize the TCB status into JSON claims to return.
 
 Supported Verifier Drivers:
 

attestation-service/attestation-service/Cargo.toml

@@ -24,6 +24,7 @@ async-trait.workspace = true
 base64 = "0.21"
 cfg-if = "1.0.0"
 futures = "0.3.17"
+hex.workspace = true
 # TODO: change it to "0.5", once released.
 kbs-types = { git = "https://github.com/virtee/kbs-types", rev = "c90df0e" }
 lazy_static = "1.4.0"
@@ -51,6 +52,7 @@ tonic-build.workspace = true
 
 [dev-dependencies]
 assert-json-diff.workspace = true
+hex.workspace = true
 rstest.workspace = true
 serial_test.workspace = true
 sha2.workspace = true