Recent press coverage has highlighted consumer fears about beacons “tracking your every move.” In reality, typical beacons don’t collect data since they are one-way devices—they only broadcast. It’s the smartphone that invades people’s privacy by knowing where the beacon is located and what services it offers through the smartphone applications.

By the way, smartphones can do this without beacons by using GPS, Wi-Fi, and cellular. It’s just that beacons are lower power and cost less to deploy, thus enabling a new usage model. Keep in mind that users can also disable all these “location-based services” in their device settings.

IT professionals and business people are also concerned about beacon security risks. But again, this implies functionality that beacons don’t have: they’re typically one way devices, sending but not receiving information. That said, beacon security in some applications is important, not only for on-going operation but also for beacon deployment.

IT professionals need to protect their incoming beacon network traffic (if any) to the same levels as they do the rest of the devices on their network, or at least to the level the beacon hardware can accommodate. For beacon broadcasting, unless it is part of a proprietary network, it’s unencrypted by definition.

In some beaconing applications where proximity to the beacon may have tangible value, such as reward points or entering a store, the provider may need to implement safeguards against spoofing. This could include simple timestamps, the use of ephemeral IDs or randomized security keys, generated with each proximity event and validated by the back-end system.

When a beacon is deployed or upgraded in the field, it goes through a configuration process. This is likely when the beacon is most susceptible to security breach. In these cases, the beacon can use Bluetooth’s security features (i.e., pairing, authentication, encryption, etc.), and other security measures implemented by the beacon OEM, such as strong password protection.

For deployment, access to configuration services can be limited to a short time window. After the time expires, the device becomes a normal broadcast beacon and no longer advertises its internal services. This process is illustrated below.

Flowchart for a time-limited provisioning window.

The Silicon Labs experts have put some very relevant information in a whitepaper on developing with Bluetooth beacons. The goal is to help you get to market quickly with the right, stable solution. It covers a lot of territory, as it:

• examines beacon applications to help you brainstorm some of your own.
• provides a short history of Bluetooth and its derivatives, including Bluetooth low energy and beacons.
• covers the leading beacon pseudo-standards at a high level, and in detail in the Appendix.
• provides references to field-hardened example code and tools to develop and deploy it.
• provides information on end-to-end solutions to get you started.

Joe Tillison is a Senior Manager at Silicon Labs. Previously he worked at Bluegiga (a company that was acquired by Silicon Labs) as a director of business development for the Americas West region. Joe spent his early career as a hardware designer on a number of electronics platforms for NASA and military spacecraft at Lockheed Martin Space Systems. He holds a BSEE degree from the University of Oklahoma and an MSE from the University of Colorado, and he has published numerous articles and conference presentations on wireless technologies.