[Rats] Android comments on EAT draft

[Shawn Willden <[e-mail]>]

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