Frequently Asked Questions about Secure

Next Beacon firmware update

Will this new set of features, the Secure Suite, be released as a beacon firmware update?

Yes, the Secure Suite will be released as a beacon firmware update. It will be available as an “over the air” update, which means that you will be able to update your beacons to the new firmware via the Admin App.
It’s important to note: before updating from firmware version 3.1 to our Secure firmware (4.0 or higher), be very sure that you want to enable the new security features. Updating your beacons will enable security features but also it will change the way communication works between your beacons and managing devices. If you have already deployed beacons and you don’t account for the differences in communication protocol between 3.1 and 4.0, your apps may not function correctly with your beacons any more.

Is the implementation of Secure Suite obligatory?

Nope. If for you don’t care to use security because you think it is not important (although we think for most use cases it is) we do not require that you do so.
In this case make sure you do not update your beacon firmware to v4.0 and they will continue working as they have been. Just please note that we recently dropped support for firmware version 3.X or below.

The next beacon firmware update (4.0) will change the way communication between beacons and their managing devices works. What does it mean to me? Is there any action that needs to be taken from my side?

Yes, because with the new beacon firmware update, we change the way beacons communicate with the devices that manage them by encrypting the communication and configuration channel. In order to be able to communicate with your beacons you need to be using our Proximity API. This brings new functionality to your beacon deployments, though, because it is now possible to securely manage and monitor your fleet of beacons via our SDK implemented into a third party app, as the password is not stored in any way. This means that, for example, if you were Facebook and you installed our Proximity SDK, anyone with the Facebook app installed would be able to update a beacon’s configuration securely.

If I give API and SDK to my developers, is there anything for the non-technical person to stress about in order to implement security suite properly?

No, you do not have to do anything more. The only requirement for the security suite to be working properly is to implement API and SDK into your solution and then update your beacons’ firmware.


General questions

Does Secure apply to all beacons?

By default our beacons are shipped with the latest firmware version, which means they already have the secure enabled.


What impact does implementation of Secure have on battery life?

Security features have a very limited effect on beacon battery life and, due to the change in how the beacon “listens” to new configurations, may even save a little bit of battery life.

Is encryption implemented on hardware of the beacons?

It is implemented on firmware level.

Is there any added latency with this new security feature- i.e. lag time between content update from http api or device?

This depends on whether the resolved Major & Minor values are stored in the application (or your SDK) or not. If an application must resolve the values with from our API on fly, then there can be some lag, but by default we enable storing the next 7 days’ worth of configurations locally in your mobile application.

What will happen if your beacon database will be hacked? There is no other way to change beacon password, but only physically?

Let’s address the database hacking. We protect our DB with the latest industry standards. It’s not accessible without private VPN. IF we spot the hacking intent, we’ll take some corrective measures. Therefore, the risk is very low. Beacons will remain updateable OTA, so if you implement our SDK, then your customers will be able to update your beacon passwords just by walking by the devices, which means you can crowdsource the update to your own clients. Nifty, no?

Is a DDoS attack is easy to do by sending malformed packets?

While we do limit connectivity to a device if it receives a malformed configuration packet that is addressed to it, there’s no risk that you will not have your beacon broadcasting due to this.

Is it possible to create an infrastructure of beacons and to profit from it by adopting a pay per use model? Of course, the infrastructure can be used only by my clients (developers) and no one else?

Yes it is. This is exactly why we created Secure and timely-limited way of sharing of beacon fleet. The Sharing API makes that possible. Secure Shuffling

Can I shuffle every value – MAC-Address, UUID, Major, and Minor using the Secure Shuffling?

You can shuffle everything but the UUID.

Can I decipher the real beacon UUID, Major, Minor on the device, or do we need to contact the server to get the actual beacon identifiers?

You need to resolve the real values with our API or by using our SDK to get the value either on the fly or cached in advance locally.

Once new configuration is set in the cloud, does the shuffling feature require an application using SDK to be in proximity of the beacon? For example, if beacon UUID has to be rolled every day, does it require an app with SDK to be in proximity of a beacon every day?

Actually, no. Once the beacon has shuffling turned on, it generates the new Major, Minor, and MAC address values itself using a simple algorithm. The algorithm is modified with a simple seed value that is known only to the beacon and the API. With the algorithm and the seed value, you will always generate the values for Major, Minor, and MAC address in the same order. This means that we don’t need to maintain a connection between the beacon and the API; we just need to know which “iteration” of the beacon’s shuffled value the beacon is currently on.

For security purposes, we don’t pass the algorithm or seed on to a mobile application because then someone could reverse engineer all possible values for a beacon. Instead, we allow you to cache a set number of shuffled beacon Major, Minor, and MAC address values on your Android or iOS application (so that you don’t have to update your app’s storage every day) and then also let you check it live at any time.

The beacon, since it knows its algorithm and seed value, will continue to step through the shuffled values on its own for as long as the battery lasts. Once the battery dies or is pulled out, the current shuffled value is stored and will be what the beacon broadcasts once it is connected to power again. Even if it’s been long enough that the SDK doesn’t have the value stored in memory, the API will still recognize the beacon.

How near should a beacon be to change its configuration using an authorized application?

That can very widely; generally, you figure that the beacon needs to be visible by the device that is managing it. Depending on your Tx power, that can be 1 meter or 50 meters.

Can overlaps in shuffling happen? e.g. two beacons at the same installation shuffle the same values at the same time?

It’s statistically somewhere in the “1 in several trillion” chances.


Compatibility with other beacon hardware

Are other beacons (Estimote, Gimbal…) compatible with the API and SDKs? Could we deploy a mix of beacons, along with API, to deploy a secure beacon project? or would they need to only use beacons?

If you want to create secure installation, you must have your beacons imported into our API. Currently, we don’t have a way to import third-party beacons, although if you can do it on your own you’re welcome to–and please tell us how! :)

Will current mobile apps work in a mixed beacon environment? Can I use other vendors along with beacons? Will the security work in this scenario?

Yes, you can, but you must use different UUIDs in order to avoid beacons broadcasting same values at the same time. Secure will not update any beacons that are not registered in our API. Secure on iBeacon vs. Eddystone

Can you access the same level of security using iBeacon and Eddystones? Does these new security features apply to iBeacon and Eddystones?

Yes, we will have support for both iBeacon and Eddystone.

How does this new update affect Eddystone beacon set to broadcast URL?

You can shuffle Eddystone beacons’ MAC address and Instance ID but Eddystone-URL doesn’t work with shuffling.

- 2017-10-25 16:43:56 UTC
Was this article helpful?
0 out of 0 found this helpful



This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Review our cookies information for more details.