Re: [Rats] About (E)UID's

[Laurence Lundblade <[e-mail]>]

> On Feb 12, 2020, at 4:07 PM, Thomas Fossati <[e-mail]> wrote:
> 
> On 12/02/2020, 15:50, Salz, Rich <[e-mail]> wrote:
>> I am still concerned about what fails if someone re-uses an EUID,
>> either by accident or maliciously.  If the security of the RATS
>> architecture depends on uniqueness, this seems important.
> 
> I agree with you.

Here’s some text we might add:

UEID’s are intended to be globally unique permanent device identifiers, but these characteristics rely on the implementors of device following the specification well. A relying party, particularly one dealing with a very broad variety of devices from different manufacturers, may wish to take into account other data in the token to uniquely identify the device. For example they might consider a hash some or all of the UEID + oemid + hw_version + signing_key as the unique identifier of the device. Note these are all values that are permanently set for a device at time of manufacturer.


> 
> If ueid is used to locate the verification key, then verification
> would fail.  (BTW, this is what we do in PSA.)
> 
> If ueid is disjoint from the verification key, then it *might* result in
> impersonation -- this also depends on the verification policy.

I would like to keep the text in EAT for UEID focused on device identification and not try to build it into a key ID too, so I don’t think the text in the EAT document should consider that use case for UEID. Profiles of EAT can specify that and can doubly insist on uniqueness, proper implementation and have a certification program to check.

EAT is intended for use with a lot of different key types and signing schemes including things like ECDAA. Android and FIDO attestation use one key across 100,000 device for privacy. One implementation of attestation I’ve seen authenticates the relying party and generates relying-party specific UEIDs that are disjoint from the attestation key.  EAT needs to work for all of these. No strong coupling between the UEID and signing key should be required in the main EAT standard *and* it must allow for strong coupling should a profile wish it.

That is:
- UEIDs are for device identification
- Signing and signing keys are for claims authenticity and integrity, not device identification


> 
> The EAT document should warn about the latter.

Is the text above for the relying party, sufficient warning for the general case?  PSA will probably want stronger words in its profile.

LL