Re: [Rats] Android comments on EAT draft

[Shawn Willden <[e-mail]>]

*From: *Laurence Lundblade <[e-mail]>

> - The claims in EAT are just a start and by no means complete. Adding
> claims that carry and describe keys is certainly on the list.
>

That's great to hear.  The existing claim set seemed to go an entirely
different direction and I wasn't sure if it would be considered a
"pollution" of the claim space to attest such radically different things.
I'll be glad to provide the set of key attestation parameters that Android
uses as a starting point for key attestation discussions.


> - All claims are considered optional and many claims are expected to be
> left out in some use cases for privacy reasons.
>

Perfect.  The Android case is kind of interesting because although we
specify the secure area implementations (and write reference
implementations), most of the implementations on actual devices are written
by third parties, often organizations that aren't as careful about privacy
as Google.


> Personally, I’d like to see EAT be useful for Android and would value
> yours and Google’s input to make it so.
>
> LL
>
> (Not sure what [e-mail] is, have replaced that address with
> [e-mail])
>

Hmm. Me neither.  At least it didn't fall into a black hole.  Thanks for
correcting it.


>
>
> On May 15, 2019, at 5:43 PM, Shawn Willden <
> swillden=[e-mail]> wrote:
>
> Hi all.
>
> After being invited by Laurence to join this WG some time ago, I have
> completely dropped the ball. I apologize for that; in the interim period I
> have expanded my team from one engineer (me) to six, and we all still have
> more to do than we can accomplish, which gives a good indication of how
> much I was dropping on the floor.  I think I have now delegated enough that
> I can begin to put some time into this.
>
> After reviewing the draft (which I like a lot, in many ways), I notice a
> crucial divergence of focus between EAT and Android Keystore Attestation.
> Perhaps this means that EAT is not applicable for Android; but I'd like to
> explore the question a bit.
>
> Specifically, EAT is about attesting to a *device* while Keystore
> Attestation is about attesting to a *key* -- though we also attest to
> quite a bit about the context of the key, i.e. the device. Indeed, the
> device information we provide is growing with every release, because
> there's a strong pent-up demand for device attestation.  So Keystore
> Attestation is gradually expanding to include the device attestation role,
> but must also retain its key attestation purpose.  For EAT to be directly
> applicable, it would have to include claims about a key as well.
>
> Perhaps another option is that we could use an EAT attestation as a
> sub-element inside a CBOR structure that attests to a key.  Or maybe there
> are other ideas about how an EAT attestation may fit into a larger
> attestation that describes characteristics of entities other than the
> containing device?
>
> Another, more tractable, area of difference is that EAT provides Claims
> for several data items which Android will likely never allow to be attested
> because of their privacy implications and potential for ecosystem
> fragmentation (apps choosing which devices they'll run on -- we generally
> try to deny them the information they'd like to have to make those
> choices).  These are:
>
>    - UEID
>    - Origination
>    - Location
>
> We do allow OEM Identification, though it's a different format and is
> restricted.
>
> Some other claims that we have, and think are important, are OS version
> and patch-level (represented as a date, YYYYMMDD); secure boot verification
> key digest; secure boot digest (hash of all verified code); application ID
> (a digest of the requesting app signing key); and secure app version (hmm,
> don't have a patchlevel, but we should!  I'll see about adding that for R).
>
> I suppose all of this could be address by registering additional claims.
> I'm not sure it would make sense to add a set of claims (or a complex
> claim) that addresses key attestation, though.  That seems to significantly
> change the semantics. Or does that sort of extension seem appropriate to
> folks?
>
> I also have a set of more detailed comments and questions, plus some
> editorial suggestions.  I put the draft into a Google Doc and added
> comments.  I've asked my team to take a pass through it as well, and I'll
> share it with this mailing list as soon as they've had a chance to weigh in.
>
> Again, my apologies for jumping in late.  Let me know if you think EAT
> just isn't appropriate for Android.
>
> --
> Shawn Willden | Staff Software Engineer | [e-mail] |
>  720-924-6645
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>


-- 
Shawn Willden | Staff Software Engineer | [e-mail] | 720-924-6645