iBeacon non static UUID

Question

I have a problem that it's bugging me: I have some iBeacon devices (tags to be exact) and I want to create a custom new app supporting their functionality.

The problem is that every now and then the tags change their mac address (very frequently) as well as their UUID (frequently but not too frequently). The way I see it this feature has been implemented to protect users against tracking.

Now this can be hardware specific feature (I use the lasso tags) or be a standard functionality of the standard (iBeacon spec which I don't have).

Can someone please verify the intended functionality or at least give pointers to iBeacon official specification and/or other documents?

Regards

Answer 1

Recently, Apple made the iBeacon specification available on their iBeacon Developer pages: https://developer.apple.com/ibeacon/ (the "Download Artwork and Specification" link in the right-hand sidebar). You still need to accept the iBeacon License Agreement.

Some vendors use rotating UUIDs (and/or majors and minors) as a way to address security and privacy concerns, just like you said. It's not exactly what Apple intended for iBeacon (they mentioned on multiple occasions that you should plan around the possibility of beacons being spoofed, b/c iBeacon is not meant to be secure), but it's still compatible with the specification.

Most commonly, there's some known seed or secret key uploaded to the beacon during manufacturing or when enabling such security feature. Only authorized parties know the seed/key, and thus can either predict what's the UUID/major/minor of a beacon supposed to be at any given time, or decrypt it. In the end, UUID+major+minor is just 20 bytes of data broadcast by the beacon, and you can encrypt it just like any other data. (Well, actually, the problem with the iBeacon is that on the iOS side, you need to know the UUID of the beacon in order to scan for it, so at least the UUID—i.e., the first 16 bytes—need to be only pseudo-random, and can't be completely random.)

Personally, I would say this is one of the cases where the market validated the iBeacon idea/spec, and came up with a solution to a problem that Apple decided not to tackle. And I wouldn't blame them—they pretty much pioneered the beacon technology (sure, it was there before, but much less popular than it is today), and nobody at that time though about using iBeacon for tagging personal belongings.

When Google released Eddystone—i.e., an alternative beacon protocol—earlier this year, they announced at the very same time that encrypting the Eddystone identifiers will be part of the core spec:

At the same time, privacy and security are really important, so we built in a feature called Ephemeral Identifiers (EIDs) which change frequently, and allow only authorized clients to decode them. EIDs will enable you to securely do things like find your luggage once you get off the plane or find your lost keys. We’ll publish the technical specs of this design soon.

(source: http://googledevelopers.blogspot.com/2015/07/lighting-way-with-ble-beacons.html)

To me, this pretty much validates the idea of securing beacons, and rotating the UUIDs is just a clever market/community "hack" of the iBeacon spec to do just that.

Answer 2

Bluetooth LE beacons transmitting the iBeacon format, including those displaying the iBeacon certification logo, typically do not change their mac address. I base this statement on two years of experience testing these beacons from a wide variety of vendors. It is also unusual for an iBeacon to automatically change its ProximityUUID. These appear to be peculiarities that are specific to one vendor's implementation. The fact that these implementation details are unusual doesn't necessarily mean it isn't allowed -- it just means it is unusual.

Unfortunately, the iBeacon specification is proprietary and not publicly available from Apple. You need to enter a business relationship with Apple to be able to access the official documentation. That said, there is no shortage of information about iBeacons in the public domain obtained by folks who have reverse engineered the simple devices. In the absence of official public documentation, you simply have to do Google searches and use your judgement about the quality of the information you find.