Open mythi opened 9 months ago
cc @sameo @slp @tylerfanelli @Lu-Biao
If 1 is agreed. We should also add Nonce endpint to CoCo-AS. cc @jialez0
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
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: https://github.com/mythi/guest-components/commit/7b97a8b6d0f53aa5b8b22c79e54892bef65e312a and #406)
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
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.
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 verified in sync. Current CoCo setup usessha384
hash for all TEEs and the nonce is from the KBS session. This fails with Intel trust authority that expectssha256
andsha512
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:
nonce
from the Attestation serviceThis focuses on 2.
Current RCAR handshake protocol
Request from Client to Server
Challenge from Server to Client:
Attestation from Client to Server
Response from Server to Client:
Suggested protocol changes
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 withoutsupported-hash-algorithms
param. Instead, a Challenge withoutselected-hash-algorithm
should be sent.