Subject: Re: [Rats] Android comments on EAT draft

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 14:27:57 -0400

Shawn Willden <swillden=[email-masked]> 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"

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

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

    > Again, my apologies for jumping in late.  Let me know if you think EAT
    > just
    > isn't appropriate for Android.

I'm very happy you will some cycles now!

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Shawn Willden <[email-masked]>
Date: Sat, 6 Jul 2019 07:54:31 -0600

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

Great!

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

> 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 | [email-masked] | 720-924-6645

---

From: Giridhar Mandyam <[email-masked]>
Date: Sat, 6 Jul 2019 14:04:52 +0000

>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 <[email-masked]> On Behalf Of Shawn Willden
Sent: Saturday, July 6, 2019 7:25 PM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Great!

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.

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 | [email-masked]<mailto:[email-masked]> | 720-924-6645

---

From: Shawn Willden <[email-masked]>
Date: Sat, 6 Jul 2019 13:33:57 -0600

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

> 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 <[email-masked]> *On Behalf Of * Shawn Willden
> *Sent:* Saturday, July 6, 2019 7:25 PM
> *To:* Michael Richardson <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Rats] Android comments on EAT draft
>
>
>
> *CAUTION*: This email originated from outside of the organization.
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Jul 2019 17:48:05 -0400

> relying party to be the network?

It's a good point, and maybe we can come up with a better term that is well
understood.   The attestations are occuring in order that the network
operator is willing to accept the device is sane.

---

From: Simon Frost <[email-masked]>
Date: Mon, 8 Jul 2019 11:57:35 +0000

-----Original Message-----
From: Michael Richardson <[email-masked]>

> operator is willing to accept the device is sane.

"Associating Attestation" perhaps? That covers both the RP being a network operator accepting a device and the RP being the consumer of a service which is hosted on a device. In both cases the attestation request is a necessary part of building the trust to form the partnership.

Thanks
Simon

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 10 Jul 2019 21:18:48 -0700

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jul 2019 08:04:16 -0400

Laurence Lundblade <[email-masked]> wrote:
    > 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-spooFable. 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.

I think that Shawn's point is that the Android privacy team wants
to be able to send location data which can be spoofed without relaying
parties knowing that it is spoofed.

---

From: Shawn Willden <[email-masked]>
Date: Thu, 11 Jul 2019 06:04:54 -0600

On Wed, Jul 10, 2019 at 10:18 PM Laurence Lundblade <[email-masked]>
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=[email-masked]> wrote:
>
> On Sat, Jul 6, 2019 at 8:05 AM Giridhar Mandyam <[email-masked]..com
> <[email-masked]>> wrote:
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 15 Jul 2019 14:07:15 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of swillden=[email-masked]<mailto:swillden=[email-masked]>> wrote:

On Wed, Jul 10, 2019 at 10:18 PM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> 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.

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=[email-masked]<mailto:swillden=[email-masked]>> wrote:

-Giri Mandyam, Qualcomm

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

Great!

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.

--
Shawn Willden | Staff Software Engineer | [email-masked]<mailto:[email-masked]> | 720-924-6645
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 16 Jul 2019 01:25:35 +0000

+1

发件人: RATS [mailto:[email-masked]] 代表 Smith, Ned
发送时间: 2019年7月15日 22:07
收件人: Shawn Willden <swillden=[email-masked]>; Laurence Lundblade <[email-masked]>
抄送: Michael Richardson <[email-masked]>; Giridhar Mandyam <[email-masked]>; [email-masked]; Henk Berkholz <[email-masked]>
主题: Re: [Rats] Android comments on EAT draft

-Ned

Completely agreed.

-Giri Mandyam, Qualcomm

Great!

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 15 Jul 2019 20:22:13 -0700

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 <[email-masked]> wrote:
> 
> On 7/11/19, 5:05 AM, "RATS on behalf of Shawn Willden" <[email-masked] <mailto:[email-masked]> on behalf ofswillden=[email-masked] <mailto:swillden=[email-masked]>> wrote:
>  
> On Wed, Jul 10, 2019 at 10:18 PM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Jul 6, 2019, at 12:33 PM, Shawn Willden <swillden=[email-masked] <mailto:swillden=[email-masked]>> wrote:
>>>  
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>>  
>> 
> 
> 
>  
> --