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

Laurence Lundblade <> Wed, 12 February 2020 17:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2321208E5 for <>; Wed, 12 Feb 2020 09:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BBzatiBQ41fH for <>; Wed, 12 Feb 2020 09:16:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DD4B1208DC for <>; Wed, 12 Feb 2020 09:16:47 -0800 (PST)
Received: from dii-102208.home ([]) by :SMTPAUTH: with ESMTPA id 1vcyjC4bAGSq51vd0jSGqy; Wed, 12 Feb 2020 10:16:47 -0700
X-CMAE-Analysis: v=2.3 cv=RvO70xuK c=1 sm=1 tr=0 a=OUXnzmuUtImtGdqeZRusCA==:117 a=OUXnzmuUtImtGdqeZRusCA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=7CQSdrXTAAAA:8 a=X7Ea-ya5AAAA:8 a=0VD3yzJn4lskfK2-60EA:9 a=QEXdDO2ut3YA:10 a=oam3c5mu0vjhVFVr9i0A:9 a=U8V5T3N1VUAZFB8v:21 a=_W_S_7VecoQA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 a=f3QdawHiMRSDlnPgGXNW:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_30E267AD-AD96-409A-9E9F-EC08E8B5C581"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 12 Feb 2020 17:16:43 +0000
In-Reply-To: <>
Cc: "Salz, Rich" <>, Simon Frost <>, "" <>, "Smith, Ned" <>
To: Thomas Fossati <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfDXvHNS8RNXT+/mUL5XeLBgwq6oqtJSB5J+1y84XUZYlufdUEjz+/y4uogMmZoCYoiGjK5qJFICxtwPd15dC/aRIO3bTRB7hlYr3E1sSqcaCCsq5gnus +PzK06+bVVmW/bgD8RIhYtVl8DTHrAinyN9eKrjMlK3KJd2bYgPkl6svIXpw4Pl5db1koIQ8RZaQ9R9KAbk+osIPW2kTpjWCTDGc3ZbkyqswDzp83ds4ykVV fjUt6qyFT62l2y0cVtUQg3psnugnvBZN9/o9WtiYgH7s0wdgGrNDcUkTO1UiHXzi
Archived-At: <>
Subject: Re: [Rats] About (E)UID's
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2020 17:16:51 -0000

> On Feb 12, 2020, at 4:07 PM, Thomas Fossati <> wrote:
> On 12/02/2020, 15:50, Salz, Rich <> 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.