Re: [Rats] Android comments on EAT draft

[Giridhar Mandyam <[e-mail]>]

>>Can you say more about location?
Are you saying that Android would never provide a relying party (say, an
open-protocol implementation of Pokemon GO) with where a device is?

>I strongly doubt that we will ever provide that.  I understand the benefits, but the privacy team feels like the risks are too great, that it's important that it always be possible to spoof privacy-critical data elements like location.

Can you expand on why “it’s important that it always be possible to spoof privacy-critical data elements like location”?

If we compare to the FIDO 2 location extension (https://www.w3.org/TR/webauthn/#sctn-location-extension), which can be included as part of the FIDO 2 attestation, the location data inclusion in the attestation is managed by the browser permissions framework that already exists for location (https://www.w3.org/TR/webauthn/#browser-permissions-framework-extensions).

It seems that the Android permissions framework could be similarly leveraged for an EAT-based location claim.

-Giri Mandyam, Qualcomm

From: RATS <[e-mail]> On Behalf Of Shawn Willden
Sent: Saturday, July 6, 2019 7:25 PM
To: Michael Richardson <[e-mail]>
Cc: [e-mail]
Subject: Re: [Rats] Android comments on EAT draft


CAUTION: This email originated from outside of the organization.


On Fri, Jul 5, 2019 at 12:28 PM Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

Shawn Willden <swillden=[e-mail]<mailto:[e-mail]>> wrote:
    > Specifically, EAT is about attesting to a *device* while Keystore
    > Attestation is about attesting to a *key* -- though we also attest to
    > quite

I have include a section in the use case document called "Cryptographic key
Attestion"

Great!

    > 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

Can you say more about location?
Are you saying that Android would never provide a relying party (say, an
open-protocol implementation of Pokemon GO) with where a device is?

I strongly doubt that we will ever provide that.  I understand the benefits, but the privacy team feels like the risks are too great, that it's important that it always be possible to spoof privacy-critical data elements like location.

    > 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).

These are all intended to be covered under "network attestation", but
now I wonder if that term is mis-leading.

Hmm.  Yes, you're attesting to the device state, not anything about a network.  I guess "network attestation" is because you're expecting the relying party to be the network?


--
Shawn Willden | Staff Software Engineer | [e-mail]<mailto:[e-mail]> | 720-924-6645