Re: [Rats] [ietf-rats-wg/eat] please get Google Android team review of Location Claim (Issue #292)

[Giridhar Mandyam <[e-mail]>]

Agree with below.

Moreover, sensor data is rarely fully self-contained within the security boundary of the attester.  An example is biometrics, which should have their own built-in defenses against spoofed data (e.g. latex fingerprints, still imagery presented for facial recognition, etc.).   The FIDO Alliance’s biometric certification program as a result validates the biometric’s performance with respect to spoofed data, and FIDO standards define how to attest to a biometric authenticator.

Given that location can be determined via a detection of an externally-originated signal (e.g. GPS satellite emission, although this isn’t strictly required in most GNSS engines of which I am aware) then presumably such signals are subject to spoofing.  The GNSS engine can provide information on spoof detection to the attester, which in turn can determine whether to include the location data in an attested claim or not.  I don’t think EAT should be prescriptive on how location data is determined, because there are many possible implementations (including unfortunately GNSS engines that do not detect spoofed satellite signals or detect them with poor confidence).

I am not sure what the security guidance text should look like except for stating that determination of trustworthiness of sensed data is beyond scope of the EAT specification.

-Giri

From: Laurence Lundblade <[e-mail]>
Sent: Monday, September 19, 2022 11:13 AM
To: rats <[e-mail]>
Cc: Giridhar Mandyam <[e-mail]>; Michael Richardson <[e-mail]>; Smith, Ned <[e-mail]>
Subject: Re: [ietf-rats-wg/eat] please get Google Android team review of Location Claim (Issue #292)


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Bringing this to the mailing list from the GitHub issues.

I don’t think we can specify trustworthiness or security of any claim. If we try, we’ll be here forever. Security-level is the poster child. :-)

For example, we do say that UEID is a permanent identifier, but we don’t say how well defended against attacks to change it must be. (iDevID on the other hand does specify this, but iDevID is an implementation specification targeting a specific security level, not a broad message/protocol specification).

Thus claim definitions are really about semantics, not security and trustworthiness. Pretty sure all the claim definitions in EAT are about semantics only.

I think it would be reasonable to say this in the security considerations section, perhaps making an example out of location. It can say that the relying party must come to know how secure a particular EAT and the claims in it are by getting information from the attester vendor and/or the verifier operator.


On Sep 19, 2022, at 8:30 AM, Ned Smith <[e-mail]<mailto:[e-mail]>> wrote:
It should be noted that location depends on external entities (satellites) for its values which an Attesting Environment can't be certain are correct (as a jamming attack could alter geo-coordinates).
Yes, noting this security considerations is probably a good idea.


The RATS architecture expects the Attesting Environment is design in such a way that the Target Environment can't lie about the measurement produced.
This is not true for EAT. It intentionally has no security design requirements. Pretty sure this is true for RATS architecture too.

In the case of location claim, these exceptions should be noted.
Yes, but they are not exceptions.

LL



To go on a little about how location works

The location system in a phone these days combines many sources — satellites (maybe more than one), WiFi, cell tower and inertia. My iPhone even asked me to hold the camera up so it could see buildings in downtown San Francisco to figure out where it was. There is probably some defense against spoofing in all this, but it is probably pretty complicated and beyond our ability to specify.

The location system in a Qualcomm Snapdragon is what does all this. It’s not a part of Android. (at least that was the architecture a few years ago)

Probably different use cases care about different sorts of attacks, accuracy, altitude, speed and such. Too difficult to analyze and characterize all that.

As of a few years ago, Android definitely had a debug feature that allowed location spoofing, presumably necessary for developing apps, but not so good if really wanted location of security reasons. Qualcomm had an EAT-like product that provided location that couldn’t be manipulated like that.

I suspect the Android team would just confirm this and that Qualcomm might be the one to say how well the location information holds up to spoofing attacks. I don’t see that it is necessary to talk to them as I don’t think we can make any statements about location trustworthiness in EAT.