Re: [Rats] Android comments on EAT draft

[Shawn Willden <[e-mail]>]

On Sat, Jul 6, 2019 at 8:05 AM Giridhar Mandyam <[e-mail]>
wrote:

> >>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”?
>

I'm not a member of the privacy team, so I don't know all of the
rationale/considerations, but I know one element of it is to protect
dissidents living under oppressive regimes.  There's a desire to make it
possible for them to prevent their devices from giving away any information
they don't want revealed, via rooting and modification of the Android OS.
Since they can't modify TEE/SE functionality, it's on us to limit the
feature set of the TEE/SE code so it doesn't reveal private information, to
the degree we can.

This is why the existing Android attestation uses batch attestation keys,
to avoid making the attestation key a strong unique identifier, and why the
ID attestation features are tightly restricted and include a low-level API
to wipe the IDs and thereby disable ID attestation.  I'm assuming that
similar logic would preclude location attestation, though the question
hasn't actually come up.


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

It could, yes, but I don't think Android will enable that.


>
> -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]>
> wrote:
>
>
> Shawn Willden <swillden=[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] |
>  720-924-6645
>


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