Re: [Rats] Android comments on EAT draft

On Wed, Jul 10, 2019 at 10:18 PM Laurence Lundblade <lgl@island-resort.com>
wrote:

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

Completely agreed.

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

We'll go a step beyond that, I think, and mandate that the TEE also must
refuse to provide the location claim under any circumstances.  But the
location claim may certainly be useful elsewhere..

I'll point out that those of you who find location claims useful for your
solutions really do not want Android to provide location claims (from the
TEE). The reason is that location is inherently spoofable, by spoofing the
RF signals that tell the device where it is.  At present, such RF spoofing
equipment is custom and relatively expensive and difficult to use, but if
Pokemon GO players couldn't spoof via software you can bet that within six
months you could buy $500 GPS spoofing devices and within a year there
would be multiple manufacturers competing and driving the price down.

> On Jul 6, 2019, at 12:33 PM, Shawn Willden <
> swillden=40google.com@dmarc.ietf.org> wrote:
>
> On Sat, Jul 6, 2019 at 8:05 AM Giridhar Mandyam <mandyam@qti.qualcomm..com
> <mandyam@qti.qualcomm.com>> 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 <rats-bounces@ietf.org> *On Behalf Of * Shawn Willden
>> *Sent:* Saturday, July 6, 2019 7:25 PM
>> *To:* Michael Richardson <mcr+ietf@sandelman.ca>
>> *Cc:* rats@ietfa.amsl.com
>> *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 <mcr+ietf@sandelman.ca>
>> wrote:
>>
>>
>> Shawn Willden <swillden=40google.com@dmarc.ietf.org> 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 | swillden@google.com |
>>  720-924-6645
>>
>
>
> --
> Shawn Willden | Staff Software Engineer | swillden@google.com |
>  720-924-6645
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
>

-- 
Shawn Willden | Staff Software Engineer | swillden@google.com | 720-924-6645