11

A thought: The list of URL's is ranked by signal strength. What's stopping someone from increasing the broadcasting strength of their beacons so that they rank first?

What else could be done?

For anyone unfamiliar with the Physical Web: https://google.github.io/physical-web

Basically, the Physical Web is a discovery service powered by bluetooth low energy beacons. Smart objects broadcast relevant URLs that any nearby device can receive.

Dmitrii Anikin
  • 111
  • 4

2 Answers2

2

A more serious attack vector is phishing or distributing malware. Set up a beacon with a legitimate and/or appealing name, broadcasting a malicious link. Given that (at least for now) this will mainly be used with Android you'd have way more success considering the security record of those devices. (but of course, Google prefers to play with beacons rather than fixing way more important issues like that one).

A solution would be to have CAs just like in the X509 world where the client software that listens for the beacons checks the broadcast's signature against its trust store, and to register a beacon you'd have to obtain a certificate from a CA which will perform verification on what you want to broadcast (so Honest Joe can't make a beacon named Bank and broadcast a phishing link).

Against broadcast strength amplification attacks the client devices should "ping" the beacons and observe how long it takes them to respond. With that you can calculate the distance to the beacon based on the speed of light in air. You can have a very strong signal, but if the beacon is physically far away it would still take a (relatively) long time to respond. However that opens up a different issue, if the client devices are now pinging beacons, then you have a privacy issue because client devices can now be detected and tracked.

André Borie
  • 12,706
  • 3
  • 39
  • 76
  • "A more serious attack vector is phishing or distributing malware." The Physcial Web Service (PWS) is the service the client (i.e. phone) sends a URL to in order to gather metadata about the URL. Ideally, the PWS should filter bad URLs. Google's PWS already does this with standard Google technologies. Also, the URL is displayed in the client, so the user at least has the opportunity to read it. There's room for improvement, but fixing inherent trouble spots of the web, which no one has managed to do since its inception, is beyond the scope of the Physical Web. – Conley Owens Aug 29 '16 at 14:26
  • "to register a beacon you'd have to obtain a certificate from a CA" Part of the benefit of the Physical Web compared to other technologies is that it *doesn't* require registration. However, many of the clients at the moment only display URLs that have HTTPS enabled, so that mostly accomplishes what you are going for, just by building on the power of the web, without inventing new technologies. – Conley Owens Aug 29 '16 at 14:29
  • "then you have a privacy issue" You also might have a power issue depending on how you would accomplish this ping back. Part of the benefit of beacons is that in only broadcasting and not engaging in any two-way communication, you can build some very cheap, very low power devices. – Conley Owens Aug 29 '16 at 14:32
  • @ConleyOwens displaying the URL doesn't matter much if you're interacting with that particular device for the first time - I've never paid for parking online, so city-parkingmeter.com would look totally trustworthy. HTTPS doesn't solve the problem of the beacon's name - an "ATM" beacon next to an ATM would still do plenty of damage, even though the site it redirects to is something fishy, but it'll still be HTTPS because the attacker has genuine control over the domain and can obtain a cert. – André Borie Aug 29 '16 at 22:44
  • Understood, but the device you are interacting with always has the ability to display its URL or to signal that it's properly been connected to. – Conley Owens Aug 30 '16 at 13:02
0

The list of URL's is ranked by signal strength.

This is only true of some clients, and not even most. The Chrome client and the prototype Physical Web prototype app on GitHub both sort by a distance estimate, which is calculated from the signal strength and TX power. The TX power is what the beacon claims its broadcasting strength is.

What's stopping someone from increasing the broadcasting strength of their beacons so that they rank first?

Given the previous notes, the real question is what is stopping someone from decreasing the TX power of their beacons so that they rank first. This is something we've actually seen in the wild. Currently there isn't a single solution; as I said, different Physical Web clients display results with different orderings. However, given that there typically aren't many beacons around, even in denser areas, it's atypical that one has to worry about being below the fold. Thankfully, we'll have some time to deal with this issue as it becomes more prevalent.

One could imagine that eventually ranking will not be based merely on crude values such as a distance estimate, but on a combination of those values with other metrics (previous engagement, etc.). At that point, advertising a false distance would only hurt a beacon's ranking---it would look like a poor result if it's not selected even when very close.

Conley Owens
  • 101