Question

As far as I can tell, there is nothing to restrict any developer from programming their beacon to use a particular UUID, major, minor or identifier.

In the event I create an iBeacon with a UUID of "foo", what is to prevent another developer of creating a beacon with the same ID and (either accidentally or maliciously) causing my app to display incorrect data ?

Have I misunderstood how iBeacons work ? Please correct me if I'm wrong.

Was it helpful?

Solution

This is absolutely true. I have both spoofed the Apple Store's iBeacons (to prove this point) and had my beacons spoofed by Make magazine for the Consumer Electronics Show Scavenger Hunt.

This is not a flaw at all. You just need to design an app that uses iBeacons so spoofing is relatively inconsequential. If you design your app so it doesn't much matter, who cares?

The specific security mechanisms appropriate to counter this depend on the app in question, but there are countless possibilities.

For the CES Scavenger hunt, for example, we simply kept an audit log with timestamps so we'd know if somebody found all the targets impossibly quickly. In the end nobody did this -- our participants were all good sports!

OTHER TIPS

You can't prevent spoofing of the advertisement packet because there is no central authority that issues universal unique identifiers (UUID's). UUIDs are arbitrarily assigned to a beacon and are not actually guaranteed to be unique.

However, once you have paired your handheld with the beacon, the picture is different. You can program a beacon (or, more specifically, a beacon-like device) to generate absolutely unique information when paired, such as a one-time password or some private-key encrypted handshaking between your app and the paired beacon.

The typical process flow would be:

  1. handset detects ibeacon broadcast, reads UUID + Major/Minor.

  2. handset launches your app (using the didEnterRegion event).

  3. your app requests to pair with the beacon, sends it a command to generate an encrypted response.

  4. your app decrypts the response. If successful, display a happy face! If failure, display a sad face.

Moving forward, I suspect that most beacon systems will be implemented this way. Unless and until the iBeacon standard is updated to accommodate encryption, it will have to be a hybrid approach of ping + pair.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top