Add IDK_S PTA - #1026
Add IDK_S PTA#1026Sangho Lee (sangho2) wants to merge 16 commits into
Conversation
7850306 to
6955223
Compare
6031f3c to
c172e8a
Compare
91e4c3a to
205a633
Compare
054e1c6 to
420f007
Compare
e5a3e08 to
65a67fb
Compare
65a67fb to
d531256
Compare
300e832 to
1cb91e6
Compare
d531256 to
02010a7
Compare
Sangho Lee (sangho2)
added
the
must-not-merge:prototype
1cb91e6 to
c9a77f6
Compare
bdd2a3a to
03cf03e
Compare
b1df4fd to
81667ad
Compare
03cf03e to
26430d6
Compare
26430d6 to
fa0aeb2
Compare
131b31e to
4443bb6
Compare
9340001 to
019ad24
Compare
84e3837 to
a0f8f03
Compare
|
|
| endorsement.extend_from_slice(&cert_len.to_le_bytes()); | ||
| endorsement.extend_from_slice(ta_signing_cert); | ||
| Some(endorsement) | ||
| } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
- This change is based on the discussion with Dikla. My understanding is that,
TA_DATAwill 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.
There was a problem hiding this comment.
Hey.. yes. From yesterday's discussion, they don't care. But I think another TA could. And if we change it then the remote verifier will also have to be changed. I think we should make it parsable
There was a problem hiding this comment.
I decided to provide two commands which simply have difference placements of TA_DATA. In terms of parseability, I think the verifier can still parse the claim anyway because it knows golden UUID, SVN, TA_DIGEST, ... which will work as anchors.
There was a problem hiding this comment.
Question is more about whether we want to implement table-based one (as EnS expects) or use the current flat layout.
| endorsement.extend_from_slice(&ta_data_len.to_le_bytes()); | ||
| endorsement.extend_from_slice(&ta_uuid.to_le_bytes()); | ||
| endorsement.extend_from_slice(&ta_svn.to_le_bytes()); | ||
| endorsement.extend_from_slice(ta_digest); |
There was a problem hiding this comment.
Do we need a field for ta_ digest size ?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Added fields for digest algorithm and lengths.
702a806 to
4635544
Compare
4635544 to
349d5b0
Compare
| const LDELF_BINARY: &[u8] = &[0u8; 0]; | ||
| const TA_BINARY: &[u8] = &[0u8; 0]; | ||
| const TA_BINARIES: &[&[u8]] = &[TA_BINARY]; | ||
| const TA_SIGNING_CERT_DER: &[u8] = &[0u8; 0]; |
There was a problem hiding this comment.
So I think Angelina has a different way of sending the cert. But let us check in your PR and then Angelina can fix it up with her signing PR
There was a problem hiding this comment.
Yes. This is a placeholder for now.
e6c4a27 to
6549039
Compare
6549039 to
252203e
Compare
|
🤖 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. |
3 participants
This PR introduces the IDK_S PTA. It provides commands to endorse TA-provided data with a flat structure signed by an IDK_S key. A wire format depends on whether the data is normal or pre-framed: 1) normal:
REPORT || TA_DATA || SIGNATURE_PARAMS || SIGNATURE; 2) pre-framed:TA_DATA || REPORT || SIGNATURE_PARAMS || SIGNATURE. All bytes except forTA_DATAare from the LiteBox/PTA andSIGNATUREcovers all except for itself.