[RFC] Runtime data spec

[jialez0]

Background

Currently, in many scenarios the runtime data is used to bind some runtime data in Attestation report, for example

• KBS protocol concats tee-pubkey and nonce together and use its hash as report data
• @KB5201314 proposed to embed I/O information [RFC] Combined Attestation for CoCo confidential-containers#176
• Data whose integrity needs to be protected in an evidence [Attestation Service] Change the API of CoCo-AS #240 (review)

The reason for using runtime data is to transmit the data generated or used by the TEE instance during its operation to external consumers through Attestation technology while ensuring integrity.

We can see that more and more information would be together be the so-called runtime data to bind with the TEE evidence.
The simple approach we used before, s.t. naive concatenation and hash would be more difficult to process structured information and difficult to generalize. Thus we propose the specification of runtime data.

The design goal of the runtime data spec is to standardize the runtime data format, calculation digest algorithm and usage process for different types of confidential computing TEE, and provide the best practical.

Runtime Data Spec

Report data support

Currently almost all TEE platforms support report data mechanism. https://github.com/confidential-containers/guest-components/blob/main/attestation-agent/attester/src/lib.rs#L61

Platform	Field name
SGX/TDX	REPORTDATA (64bytes)
SNP	report_datat(64bytes)
CCA	cca-realm-challenge(64bytes)
CSV	user_data(64bytes)

Usage of the Runtime Data

1. TEE instance builds runtime data at runtime and calculate runtime data digest.
2. TEE instance calls API driver to get attestation report using the runtime data digest as report data.
3. TEE instance initiates the RA process, and the Attestation Verifier calculates the digest of the runtime data and verifies whether it is consistent with the runtime data digest field in the evidence.

Runtime data spec

{
    "version": a string, specifies version of the runtime data,
    "alg": a string, hash algorithm to calculate the runtime data digest,
    "data": an JSON object, including compound data,
    "digest": a string, digest of "data" in hex derived using "alg"
}

Runtime data digest calculation

Rearrange each layer of the data JSON object in dictionary order by key, then serialize and output it into a compact string, and perform hash calculation on the whole.

The rearrange is important. It can ensure the hash inputs are the same.

How to deliver runtime data

This spec does not define this.

Examples

Usage in KBS protocol

Current RCAR protocol defines the following Attestation request.

{
    /*
     * A JWK-formatted public key, generated by the KBC running in the HW-TEE.
     * It is valid until the next time an attestation is required. Its hash must
     * be included in the HW-TEE evidence and signed by the HW-TEE hardware.
     */
    "tee-pubkey": $pubkey

    /* The attestation evidence. Its format is specified by Attestation-Service. */
    "tee-evidence": {}
}

A typical tdx Attestation request looks like

{
    "tee-pubkey": "AAAAA",
    "tee-evidence": {
        "cc_eventlog": "AAAAA",
        "quote": "BAAC"
    }
}

After applying runtime data spec, it would be

{
	"evidence": {
		"cc_eventlog": "AAAAA",
		"quote": "BAAC"
	},
	"runtime-data": {
		"version": "v0.1.0",
		"alg": "sha384",
		"data": {
			"tee-pubkey": "AAAAA",
			"nonce": "AAAAA",
		},
		"digest": "0a96dc5bbf0b6c0e0db6c83db8f59013e9817ecf47c1c5bf8c1c17e7e3831d00d7180d32f2294ce22a4ba0b39fbf3fbe"
	}
}

The digest is calculated by sha384 the string {"nonce":"AAAAA","tee-pubkey":"AAAAA"}.

[fitzthum]

This looks good. The layout looks similar to the InitData proposal. Do you think it would make any sense to use the same format for both?

[mythi]

Thanks a lot for triggering this proposal! I have two opens:

1. how the AS used by KBS gets to provide inputs to this? Related: KBS (protocol) enhancements to reportdata generation #242
2. with this, we plan to move the report data generation away from the RCAR protocol into attesters?

The digest is calculated by sha384 the string {"nonce":"AAAAA","tee-pubkey":"AAAAA"}.

what would be the way to express: hash( "AAAAA" || "AAAAA") instead?