Beacons are becoming more and more popular solutions for tracking objects in real-time. In this post we'll discuss the limitations of the technology in regards to security, and how to overcome those limitations. We'll describe current solutions for the Bluetooth 4.0 beacons, as well as propose more efficient solutions in terms of required backend infrastructure and phone battery consumption for Bluetooth 5.0, which is currently entering the market.
What is a beacon?
A beacon is a Bluetooth device that uses the Bluetooth advertisement packages, a part of GAP protocol, to send data instead of paring with another device. There is an additional restriction on the format of broadcasted packages. Bluetooth in standard 4.x allows to send up to 32 bytes of data, and beacon standard uses that data to encode minor, major and UUID of the beacon with a combination of additional information required by GAP protocol. There is no magic, beacon sends 16-byte UUID combined with 2 byte long minor and major identifiers (4 bytes in total).
Because of that, it's relatively easy to spoof beacons. Everything that's required is to obtain the UUID, minor and major number, which are advertised in plain text. There are companies producing micro-controllers that provide apps that allow easy beacon spoofing, as for example Nordic App.
Spoofing a beacon
Spoofing a beacon allows someone to clone an existing beacon, and to create another beacon with the same ID. Spoofing is not a big issue if beacons are used for convenience. An example of a convenience use case would be beacons in museums. A beacon can be placed next to a painting, and provide details about the painting when the visitors come close, through a mobile app.
Spoofing becomes a bigger issue if you have to rely on the beacon to ensure someone's or something's current presence in a given location. For example, let's assume you are running a promotion for a nearby café to everybody who visits the museum. Visitors would only receive the special offer to the café when they are close to a specific beacon inside the museum. However, a malicious third part could copy your beacon triple and produce a fake beacon out on the street. So people outside of the museum could get the special offer since there is a copy of your special beacon outside of the museum. That would ruin the strategy of the café promotion.
How to secure beacons
Bluetooth 4.0 beacon
The solution for beacon spoofing is to add, on top of existing GAP protocol, additional logic that will prevent spoofing. We have to work in boundaries of Bluetooth standard to not lose compatibility with all standard beacon libraries.
One way to do this is to periodically change the beacon UUID and minor/major numbers according to some algorithm. This approach requires you to implement the same logic on the server side that would resolve the underlying beacon based on ephemeral values scanned by a mobile application. This is what Eddystone and kontakt.io are doing.
One way to implement this is to derive the beacon triple from some hashing function, for example SHA3 (seed + sequence). It requires setting up seed for the beacon and the backend server. This can be done using a standard Bluetooth connection, beacons are usually based on chips that support a standard operation besides beacon mode. Another way is to set it when preparing firmware for a specific beacon. For obvious reasons, the seed cannot be part of a mobile application. It can be extracted, and all anti-spoofing would be for nothing since an attacker can recreate the sequence of beacons triples. This is why it has to be stored and resolved on the server side.
It's also possible to use asymmetric cryptography to further secure communication between a beacon and a service application when exchanging seed that will be used for beacon triple generation.
While this solution works fine, it requires an additional call to the backend server usually hosted by the beacon vendor. This call allows to resolve which beacon is in proximity base on a received ephemeral triple. Also on the backend, you have to implement a resolving logic. Google Eddystone solution (section 3.3) assumes that all ephemeral triples are generated on the backend and kept as pairs with real triples in the database. This is another limitation for the frequency of triple rotation since you must generate a mapping for all your active beacons along every tick. With Bluetooth's new specification, there may be a way to eliminate this dependency for beacon resolving.
Bluetooth 5.0 beacon
The new Bluetooth standard gives us more options. The new standard length of the GAP package is extended from 32 to 255 bytes. This allows us to add more information into the advertising package that the beacons send out. Also, Bluetooth 5 allows chaining advertisement packages, which allows even more data to be pushed from the beacon to the edge device (e.g. Raspberry Pi or a mobile phone).
This additional space for data can be used for transferring sensor data from sensors attached to a beacon, but it can be used for other purposes as well. For example, it can be used to add some authentication data that changes over time to prove that the person or the application reading a particular beacon is actually in near proximity of the beacon instead of spoofing it.
The idea is to transfer some signed data, concatenated with a sequence number and a beacon triple to prevent replay attack, to make spoofing impossible without knowing the private key used for signing. In this way, there is no need of sharing secret seed, you are just sharing a public key which does not require any secure channel to do so.
This, of course, requires a lookup for the public key on the server side to be sure that private/public key pair is recognized as valid for given beacon, none the less to eliminate the need of establishing a secure channel communication with the beacon device.
The solution that eliminates the need for lookup can send a signature and a certificate using Bluetooth GAP packages, optionally with chaining. The certificate can be issued by a beacon vendor for the key pair used for signing. This way, a mobile app can validate if the beacon is spoofed or authentic by itself, it only needs one public key to validate the certificate. In the process, this saves network round trip to the server and reduce battery usage. This approach mimics one that is implemented and widely tested in web browsers world where there are certification authorities issuing certificates for particular domains.
In the case of beacons certification, the authority can be a beacon vendor or a company developing the app. To implement such solution, there is a need for a custom software on the beacon side, and the beacon has to correctly formatted GAP package. It has to pack necessary beacon triple data, and after that pack signed data and certificate. Sounds complicated, so let's see what hardware and software you need to implement something like that.
Open source hardware
First, let's look into hardware that is easy to prototype on. There are open source beacon designs like Ruuvitag that you can order. Or, if you want you can use hardware design files to order PCB from services, like jlcpcb and you can solder it yourself.
The mentioned Ruuvitag board contains of a Nordic nrf52 chip which is an ARM-based micro-controller. The same is used in kontakt.io beacons. This chip has to be flashed with firmware, which you have to implement yourself. There is a SDK provided by NordicSemiconductors that works with GCC compiler. There are also examples of Beacon firmwares that you can use as a starting point for your project.
The last thing is to flash your firmware onto the chip. To do so, you have to use a JLink programmer, which is an expensive tool if you are using it for commercial purposes. There is a workaround for this that should be fine in the prototyping phase. There is a development kit provided by Nordic which costs around $ 50 that has a nrf52 chip and an integrated JLink chip with routed out programming pins. You can use this development kit with some jumper wires with breadboard to program Ruuvitag and do some field testing.
In case of any issues, you can always search or ask on stack.
Open source software
Besides using an open hardware you can also use an open software for your beacon. There is very good and secure library for ECC on the ARM that is perfect for the discussed example. It allows you to sign data and algorithms used in that library to prevent side channel attacks.
Android, since version 8.0, supports Bluetooth 5 GAP packages, the type of packages used by beacons. To scan for them you have to start Bluetooth Low Energy scanning, and if you get the Bluetooth 5 package, you will get a longer package in ScanCallback.
The only thing that is left, is to design a package structure of additional data packed into the GAP advertisement of a beacon.
As you can see with the new version of Bluetooth, there are many new opportunities to explore as well as options to introduce familiar concepts in a new context.
P.S. If you're interested in developing a project with location-based or proximity-based features, you should try our solution! Register today, and try our service for free until the rest of the year of 2018.
The chip that supports Bluetooth 5.0 https://www.nordicsemi.com/eng/Products/Bluetooth-5
Library for crypto on beacons
Open source beacon design
Google Eddystone beacons
Details about new advertising packages for Bluetooth 5 http://blog.bluetooth.com/exploring-bluetooth5-whats-new-in-advertising