Subject: Re: [EAT] [saag] "EAT" proposal for device attestation

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2018 11:03:37 -0400

Laurence Lundblade <[email-masked]> wrote:
    > FYI, Some of us are interested in developing what we call an "Entity
    > Attestation Token” that can provide some assurance about a device to its
    > remote communication peer in a general and standard way. Attestation similar
    > to this is done by FIDO, BRSKI, Intel EPID, recent versions of the Android
    > key store and other, but they all use different formats.

okay, you got my attention by naming my draft :-)
Beetlejuice, beetlejuice, ...

While BRSKI says that attestation is import, it doesn't actually do any
attestation.   I don't really know how we'd include it in BRSKI, come to
think of it.  BRSKI ought to be able to transport the artifacts you are
describing.

You may also be interested in draft-ietf-anima-constrained-voucher
and draft-ietf-6tisch-dtsecurity-zerotouch-join.

    > We’re proposing CBOR and COSE for a general standard format. We have first
    > draft here.

    > There is a non-WG mailing list for discussion: [email-masked]. It is just
    > getting started so there hasn’t been any discussion yet. I expect the core
    > standards work would be aligning on claims that describe devices, but I’m not
    > sure if folks are familiar with the current schemes out there that I
    > mentioned above and what they do.

    > I will attend the Montreal IETF and hopefully present a HotRFC.

(I will be camping, and miss it)

Some comments so far in my reading (which is not yet complete):

  The Manufacturer.  The company that made the entity.  This may be a
       chip vendor, a circuit board module vendor or a vendor of finished
       consumer products.

Given that it may be three (or more) entities, and they each have different
agendas, I think that it might be worth being specific about each level.

   In this case the manufacturer should
   perform the verification, because any release of the key material
   would enable a participant other than the entity to create valid
   signed EATs.

s/manufacturer should/manufacturer MUST/

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 20 Jun 2018 22:55:42 -0700

Hi Michael, thanks for the comments.

Seems to me that BRSKI and Zerotouch, both rely on the IDevID key pair (more precisely a private key and an X.509 cert) being provisioned on the device before they start.  This key is used to prove the device is not a fake or an emulator.  I would call this a form of attestation.

EAT is designed to make use of identical key material and to also prove the device is not a fake or an emulator.

EAT however uses this key material with COSE to produce a signed message, while BRSKI uses this key material to run a TLS or DTLS session. There is probably a bit of philosophical difference on which is better, or whether they can work together and if so, which is on top of which. This is definitely worth a lot of discussion but won’t delve into it yet.

EAT is designed to work with a lot of different keying schemes that includes IDevID, EPID, ECDAA, symmetric key schemes, custom schemes and so on. I think this flexibility is critical to deal with device and chip manufacturing issues (and privacy issues). From what I’ve read so far, BRSKI and zerotouch work only with IDevID (private key plus X.509 cert). 

One of the chip manufacturing issues is that X.509 certificates are too big to put into fuses. Fuses cost a lot of die area and need to be minimized to keep chip costs down. A 256-bit key pair seed is a much more reasonable thing to put into fuses in a chip, especially a low-cost IoT chip.

Another issues is that chip vendors don’t own their fabs and switch from one fab to another. A competitor's chips might be made right next to theirs. That results in messiness and expense in provisioning keys into chips during manufacturing. The systems used to provision keys into chips take a long time to build, deploy and secure. 

I need to more reading and thinking, but it seems that TLS/DTLS is not is adept at handling these issues and variations.  Have you talked about these issues in BRSKI and zerotouch?

Will catch up on your comments on the manufacturing claim later.

LL

> On Jun 15, 2018, at 8:03 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> EAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eat

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jun 2018 10:22:06 -0400

Laurence Lundblade <[email-masked]> wrote:
    > Seems to me that BRSKI and Zerotouch, both rely on the IDevID key pair
    > (more precisely a private key and an X.509 cert) being provisioned on
    > the device before they start.  This key is used to prove the device is
    > not a fake or an emulator.  I would call this a form of attestation.

Unless a TPM is involved, I don't consider it an attestation.

    > EAT however uses this key material with COSE to produce a signed
    > message, while BRSKI uses this key material to run a TLS or DTLS
    > session. There is probably a bit of philosophical difference on which
    > is better, or whether they can work together and if so, which is on top
    > of which. This is definitely worth a lot of discussion but won’t delve
    > into it yet.

BRSKI also signs a voucher-request which may be COSE or CMS.

    > EAT is designed to work with a lot of different keying schemes that
    > includes IDevID, EPID, ECDAA, symmetric key schemes, custom schemes and
    > so on. I think this flexibility is critical to deal with device and
    > chip manufacturing issues (and privacy issues). From what I’ve read so
    > far, BRSKI and zerotouch work only with IDevID (private key plus X.509
    > cert).

We are considering a method by which the IDevID could be retrieved from the
Internet rather than from the device.

    > One of the chip manufacturing issues is that X.509 certificates are too
    > big to put into fuses. Fuses cost a lot of die area and need to be
    > minimized to keep chip costs down. A 256-bit key pair seed is a much
    > more reasonable thing to put into fuses in a chip, especially a
    > low-cost IoT chip.

While I'm not a a fan of PKIX, in this case I think it has great value.
The IDevID, being a signed object, does not need to stored in as critical
(i.e. tamperproof) place as the private key.

    > Another issues is that chip vendors don’t own their fabs and switch
    > from one fab to another. A competitor's chips might be made right next
    > to theirs. That results in messiness and expense in provisioning keys
    > into chips during manufacturing. The systems used to provision keys
    > into chips take a long time to build, deploy and secure.

Yes, this is a concern.
I'm not sure how this changes.

    > I need to more reading and thinking, but it seems that TLS/DTLS is not
    > is adept at handling these issues and variations.  Have you talked
    > about these issues in BRSKI and zerotouch?

I don't think that the choice of protocol affects how easily the chip is
to manufacture.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Jun 2018 10:53:57 -0700

Hi Michael,

I have more BRSKI and other reading to do; here’s some partial comments to keep the conversation going.

> On Jun 21, 2018, at 7:22 AM, Michael Richardson <[email-masked]> wrote:
> 

FIDO <https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/> and Android KeyStore <https://developer.android.com/training/articles/security-key-attestation> use the term attestation when there is no TPM and when there is no measurement of running SW that TPMs typically do. Maybe this is annoying distortion of a well-understood TCG term.

But, I don’t care that much what it is called. I’m interested in how BRSKI and EAT relate because I think the ADs and lots of other folks will ask that question.

It still seems to me that both EAT and BRSKI make use of a secret/private key that is stored securely on the device by the device manufacturer. That key is used to prove to a server / service that the device is not a fake or emulator.

From there BRSKI goes on to define a protocol for bootstrapping a device configuration and binding to a cloud service.

EAT goes in a different direction to define a general means of representing and signing lots claims about the device for lots of different use cases.

BRSKI prefers IEEE IDevID.

EAT can use IEEE IDevID, but accommodate other signing schemes like EPID / ECDAA to deal with privacy, other non-X.509 public key schemes and even symmetric keys if necessary.

Does that make sense to everyone as a start on how these relate?

LL

---

From: Suresh Marisetty <[email-masked]>
Date: Thu, 28 Jun 2018 18:07:52 +0000

Good Point Michael,

Irrespective of the attestation scheme or protocol used (BRSKI, FIDOO, TPM,  or even EAT), it would all starts with an attestation key that is provisioned.

As of now, I have not come across EAT definition of it yet, but assumes that some attestation key exists.

FIDOO goes into lot of details on how to provision the keys in four different ways with some of the methods supporting anonymity:
1.       Full Basic attestation - global attestation private key used to sign attestation data
2.       Surrogate Basic Attestation - self signing with a private key (not an attestation key)
3.       Privacy CA - alias attestation key pairs signed by privacy CA
4.       DAA - credential used with blinding's to sign attestation data

EAT tokens can build the attestation objects in the specified format, but attest them with a chose key mechanism.  I believe the FIDOO near-equivalent of EAT is  KeyRegistrationData (KRD) objects if my understanding is correct.

Are we leaving this open for the EAT, to have each implementation use a different attestation key mechanism (FIDO, BRSKI, TPM, EPID, ??) and provisioning?

Thanks
Suresh Marisetty

From: EAT <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Thursday, June 28, 2018 10:54 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAT] [saag] "EAT" proposal for device attestation

Hi Michael,

On Jun 21, 2018, at 7:22 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

FIDO<https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/> and Android KeyStore<https://developer.android.com/training/articles/security-key-attestation> use the term attestation when there is no TPM and when there is no measurement of running SW that TPMs typically do. Maybe this is annoying distortion of a well-understood TCG term.

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jun 2018 15:03:43 -0400

Laurence Lundblade <[email-masked]> wrote:
    > But, I don’t care that much what it is called. I’m interested in how BRSKI
    > and EAT relate because I think the ADs and lots of other folks will ask that
    > question.

    > It still seems to me that both EAT and BRSKI make use of a secret/private key
    > that is stored securely on the device by the device manufacturer. That key is
    > used to prove to a server / service that the device is not a fake or
    > emulator.

    > From there BRSKI goes on to define a protocol for bootstrapping a device
    > configuration and binding to a cloud service.

Yes, but in BRSKI, after connecting, BRSKI replaces the manufacturer's key
with a domain-specific key bound to the owner of the device.

Once the device is under the owner's control, the manufacturer is no longer
involved.   I don't think the LDevID is generally useful for attestation, but
I could be wrong in some specific situations.

    > EAT goes in a different direction to define a general means of representing
    > and signing lots claims about the device for lots of different use cases.

    > BRSKI prefers IEEE IDevID.

I would say it differently, but yes, that's true.

BRSKI says to manufacturers, "thou shall provision a key pair signed by manufacturer".
We don't really care that much about what it is... and actually 802.1AR's IDevID
is woefully underspecified in my opinion!
The major reason to refer to 802.1AR so that nobody thinks we are asking
something ridiculous, and to make it clear that a TPM could be used to store
it.

BRSKI could carry an EAT artifact in it somewhere.
There are quite a number of choices actually.

    > EAT can use IEEE IDevID, but accommodate other signing schemes like EPID /
    > ECDAA to deal with privacy, other non-X.509 public key schemes and even
    > symmetric keys if necessary.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 29 Jun 2018 06:47:40 +0000

Hi Michael, Hi Laurence,

I prefer to keep the work on BRSIKI and EAT separate. I would also prefer not to reference IEEE 802.1AR.
I think it would be a distraction.

Ciao
Hannes

-----Original Message-----
From: EAT [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 28 June 2018 21:04
To: Laurence Lundblade
Cc: [email-masked]
Subject: Re: [EAT] [saag] "EAT" proposal for device attestation

    > configuration and binding to a cloud service.

Yes, but in BRSKI, after connecting, BRSKI replaces the manufacturer's key with a domain-specific key bound to the owner of the device.

BRSKI says to manufacturers, "thou shall provision a key pair signed by manufacturer".
We don't really care that much about what it is... and actually 802.1AR's IDevID is woefully underspecified in my opinion!
The major reason to refer to 802.1AR so that nobody thinks we are asking something ridiculous, and to make it clear that a TPM could be used to store it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Jun 2018 11:54:49 -0700

Yes, I think the work should be separate. There’s lots of EAT stuff that has little to do with BRSKI and vice versa.

I do think it is useful to understand the primordial device key material in both and see how they relate.  From my experience this key material is to get set up well so the more info we have on real world practice and results, the better. 

LL

> On Jun 28, 2018, at 11:47 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Michael, Hi Laurence,
>