Re: [Rats] Android comments on EAT draft

[Laurence Lundblade <[e-mail]>]

1) Modern Location Engines
A modern location engine aggregates cell tower, WiFi and (one or more) satellite-based (GLONASS, GPS…) locations. This is what makes maps on your phone work so good. Spoofing one, doesn’t break the system. On phones the location subsystem is likely to be isolated from the HLOS (Android) and thus considered more trustworthy than some. So I don’t think the argument that GPS radio can be spoofed disqualifies it. 

2) Roots of Trust Comment
I don’t think all claims have to originate in THE root of trust. THE root of trust can sign claims that originate outside of it as long as they are marked as such. This is the purpose of submods. They can be marked as coming from the “location engine” submod and it’s security can be indicated as less / different.

I do not draw a hard distinction between attestation and telemetry such that telemetry must be excluded. I just want to mark them distinctly so the relying party knows what they are getting.

LL




> On Jul 15, 2019, at 7:07 AM, Smith, Ned <[e-mail]> wrote:
> 
> Regarding our definition of attestation, it is important to consider whether assertions are under the control of the roots of trust. If the asserted information exists outside a trust boundary, then wouldn’t this be considered telemetry? The idea of a root-of-trust for measurement implies there is a trusted way to collect assertions. That means to me (and hopefully others) that the integrity of evidence has high strength of function (where the strength of function is tied to the trustworthiness of the roots of trust and not some unknown elements used during collection).
>  
> Since location based on GPS or radio triangulation uses radio equipment that is outside the control of the roots of trust. It seems classifying it as telemetry is reasonable.
>  
> As a counter example, media players sometimes are manufactured with a region code. Designing a root of trust that contains a region code seems achievable, hence would be a good candidate as an attestable assertion / evidence that has location semantics. 
>  
> -Ned
>  
> On 7/11/19, 5:05 AM, "RATS on behalf of Shawn Willden" <[e-mail] <mailto:[e-mail]> on behalf ofswillden=[e-mail] <mailto:swillden=[e-mail]>> wrote:
>  
> On Wed, Jul 10, 2019 at 10:18 PM Laurence Lundblade <[e-mail] <mailto:[e-mail]>> 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=[e-mail] <mailto: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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>>  
>> 
> 
> 
>  
> -- 
> Shawn Willden | Staff Software Engineer | [e-mail] <mailto:[e-mail]> | 720-924-6645