keyId

[muhammad-usama-sardar]

According to the discussion with @hannestschofenig on 05.09, there should be a usage of keyId in the model, which is currently missing in the draft. From a security perspective, it needs to be precisely described:

• what exactly it is, and
• from what factors it is derived.

[yaronf]

@muhammad-usama-sardar Hmmm, I didn't attend the meeting and I'm unable to find any mention of a KeyID in the draft. Can you please clarify what this means?

[muhammad-usama-sardar]

Can you please clarify what this means?

Sure. The primary issue is that notations attest_key(nonce,TIK) and sign(TIK,hs) as used in Figures 8 and 9 are not very precise. Some of the issues are described in #22. In order to resolve these issues, we were thinking about having the TIK generated within the trusted location (e.g., Realm) and then sending keyId to the untrusted world to be used as a handle for this key. For example, the server could then call the trusted location to sign the handshake with this handle to denote the key that should be used for signatures.

Hannes was supposed to check from the implementation what exact factors this keyId is derived from.

[thomas-fossati]

discussion on 19/02:

• attest_key() attests to the public part of TIK-X
• provide context to Figures 12 and 13 in -04 that explains the (split) internal arrangement of the TEE
• Yaron suggests to use "fingerprint" rather than key-id