Re: [Rats] 802.1AR device identity

[Laurence Lundblade <[e-mail]>]

I want to unpack and unfold a few things here.

Permanence / Lifecycle / Privacy — I think the main topic here is about when an ID changes relative to the lifecycle of the device and how this relates to privacy.

Compromise — I think compromise due to algorithms being compromised or the device being owned or such is a separate topic. Discussion of it seems orthogonal, should go into security considerations and really comes down to certification in the end if you really want to lock it down.

I’m not sure which is meant by “immutability” in the previous emails.

My intent in the definition of UEID was that it is truly permanent. It doesn’t change at any time in the lifecycle of the device. This is the simplest case to describe. It is not at all privacy preserving for some use cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor). 

I was thinking other folks might define other IDs for other use cases. Maybe the time has come to invent one or two of those and put them in EAT.

Some Solutions
One possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED). It is allowed to change in major events in the devices lifecycle such as events when ownership changes, the managing entity changes or on factory reset. I think this lines up with the way some MAC addresses are managed for privacy reasons. This line up is good because a UEID can be an IEEE MAC.

An RP might receive an EAT with only an UEID, only an SPUEID or both. The RP can decide what they want to use.


Another one is for the Attester to authenticate the Verifier and/or Relying Party and generate a distinct UEID or SUEID just for use by that RP. This is a solution to the privacy issue. I’ve actually done an implementation of this one.


A related solution is to have a privacy proxy between the Attester and the Verifier that makes RP-specific UEIDs or SUEIDs.


Separation of ID from Attestation Key
An ID that is not signed is nearly useless because anyone can forge it so we’re always talking about some sort of signing.

EAT intentionally separates the ID from the signing key. I haven’t read IDevID, but I don’t think it has this separation. The reason EAT separates them is to have a lot of flexibility to deal with the privacy and lifecycle issues that come up in real deployments for chip makers and complex supply chains.

For example, FIDO uses group attestation keys to deal with the privacy issue. One key is put into 100,000 plus devices which makes it statistically not very useful for tracking users. Maybe the device manufacture uses this tactic for billions of devices. Then maybe a use case involving only millions of these devices needs a truly global ID and have the means to program it. This can work if the keys and IDs are separate.

Or maybe the manufacturer changes signing schemes moving from a primitive MAC to EC-based pub key and onto some sort of DAA while maintaining the same scheme for device IDs.


Possible harmonization with other Device IDs?
I noticed that birkholz-rats-suit-claims <https://tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt> mentions a device ID based on UUIDs. We should probably take a look at how this relates UEID. There’s probably others to check out. We probably want to re use a lot of the claims from Evidence in Attestation Results so they can be pass-through for the Verifier.

Note also that UUIDs are obsolete now.

LL


P.S., Any suggestions on how to get access to IEEE IDevID? I’m not part of a big company. I tried joining IEEE once, but that wasn’t enough to get access.