Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)

Laurence Lundblade <> Sat, 20 October 2018 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7109129BBF for <>; Sat, 20 Oct 2018 08:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R8YoWtDlTG2m for <>; Sat, 20 Oct 2018 08:22:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2275312958B for <>; Sat, 20 Oct 2018 08:22:00 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id Dt4cgnq49q2NHDt4egIwqm; Sat, 20 Oct 2018 08:21:59 -0700
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EEBF7BC4-07E5-409C-9C1B-8F357E0BA068"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sat, 20 Oct 2018 20:51:52 +0530
In-Reply-To: <>
Cc: "" <>, Guy Fedorkow <>, Hannes Tschofenig <>, "Smith, Ned" <>, Jeremy O'Donoghue <>, "" <>, Denis <>
To: Henk Birkholz <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfDtcKwNYuiNiS74DDljJE1fbosTqsnRZw/5bfZy3epy6YY7IbhkKegwGEAW7JvVThM3jCZAlYNtblYITeRS6EwlRNAjl2CzyUk+1Ng7SCGdQZa6ER75K meWubW5YaJGR9xvGaPVcc9kgMimS0sC3Uwd4Ouk+6jt3/8tY55r6goJ2eDF/IrnGVeEP9hbbyZpU2g0VmP98r/RCaI51MlgBni3B2wrey3avvHDp89NAnw4D fhctAZ1TYHLmZkXEnM+tPK0MY7qX9aI0dxBRUj4Z99lJU086TZOahUtwOWyXejM5oG8SEommNswi+0UMyDh7fu18W51UaNjEeoS8hRPTSS1roCSTBb9H/ARN si/ak22RrAb2HETWIruO9qIN9nddF8Q1nxXJ7p+1ZyltZloOZGc=
Archived-At: <>
Subject: Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Oct 2018 15:22:03 -0000

> On Oct 20, 2018, at 8:26 PM, Henk Birkholz <> wrote:
> Hello Laurence,
>  And I am perplexed how you think I was implying that EAT or CoID are insecure. How did I make the impression to have suggested that?

You have characterized EAT as only proof-of-possesion. It is not.

> Wrt the "verification keys" I am not so sure, what the diagram means by that. With an asymmetric key-pair these would probably be public keys to check the signature by (I assume)?

It is an open-ended range of things:
An ECDAA interaction with service (Maybe like Intel’s)
A verification request of an Android Attestation from a Google Service
An IEEE-802.1AR CA and Sub-CAs (mostly standard X.509)
A public key fetch based on any reasonable / useful key ID (e.g. Subject Key ID)
A submission of the EAT token signed by a symmetric key to a service that verifies it (and rather carefully protects the private verification keys with high quality HSMs)
A redirect through a privacy CA
Some custom manufacturer defined scheme

I strongly believe this flexibility is necessary for real deployments especially for the high investment already made by platform and chip vendors.

There is an assumption that the device manufacturer will only put attestation keys in devices that are configured correctly. Typically the attestation key will only be usable to sign attestation if the device booted code that was verified, debug was turned off and such. (I know TCG does this in a more elaborate thorough way, and that is good and well and can be put to use with EAT for appropriate use cases).