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

[Simon Frost <[e-mail]>]

I think that modification would address this discussion well (though perhaps add ‘or verifier’ as well as relying party in the text).

I agree not making a hard association here with any key selection, any implementor should be considering their particular threat model on how the different claims are protected.

Thanks
Simon

From: Laurence Lundblade <[e-mail]>
Sent: 12 February 2020 17:17
To: Thomas Fossati <[e-mail]>
Cc: Salz, Rich <[e-mail]>; Simon Frost <[e-mail]>; [e-mail]; Smith, Ned <[e-mail]>
Subject: Re: [Rats] About (E)UID's


On Feb 12, 2020, at 4:07 PM, Thomas Fossati <[e-mail]<mailto:[e-mail]>> wrote:

On 12/02/2020, 15:50, Salz, Rich <[e-mail]<mailto:[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
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.