Add IDK_S PTA

[Sangho Lee (sangho2)]

This PR introduces the IDK_S PTA. It provides a method which endorses TA-provided data with a flat structure signed by an IDK_S key. A wire format is TA_DATA || REPORT (MAGIC, VERSION, TA_DATA_LEN, TA_UUID, ..., TA_SIGNING_CERT_DER) || SIGNATURE_PARAMS || SIGNATURE, where TA_DATA_LEN is an observed length of TA_DATA. All other values are from the LiteBox/PTA and SIGNATURE covers all except for itself.

[Sangho Lee (sangho2)]

TA_SIGNING_CERT_LEN and TA_SIGNING_CERT_DER are technically redundant if a TA is embedded because it isn't signed. However, for now, we do not make them optional.

[Sangho Lee (sangho2)]

Since a signed endorsement is just an appendix now, we don't have to copy the received TA data back to the output buffer if the TA concatenates these two by itself (performance optimization).

[thara-gopinath]

Isn't TA_DATA part of the endorsement claim in params1 ?

[Sangho Lee (sangho2)]

If we don't have MAGIC and VERSION prefix, this claim is technically fully decoupled from TA_DATA itself. TA can concatenate them. Anyhow, this is just perf optimization.

[thara-gopinath]

So.. I don't think we can have ta_data as the first element. It will be impossible to parse the claims structure. I propose MAGIC || VERSION || TA_DATA_LEN || TA_UUID || TA_SVN || TA_DIGEST ||
/// TA_DYNAMIC || DEBUG || ISOLATION_SOLUTION || TA_SIGNING_CERT_LEN ||
/// TA_SIGNING_CERT_DER || TA_DATA || SIGNATURE

Now I re-read the Attestation doc from EnS multiple times ! I think they are also looking for some kind of info on the signing cert (IDK_S) itself. Like the type of algorithm/ hash algorithm etc which makes sense so that we can switch to PQC later. The doc talks about following structure for this

""""
typedef struct _KEYISO_ATTESTATION_SIGNATURE_PARAMS
{
ULONG Magic; // KEYISO_ATTESTATION_SIGNATURE_PARAMS_MAGIC
ULONG Version; // KEYISO_ATTESTATION_SIGNATURE_PARAMS_CURRENT_VERSION
ULONG cbAlgID; // Length of algorithm identifier string
ULONG cbAlgPramas; // Length of algorithm parameters structure
ULONG cbHashAlg; // Length of hash algorithm name string
// UCHAR AlgID[cbAlgID] -- Algorithm name (e.g., "ECDSA_P384")
// UCHAR AlgParams[cbAlgPramas] -- Algorithm params (e.g., KEYISO_ATTESTATION_ECC_SIGNATURE_PARAMS)
// UCHAR HashAlg[cbHashAlg] -- Hash algorithm name (e.g., "SHA384") } KEYISO_ATTESTATION_SIGNATURE_PARAMS, * PKEYISO_ATTESTATION_SIGNATURE_PARAMS;

For LVBS, the IDKS key is an ECDSA P-384, so:
• AlgID: "ECDSA_P384"
• AlgParams: The ECC signature params structure KEYISO_ATTESTATION_ECC_SIGNATURE_PARAMS, contains only the Magic and Version - no additional parameters beyond the curve identified in AlgID.
• HashAlg: "SHA384"
"""""

But I am not sure if we want to follow a structure like this. Just defining the relevant fields might also suffice. Like char idk_alg_name[] and char idk_hash_name[] ? I don't know if these should be fixed length strings or we need to add fields to specify the size

[Sangho Lee (sangho2)]

• This change is based on the discussion with Dikla. My understanding is that, TA_DATA will internally has a length field to recognize its end.
• That's what our old commit implemented :) If we want to have them, it might be better to just use EnS's KeyIso structure, instead of inventing our own thing.

[thara-gopinath]

Do we need a field for ta_ digest size ?

[Sangho Lee (sangho2)]

For now, we only use SHA-256, whose length is fixed. it depends on whether we want to support other hash algorithms like SHA-384 and SHA-512.

[thara-gopinath]

I think we should add this . It is very possible that we want to support SHA-384 or SHA-512 later. The attestation verifier will have to change then

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.