Re: [Rats] Android comments on EAT draft

[Laurence Lundblade <[e-mail]>]

First comment: I’m not sure this discussion has a big effect on what we standardize here. It seems reasonable to standardize the location claim even if Android or others don’t use it because it is a useful claim. So we should keep the location claim.  There should be some privacy discussion for the claim, probably suggesting at minimum the user’s consent be obtained before it is sent.

Second comment (not really relevant to standards work): It could work like this. The non-TEE part of the device (i.e., Android) tells the TEE if it can include the location or not. When the TEE includes it, it will be non-spoonable. That should be OK, because the user and Android are still in control. I fully agree that the TEE should not be sending any data that has any privacy issue on it’s own.

LL


> On Jul 6, 2019, at 12:33 PM, Shawn Willden <swillden=[e-mail]> wrote:
> 
> On Sat, Jul 6, 2019 at 8:05 AM Giridhar Mandyam <[e-mail]..com <mailto:[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 <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 <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] <mailto:[e-mail]>> On Behalf Of Shawn Willden
> Sent: Saturday, July 6, 2019 7:25 PM
> To: Michael Richardson <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[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
> 
> 
> 
> -- 
> Shawn Willden | Staff Software Engineer | [e-mail] <mailto:[e-mail]> | 720-924-6645
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats