Are iBeacon advertising IDs unique?

问题:

We are discussing a large scale deployment scenario with iBeaons in several locations cross-country. The question was raised as to whether the IDs with which iBeacons advertise their presence is unique? Because our client wants to be really sure that the app only responds to a specific iBeacons and not to something else that's impersonating with the same ID (even if inadvertently).

If not unique, does the protocol allow iBecaons to advertise any additional authentication information?

回答1:

It is absolutely possible to impersonate another iBeacon. I went to the Apple Store in Washington DC with a copy of the Android iBeacon Locate app, and used it to scan the identifiers of the iBeacons in Apple's store. I then went back to my office and configured my own iBeacon to transmit this same three-part identifier, and was able to make my iPhone get the same in store messaging from Apple. You cannot stop other people from doing this if they really want to. But the good news is that for most use cases, there isn't a real motivation for other people to do this.

That said, an inadvertent overlap of iBeacon identifiers is extremely unlikely. If you generate your own ProximityUUID using a standard UUID generator, the odds of another generated ProximityUUID being accidentally the same are infinitesimally small -- less than the odds of being hit by a meteorite.

Standard iBeacons do not have any other authentication mechanism. They are connectionless, transmit-only devices that only send out a three-part identifier (Proximity UUID, Major, Minor) and a transmitter power calibration value.

回答2:

I work on the beacons at Gelo ( http://www.getgelo.com ). Payload confidentiality and anti-spoofing are very large concerns with a few of our customers.

UUIDs themselves are not guaranteed to be unique. It is entirely possible to spoof an UUID and all of their advertisement data (including major/minor). This presents a number of security risks.

There are rotational UUID schemes that some beacon manufacturers employ in whice every X minutes, seconds, or hours the UUID itself is changed. This would mean that someone wanting to intercept and/or spoof the beacon would need require either being in the same location as the original device and constantly matching the new values or figuring out the rotational scheme or algorithm.

The problem with rotational UUID approach is that it doesn't protect the payload (the advertising message or the scan response) so an attacker could mimic another beacon and change the value(s) being sent. Based on what the beacon communicates and how it's used by any listening devices (observers, centrals in BLE terms) or consuming applications this could not be a problem or it could be a very large problem.

We've spent time researching how-to mitigate the risk at all levels while taking into account power consumption. This is because most BLE beacons run on batteries and you want to extend the battery life as much as possible. We've come up with an approach that successfully mitigates the risk for an international organization with nearly 100k locations.

Solving this problem is possible and it's something that we've been working on. If this is what you're looking for give Gelo a call or email. We may be able to help you.

回答3:

There is definitely no "UUID anti-spoofing" in place in iBeacon technology. In fact, many developers make the situation even worse and just use the default UUID provided by the iBeacon vendor. As a result, whenever you go - lets say - around an Estimote iBeacon, you see an app that is not valid in the current context, therefore just adding to users' confusion.

You can help preventing this issue and keep the environment cleaner by using globally unique proximity UUID generator and catalogue for your deployment.

See our OpenUUID service, that aims to do exactly that...

回答4:

iBeacon ids are 20bytes (16 byte UUID, plus a 2-byte "Major" number and a 2-byte "Minor" number). The odds that someone will guess or accidentally choose all 20 bytes exactly the same AND be in range of the same beacon at the same time are extremely small. The combination of the near-unique number and relative short range of the BLE signal make an accidental collision pretty unlikely.

回答5:

In addition to sensing the above mentioned parameters you can usually get info about the beacon mac address. If it´s based on any of the more common circuits such as the TI CC240x chips the MAC address is hardcoded unique to every chip. So that one is less easy to spoof.

One typical idea if you are both beacon deployer and app provider is to program some custom service/characteristic into the beacon as well so that your app can connect to it and verify it´s a known beacon. BUT if you at all allow someone to connect it means the beacon is extremely sensitive to a Denial of Service attack. Most beacons are single tasking and cannot radiate and id and handle a connection attempt at the same time. So some dark force could install "beacon timewaster modules" in the vicinity that keeping your beacons busy talking to a waster rather than providing the id radiation you want them to. Those rotating UUID schemes may be good enough in a hostile environment. For the most part I would say the beacons are likely to work pretty much undisturbed. It is very easy to develop a beacon quality monitoring app or custom BLE device that will keep listening for deployed beacons and report on the uptime. That way a deployer of a deployed farm of beacons will be alerted if a node goes out of service.