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

["lgl island-resort.com" <[e-mail]>]

Hi Usama,

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.

A little background for my comment:

Seems like so far we have written a lot more about freshness than security considerations for attestation system architecture and key life cycles.

I did work on what was essentially an attestation project ten years ago. For freshness, it was a system design that a mid level system architect could handle in a month or so and for implementation it was a few months by a mid-level engineer. OTOH, setting up the attestation keys management system took years and multimillion dollar contracts because it affected the factory floor and the set up of crypto operations (HSMs). It was not the same as HSMs for TLS at all. Some of it hinged on complex system architecture, particularly the interconnect between sub modules.

OTOOH, many will avoid such complexity by buying chips or systems that have already done this.

A few more comments below.


On Nov 14, 2024, at 3:51 AM, Muhammad Usama Sardar <[e-mail]> wrote:


Hi Laurence,

On 12.11.24 21:25, lgl island-resort.com wrote:

On Nov 11, 2024, at 6:21 AM, Thomas Fossati <[e-mail]><mailto:[e-mail]> wrote:
...

At least, we need these three base properties:

* integrity -- the conceptual messages cannot be manipulated;
* authenticity -- the protocol principals are really who you think they are; and
* freshness -- the temporal aspects of the session cannot be distorted
(e.g., re-ordering of events, compression/dilation of the timeline);

I don’t worry much about freshness. *Everyone* gets it. When I started presenting EAT in 2018, that was the first question every time. We have lots of docs. Still needs mention of course.


I would respectfully disagree here. In fact, freshness is currently my biggest worry :) If we talk about it theoretically, yes the concept of freshness exists since several decades. But is it well-understood for TEEs? I think "no". Even the five authors mentioned on my first slide currently have a very diverse view of freshness, let alone the whole WG. In Dublin, I even heard people saying that the Attesting Environment can also generate a nonce because it is trusted. Recently, in CCC Attestation SIG, we had one hour of inconclusive discussion alone on the topic of freshness where folks had very diverse opinions.

But for those who consider it well-understood, I can open a couple of Pandora boxes for TEEs:

  *   I have heard Henk distinguishing freshness and recentness in previous meetings. I discussed this with him in Dublin. It is never defined in RFC9334 and I don't see how to incorporate this in protocol analysis. I wonder how do folks perceive the difference between the two.
  *   What happens when the Attester gets an attestation nonce? Does it just collect the measurements from cache or does it remeasure some of the components?

Maybe I’m missing something, but freshness doesn’t seem any different for a TEE than any other environment.


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.


What seems less articulated is things like how much of the device was covered. Was the HW covered. Is the device architecture, all the way to the HW, well designed so that the attestation isn’t subverted?
Fully agree. I talked about this in meeting 118.
How is attestation composition secured? That depends on the security of the interconnect between lead and sub attesters which is probably secured by SoC architecture.

Fully agree, though it can be abstracted to some level for generalization, as we did for Arm CCA.
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.

LL