Detecting physical proximity
Message # 1
Date: Mon, 13 Feb 2006
To: PracticalSecurity at hbarel.com
From: Hagai Bar-El
Subject: [PracticalSecurity] Detecting physical proximity
List,
There is this one security challenge I was brought up to believe there is no solution for, and since I happen to need one I am bringing this to your review. It's about detecting physical proximity.
I need cryptographic entity A that establishes a security association with cryptographic entity B to be able to tell if the two are physically connected, or are within some predetermined physical proximity of any type.
The usage of a trusted third party is allowed, but we cannot assume location-determination-specific hardware, such as embedded GPS chips inside the entities. Neither can we assume non-standard hardware, such as for measuring strength of radio signals.
The only way I know to obtain this information is using timing measurements of network traffic, but this method suffers from several drawbacks, so I am reluctant to use it, unless I find no other choice.
Any ideas? I realize that a complete and proof solution is probably not out there, but I am willing to hear of other "approximation" methods such as the timing one...
Regards,
Hagai.
Message # 2
Date: Sun, 12 Feb 2006
From: "Cuellar, Jorge"
To: "Hagai Bar-El"
Cc: PracticalSecurity at hbarel.com
Subject: Re: [PracticalSecurity] Detecting physical proximity
Hi Hagai,
Yes, timing measurements of network traffic could work, but it is dependent on many, many assumptions.
What type of channel are the entities using? If they are short-range, are you assuming that an "attacker" E can be close to A too?
But if A "authenticates" E as being close, this is OK, I guess.
Lat us call that case I.
Or is the attacker model the following: close to A there is one entity E. This entity E has another communication channel to entity E1 and E is just relaying the communication to E1. Thus A is talking over E to E1.
The question is then how A can notice that he is talking to E1, which is "far".
Lat us call that case II.
The problem here seems to be trust: I and II are not really different.
Suppose that A authenticates E as being close and then they do some type of key agreement. Assume it works. What hinders E at this point of time to send his keys to E1 and let, as in II, the rest of the communication happen between A and E1? Or what hinders E to send all information and receive orders from E1?
Best regards,
Jorge
-----Original Message-----
From: PracticalSecurity-bounces at hbarel.com
[mailto:PracticalSecurity-bounces at hbarel.com] On Behalf Of
Hagai Bar-El
Sent: Sunday, February 12, 2006 9:57 PM
To: PracticalSecurity at hbarel.com
Subject: [PracticalSecurity] Detecting physical proximity
List,
There is this one security challenge I was brought up to
believe there is no solution for, and since I happen to need
one I am bringing this to your review. It's about detecting
physical proximity.
(snip)
Message # 3
Date: Sun, 12 Feb 2006
From: S K
To: PracticalSecurity at hbarel.com
Subject: Re: [PracticalSecurity] Detecting physical proximity
What kind of devices are the entities allowed to operate? From your proposed possible solutions and non-solutions, cell phones and other data transmitting devices. Any others?
--- Hagai Bar-El
List,Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
There is this one security challenge I was brought up to believe
there is no solution for, and since I happen to need one I am
bringing this to your review. It's about detecting physical proximity.
I need cryptographic entity A that establishes a security association
with cryptographic entity B to be able to tell if the two are
physically connected, or are within some predetermined physical
proximity of any type.
The usage of a trusted third party is allowed, but we cannot assume
(snip)
Message # 4
Date: Mon, 13 Feb 2006
From: Yoav
To: Hagai Bar-El
Cc: PracticalSecurity at hbarel.com
Subject: Re: [PracticalSecurity] Detecting physical proximity
If you're talking about an IP-based connection, you can use TTL. No cryptographic strength, but its hard to get routers not to lower the TTL of your packets, so TTL can be faked down but not up. If two devices are on the same network, they can set their TTL to 255 and drop packets from the other party if TTL<255. In Linux, its a matter of a simple iptables ruleset.
If there's just one router between the two devices, its still reasonably secure. For anything more than that, spoofing becomes a problem. Trusted third-parties on both sides can be used to enhance security in this case: Lets assume the two parties are users connected to different ISPs. Each ISP runs a simple "proximity-server" which receives packets and returns them signed (including their headers). Each party talks to his ISP's proximity-server, which is typically 1 hop away. The party's packet, now with TTL=254, is signed and returned. Now each party can prove that its close to a specific ISP (or has a box connected to this ISP, relaying his traffic... :)
You'll also be operating under the assumption that the attacker doesn't control any devices within the defined perimeter, or a relay attack would be possible. This is true for any solution, except timing-based solutions which you'd rather not use.
btw, if you're on the same network, you may as well use link-layer packets which are not routed outside the network. For devices with a router between them, TTL may be a suitable alternative.
Regards,
Yoav
On Sun, 12 Feb 2006, Hagai Bar-El wrote:
List,
There is this one security challenge I was brought up to believe
there is no solution for, and since I happen to need one I am
bringing this to your review. It's about detecting physical proximity.
I need cryptographic entity A that establishes a security association
with cryptographic entity B to be able to tell if the two are
physically connected, or are within some predetermined physical
proximity of any type.
The usage of a trusted third party is allowed, but we cannot assume
(snip)
Message # 5
From: Simon Josefsson
To: Hagai Bar-El
Date: Mon, 13 Feb 2006
Cc: PracticalSecurity at hbarel.com
Subject: Re: [PracticalSecurity] Detecting physical proximity
Hagai Bar-El
List,Can the trusted third party be one or two humans? Display a random number on each of the device, and have the human input them into the other device. If the device owners are distinct and doesn't trust each other, have each of the device owner input the number from the other device. Try to avoid making it possible to automate the procedure in ways that would fool the device owners. Have a time-out of 30 seconds. There probably are some caveats, but something like this seem to work, and is probably sufficient for consumer-type products (e.g., payment).
There is this one security challenge I was brought up to believe
there is no solution for, and since I happen to need one I am
bringing this to your review. It's about detecting physical proximity.
I need cryptographic entity A that establishes a security association
with cryptographic entity B to be able to tell if the two are
physically connected, or are within some predetermined physical
proximity of any type.
The usage of a trusted third party is allowed, but we cannot assume
(snip)
I know this is probably not what you were looking for, but I haven't been able to come up with anything better.
/Simon
Message # 6
Date: Tue, 14 Feb 2006
To: "Cuellar, Jorge"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Detecting physical proximity
Cc: PracticalSecurity at hbarel.com
Hi Jorge,
At 12/02/06 23:20, Cuellar, Jorge wrote:
Yes, timing measurements of network traffic could work, but it isIf proximity is all that is detected to imply trust, and A trusts any entity, including E, as long as it is in proximity, then we have a big trust problem, as you indicated. It's actually barely a technical problem at this point, because once E is trusted just for being close, it can do "distant" actions with its assets. Moreover, it is even more difficult because it implies that E cannot even be trusted to follow the proximity detection protocol.
dependent on many, many assumptions.
What type of channel are the entities using? If they are short-range,
are you assuming that an "attacker" E can be close to A too?
But if A "authenticates" E as being close, this is OK, I guess.
Lat us call that case I.
Or is the attacker model the following: close to A there is one entity
E. This entity E has another communication channel to entity E1 and
(snip)
The situation is less difficult, though. We can trust A and B to follow the protocol and not to redirect "near" traffic by secondary means. So, It's not enough for E to be close so to the trusted. A trusts X if it is both authorized (following some other authentication sub-protocol) AND within proximity. Further, you can assume that an authorized entity B is trusted not to cheat the proximity protocol.
Hagai.
Message # 7
Date: Tue, 14 Feb 2006
To: S K
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Detecting physical proximity
Cc: PracticalSecurity at hbarel.com
Hello,
At 12/02/06 23:49, S K wrote:
What kind of devices are the entities allowed to operate? From yourWell, the solution is indeed for portable devices. We can assume IP connectivity, but probably nothing else we can use. Otherwise, we could use signal strength (although this is not real security) at least as a compromise...
proposed possible solutions
and non-solutions, cell phones and other data transmitting devices.
Any others?
Hagai.
Message # 8
Date: Tue, 14 Feb 2006
From: Alfonso De Gregorio
To: Hagai Bar-El
Subject: Re: [PracticalSecurity] Detecting physical proximity
Hagai Bar-El wrote:
The only way I know to obtain this information is using timingDo you mean the proximity-proving protocol proposed by Waters and Felten in "Secure, Private Proofs of Location"?
measurements of network traffic, but this method suffers from several
drawbacks, so I am reluctant to use it, unless I find no other choice.
Regards,
Alfonso
Message # 9
Date: Wed, 15 Feb 2006
To: Alfonso De Gregorio
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Detecting physical proximity
Cc: PracticalSecurity at hbarel.com
Hello Alfonso,
At 14/02/06 12:45, Alfonso De Gregorio wrote:
Do you mean the proximity-proving protocol proposed by Waters and FeltenThe proposal by Waters and Felten, if I remember it correctly, was a particular case of using timing analysis based on radio signals.
in "Secure, Private Proofs of Location"?
Unfortunately, the system in question might not have access to the underlying physical bearer, so I am not sure I will be able to measure radio latency. On the other hand, Waters and Felten do address many other aspects that are an over-kill for me, such as assuring privacy.
As it seems now, timing (on the IP level) as well as TTL (as suggested by Yoav, if proximity is measured IP-network-wise), are the only viable approaches here. It's certainly not perfect, but I guess the group agrees that that's the closest we can get.
Thanks!
Hagai.