KBS (protocol) enhancements to reportdata generation

[mythi]

The original case was reported in #162 triggered by my work on #159 and a bit of #151 too. This issue is an RFC proposal based on ideas I've prepared with @Xynnn007 to get CoCo attesters to generate quotes/reportdata in a generic way so that they can be made consumable by different AS backends.

The source of the problem is: hash(nonce || runtime data) and how to keep the attester vs verifier in sync. Current CoCo setup uses sha384 hash for all TEEs and the nonce is from the KBS session. This fails with Intel trust authority that expects sha256 and sha512 for SGX and TDX, respectively. IOW: CoCo attester generated evidence cannot be verified by Intel Trustauthority.

For this to work with non-CoCo attestation-services, two problems need to be sorted out:

1. it must be possible to seed nonce from the Attestation service
2. it must be possible to specify hash algorithm to be used by the attester.

This focuses on 2.

Current RCAR handshake protocol

1. Request from Client to Server

{
    "version": "0.1.0",
    "tee": "$tee",
    "extra-params": {}
}

2. Challenge from Server to Client:

{
    "nonce": "$nonce",
    "extra-params": {}
}

3. Attestation from Client to Server

{
    "tee-pubkey": "$pubkey",
    "tee-evidence": {}
}

4. Response from Server to Client:

{
    "protected": "$jose_header",
    "encrypted_key": "$encrypted_key",
    "iv": "$iv",
    "ciphertext": "$ciphertext",
    "tag": "$tag"
}

Suggested protocol changes

1. add an extra param "supported-hash-algorithms" to Request. This
   helps the client to tell the server what hash algorithms are supported.

{
    "version": "0.1.0",
    "tee": "$tee",
    "extra-params": {
        "supported-hash-algorithms": ["sha256", "sha384", "sha512"]
    }
}

2. add an extra param "selected-hash-algorithm" to Challenge. This
   tells the hash algorithm that the server selects from the ones that
   client supports.

{
    "nonce": "$nonce",
    "extra-params": {
        "selected-hash-algorithm": "sha512"
    }
}

In this way, the KBS could select the hash algorithm depending on the TEE type and attestation service used.

For forward compatibility, the server should NOT response a Challenge with
selected-hash-algorithm param when receiving a Request without supported-hash-algorithms param. Instead, a Challenge without selected-hash-algorithm should be sent.

Tasks

• kbs: ita: Set hash algorithm based on TEE type #491
• AA: kbs: Add supported hash algorithms to Request guest-components#712

[Xynnn007]

cc @sameo @slp @tylerfanelli @Lu-Biao

[Xynnn007]

If 1 is agreed. We should also add Nonce endpint to CoCo-AS. cc @jialez0

[Xynnn007]

btw, we need to raise a PR/issue in kbs-types repo to update the structure of both Challenge and Request, extending extra_params from String to HashMap or better serde_json::Value

[mythi]

We are going to start working on the implementation of the "suggested protocol changes" now that the kbs-types updates and the IBM SE refactoring are merged. Are there any objections?

I have verified that the hash algorithm negotiation is enough (see: mythi/guest-components@7b97a8b and #406)

[pawelpros]

It's worth mentioning that - azure VTPM has limitation for get signed quote from TPM which in theory should be supported up to 64 bytes (Sha256/Sha385/Sha512) but in real case the limitation is 50 bytes so Sha512 will not pass through

[mkulke]

It's worth mentioning that - azure VTPM has limitation for get signed quote from TPM which in theory should be supported up to 64 bytes (Sha256/Sha385/Sha512) but in real case the limitation is 50 bytes so Sha512 will not pass through

Note, this is a limitation in the tss API, since it uses a nonce buffer type that will be the size of the biggest hash algo available in a given TPM's PCR banks (which for azure vTPM is sha384) plus 2 additional header bytes (48 + 2). so, this limitation will most likely not be lifted anytime soon.