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

[Laurence Lundblade <[e-mail]>]

> On Oct 20, 2018, at 9:13 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Hello Laurence,
> 
> what I understood now, I think, is that the processes that will eventually make use of EATs - "in the bigger picture" - are intended to be based on more than proof-of-possession.
> The EAT that is the signed claim set is relying on the "assumption that the device manufacturer will only put attestation keys in devices that are configured correctly".
> 
> And that is exactly what I meant. The key material deployed on the thing has meaning: if it is there, you trust the assumption that the thing is configured correctly.

Seems to me that there is always some implied trust in the behavior of some part of the device you put the key in. It might be a tiny bit of HW, but it is something. No matter how many layers of measurement and roots-of-trust there are, the bottom that hold the key has to be trusted to have some behavior before you put the key in during manufacture.

> 
> Do we agree on this? :-)
> 

Well probably, but we haven’t spend enough time together yet to know for sure. :-)


> The reoccurring reference to TCG seems to exclude other more thorough approaches on how to conduct remote integrity verification a bit, I think. I am carefully highlighting this, because the reasoning behind an IETF WG is the demand for network protocols that are able to consolidate the different "inbox-api" and "out-of-band" concepts used in various domains.

I added a few lines below. 

Not sure what an inbox-api and such are yet...

LL


> 
> Viele Grüße,
> 
> Henk
> 
> On October 20, 2018 4:21:52 PM GMT+01:00, Laurence Lundblade <[e-mail]> wrote:
> 
>> On Oct 20, 2018, at 8:26 PM, Henk Birkholz <[e-mail] <mailto:[e-mail]>> 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

* A RATS Procedure based on TCG stuff
* A RATS Procedure not using TCG stuff



> 
> 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). 
> 
> LL
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> EAT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eat