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

[Muhammad Usama Sardar <[e-mail]>]

Hi Laurence,

On 14.11.24 19:45, lgl island-resort.com wrote:
> Generally, I’m only hoping for some attention to be put on some of the 
> fundamentals that get less attention like key lifecycles. Certainly 
> not objecting to any work. 
Indeed, I misunderstood your previous email to mean that we should not 
work on these because they are pretty well-understood. Anyway, thanks 
for the clarification.
> Maybe I’m missing something, but freshness doesn’t seem any different 
> for a TEE than any other environment.

I feel that it is even less understood in TEEs - perhaps because of the 
complexity and the strict threat model. Additionally, the confidential 
computing hardware vendors as well as the framework developers either do 
not specify things at all or leave it underspecified.

>>> Integrity and authenticity are pretty well understood too.
>>>
>> Disagree here as well and a couple of Pandora boxes for TEEs to get 
>> started:
>>
>>   * For authenticity, we need identity. What exactly is the identity
>>     of the workload?
>>   * If the certificates tie the workload to a unique physical
>>     platform, how does the migration of workload work?
>>
> Agree that identity is not well understood. I wasn’t including that in 
> the “integrity and authenticity” frame when I made my comment. I'm 
> happy that we work on identify however we classify it.
>
To me, authenticity (or authentication) refers to the guarantee that 
Verifier communicates with the /intended/ Attester (as we defined in 
Sec. II.C.3 of [1]); and to distinguish intended Attester from other 
Attesters, we need to have some form of identity of Attester. Happy to 
know/discuss if WG interprets it differently.

[1] 
https://www.researchgate.net/publication/375592777_Formal_Specification_and_Verification_of_Architecturally-defined_Attestation_Mechanisms_in_Arm_CCA_and_Intel_TDX

>
>>> How keys are stored in the device and how they are put into the 
>>> device is really important? Typically this is during manufacturing 
>>> and requires secure facilities.
>>>
>> Fully agree, and I think no vendor ever specified this. If anyone is 
>> aware of any spec, please point me to it.
>>
> Vendors may not share much here. From what I know it is often 
> proprietary. It may be in the realm of where physical and operational 
> security come into play. That doesn’t mean that we can’t have useful 
> things to say.
Would be great to have your and WG insights added to the document, since 
I don't have much to add here.

Regards,

Usama