AA: Expand AA APIs to support CC trusted APIs

[dongx1x]

Hello,

Confidential Computing (CC) API group defines unified and vendor agnostic and Trusted Computing Group (TCG) compliant CC trusted APIs, like Intel TDX, AMD SEV SNP, TPM, etc. It helps the diverse applications to access and process the trust states which were represented by integrity measurement, event record, and report/quote in the confidential computing environment.
The key CC trusted APIs include:

• get_cc_report: get a signed attestation report in a TEE, such as TDX Quote, TPM Quote, and AMD attestation report.
• get_cc_measurement: get the measurement registers in a TEE, such as TDX RTMRs, TPM PCRs, and AMD SEV SNP launcher measurement.
• get_cc_eventlog: get the recorded event logs in a TEE, which follow TCG specification and support Canonical Event Log (CEL).
• get_measurement_count: get the count of the measurement register.
• get_default_algorithm: get the default digest algorithms supported by a trusted foundation.
• replay_cc_eventlog: replay the event logs against measurement registers to prove the integrity of the event logs.

More information on these functions can be found here: https://github.com/cc-api/cc-trusted-api/blob/main/common/rust/cctrusted_base/src/api.rs

With these common APIs, the workload can easily get the measurements directly in a common interface in each kind of TEE, furthermore, within an Integrity Measurement Architecture (IMA) enabled system, the measurement can be used as evidence of a trusted chain for all applications. More information can be found in CCC Attestation SIG presentation or CCC TAG presentation.

AA has attestation interfaces for getting evidence, tokens, etc. CC APIs can be added as a trait in the same level as Attestation APIs, here is a proposal to expand AA APIs to support CC trusted APIs.

Comments are welcome!

[wenhuizhang]

Hi,
on top of cc-api, a ttrpc/grpc is preferred, and on top of ttrpc/grpc, a http/https/restful api is preferred.

so the whole flow might look like below:

cc-api --> grpc/ttrpc (attestation agent api layer one) --> http/https/restful api (attestation agent api layer two), then attestation agent api --> remote (in docker)/local(local binary) attestation service

In terms of interfaces, three interfaces are exposed to remote (in docker)/local(local binary) attestation service, 1. get eventlog; 2. get quote; 3, get measurement ; and maybe 4. get report, which equals get quote + replay&verify

[fitzthum]

I'm not sure I totally understand the proposal. Is the idea to have the AA expose this API to workload containers? That might be a non-starter. We need to be very careful about exposing evidence to containers, which aren't necessarily measured. It can be dangerous to expose valid hw evidence to unknown workloads, especially if the evidence is relatively generic.

The pattern for exposing the guest components to the workloads is to use the ASR. I'm not sure how that squares with this. Note that we already have an endpoint to expose attestation reports with this pattern. It is disabled by default. For platforms that support runtime measurement, the report usually contains these fields.

Can you be more clear about what we are missing that this proposal would enable? Btw it doesn't seem like this API has been very widely adopted.

[kenplusplus]

I'm not sure I totally understand the proposal. Is the idea to have the AA expose this API to workload containers? That might be a non-starter. We need to be very careful about exposing evidence to containers, which aren't necessarily measured. It can be dangerous to expose valid hw evidence to unknown workloads, especially if the evidence is relatively generic.

In our proposal, the AA will use the CC Trusted API and the AA can decide what should be exposed to containers. Could you please share what dangerous of hw evidence. Actually, workload can get all of these evidence without this API with proper permission. The evidences include launch time and runtime in a trusted chain according to TCG (Trusted Computing Group)'s requirement.

The pattern for exposing the guest components to the workloads is to use the ASR. I'm not sure how that squares with this. Note that we already have an endpoint to expose attestation reports with this pattern. It is disabled by default. For platforms that support runtime measurement, the report usually contains these fields.

What is ASR? (Sorry I did not find it in AA code, could you please share a little more)? We will not change any existing pattern, CC trusted API just to expose evidence by following existing AA pattern.

Can you be more clear about what we are missing that this proposal would enable? Btw it doesn't seem like this API has been very widely adopted.

This proposal is used to expose the launch + runtime evidences (aka event log) in unified API and follow TCG (Trust Computing Group) industrial standard. So it can simplify the AA to handle evidence collection and format like (PCClient/Canonical) on different TEEs and vTPM, like CCEL event log or TPM2 event log.

The APIs has been discussed in latest CCC attestation SIG meeting, (xiaosheng shared the video link), and the slide can be found https://github.com/CCC-Attestation/meetings/blob/main/materials/KenLu_CC_API.pdf
Although TCG has been there for many years, but concept of trustworthy has not widely understood by many people, I am working with some universities like UCLA to create trustworthy AIGC Hackson to advocate why trustworthy is so important for attestation and cloud native pipeline.