[Rats] Re: Security considerations of remote attestation (RFC9334)

["Smith, Ned" <[e-mail]>]

See inline [nms]

On 1/13/25, 13:26, "Muhammad Usama Sardar" <[e-mail]> wrote:


Please see inline
On 13.01.25 06:38, Panwei (William) wrote:

On 05.01.25 19:48, Muhammad Usama Sardar wrote:
Below I am assuming a remote attestation solution based on digital signatures. At a high level, there are three main keys:

1.      Attestation Key (AK): It is used for signing attestation claims.

2.      TLS Identity Key (TIK): Ephemeral Key (EK): It is a key generated within a TEE and its public part is signed by AK. However, the TLS peer (TLS client in my case) has no prior knowledge about this key.

[WP] In your case, I think you mean this TIK EK is the key of the TLS server and the TLS client has no prior knowledge about this key.
Correct. In case the visualization helps, see Fig. 8 in [1].

Does the TLS client have knowledge of the AK?
For simplicity, let's assume TLS client has the public part of AK. There are bigger issues otherwise.

Could the identity of the owner of this TIK EK be signed as long as the public part by the AK as well? I guess it’s doable.
I think you mean s/as long as/along with. Here is my pain point: It is a key generated somewhere in the cloud; who is its "owner" and what is his "identity"?
[nms] Every authentication use case is an attestation use case. The TIK may also be attested implying there is an EK signing evidence about the TIK. Some drafts referred to this as “key attestation”. So for every key in a certificate path that stems from an EK, there could be a key attestation context echoing its trust properties. This can lead to a very complex graph problem without simplifying assumptions. RFC9334 suggests that a trust anchor policy can be used to simplify the otherwise unwieldy graph problem. Provably correct security that choses to not allow TA policy as an acceptable precondition is faced with having to consider the complexity of the graph.




3.      TLS Identity Key (TIK): Long-term Key (LTK): It is the key bound to the machine's long-term identity (assigned name/FQDN etc.) and it is the key which is typically used to provide "authentication" in standard (non-PSK based) TLS protocol.

[WP] Key #2 is generated within a TEE and its public part is signed by AK. What about Key #3? Is Key #3 stored in a TEE and this secure storage is attested (signed) by the AK (Key #1)?
I think there should be some protection, but it is not specified in [2].
[nms] A formal analysis likely will require stating assumptions that some of the keys are determined to be trustworthy by policy so that the other keys’ trust properties can be analyzed within the context that they are defined (aka as part of the TLS-attest spec).


Typically 1 is more protected compared to 2. Breaking 1 leads to trivially breaking 2.

[WP] Key #2 is generated and stored within a TEE, and I think Key #1 also needs to be stored within the TEE.
Correct.

So are these two keys protected at the same level?
No, Key #1 is typically more protected compared to Key #2. If Key #1 leaks, the security of all VMs on that platform breaks. If Key #2 leaks, only that specific VM is affected.
[nms] It would be helpful if there was a way to express protection level as a property of the key (aka key attestation). Then a protocol analysis can capture key protection level (whether actual or assumed) and analyze whether there is an escalation of privilege due to a key at a (assumed?) lower level affecting the level of another key. The security principle is the system is only as strong as the weakest link. So, if key #1 is more protected than key #2, but key #2 is related to key #1 in such a way that trust in key #1 depends on trust in key #2. The effective trust for both can’t be higher than the key #2 level.

Usama

[1] https://ieeexplore.ieee.org/document/10752524

[2] https://www.ietf.org/archive/id/draft-fossati-tls-attestation-08.html#section-6.2