Re: [Rats] UEID in EAT

[Laurence Lundblade <[e-mail]>]

First the uniqueness and collision problem, then separately the privacy problem.

So a type 0x1 UEID is a true crypto quality random number. The theoretical problem is the one of a collision between two true random numbers, the birthday problem.

In the implementation where a true crypto quality RNG like those supported by Intel chips and Qualcomm chips these days, there is no hash function involved. So it’s not the same problem as a hash collision problem. Really it is just the birthday problem.

Uniqueness across vendors for type 0x01 UEIDs is assured because the vendors are using crypto quality RNGs. It doesn’t matter if there are million vendors or one vendor.

There may be a concern that vendors won’t use crypto quality random numbers, but that is still not a hash collision problem.

If you choose to generate UEIDs by hashing some other random data, then the quality of the hash function comes in and of course the quality or randomness of what you hash. We can recommend hash functions, maybe even DRBGs, but the real requirement is crypto quality randomness in the full solution.

The uniqueness to type 0x02 and type 0x03 UEIDs across vendors is entirely different from type 0x01 and depends on an organization like IEEE registering vendors and assigning IDs. That is just following industry practice.

Vendors can do all sorts of bad things here to break the uniqueness even for MAC addresses and IMEIs. I’m not sure we can do much about it except describe the way it should be done. (A good certification program could do something about this, but IETF doesn’t run certification programs). The good news is that crypto quality RNGs are generally available now.


Now on to privacy.

I think we should define a true globally unique UEID that is not privacy preserving and that never changes. Billions of single-use devices will be just fine with this and billions probably require this. It’s the multi-use devices like laptops and mobile phones where the big problem is, but that is only a subset of the target market.

In addition to a non-privacy-preserving UEID, we could design one or more solutions that do give privacy preservation. I didn’t do that yet because it seems hard. We could do it. Maybe it should be in EAT, maybe it should be a separate draft of even drafts if there are multiple solutions. Maybe one is based on Juan’s IEEE work.


To summarize / unpack:

#1 vendor uniqueness — Birthday problem for type 0x01; industry registry and assignment for type 0x02 and 0x03

#2 hash collision — Only an issue if a hash function is used; can recommend hashes; true issue is overall randomness quality

#3 privacy — keep the non-privacy-preserving UEID for use cases that need it; entertain proposals for privacy preserving UEIDs

LL




> On Sep 11, 2020, at 5:25 AM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Hello,
> 
> Someone had pointed out a possible problem with the UEID, so I dug a little and wanted to poke at it.  In looking at the UEID, it relies strictly on the collision rate for hash generation, setting the number of bits high enough for the very large number of devices that could be assigned an UEID.  It also states that the UEID never changes.
> 
> The question posed to me privately is that there seems to be a conflict in the two sections on this proposal.  How do you ensure uniqueness across vendors?
> 
> Going back to an example, collision attacks have been successful even though they are highly sophisticated.  The earliest example was in one of the exploits used in the STUXNET attack.  That example resulted in deprecation of older hash functions.  Minimally, some recommendations should be provided on hash functions, pointing to a registry of maintained recommendations.  The problem across vendors is also interesting in that you can track this within a vendor, but how do you ensure uniqueness across vendors?
> 
> I am copying Juan Carlos as he and others did work within the IEEE that could be very useful here.  They standardized a method to produce randomized MAC address values.  While vendors had their own method, privacy was not assured as it was possible to detect what vendor generated a particular value due to variances in their algorithms.
> 
> IEEE has also moved to a method to allow for changing MAC addresses for increased privacy.  Should EUID remain a constant value or be able to change over time?  There's likely value in allowing change over time for privacy.  You can find IEEE information on the problems associated with changes over time, but usually that type of work can lead to answers on how to make it work.  
> 
> I am hoping Juan Caros may be able to assist a bit here and we can learn from IEEE's experience and save a bit of time.
> 
> Thank you,
> Kathleen
> 
> -- 
> 
> Best regards,
> Kathleen
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats