Last week we hosted a webinar on beacon security, possible threats, and how to protect your beacon infrastructure. During the Q&A session after the webinar, we received a lot of great questions. We’re answering them all here for your convenience. If you didn’t watch the webinar live you can still watch the recording where our head of marketing & head of software provide you with a thorough explanation of Kontakt.io Secure and how it keeps your beacons safe.
If you have any questions that we didn’t already answer, leave them for us in the comments below!
UPDATED: 15 October 2015
1.1 Will this new set of features, the Kontakt.io Secure Suite, be released as a beacon firmware update?
1.2 Is the implementation of Kontakt.io Secure Suite obligatory?
1.3 The next Kontakt.io beacon firmware update will change the way communication between beacons and managing devices works. What does it mean to me? Is there any action that needs to be taken from my side?
1.4 If I give the Kontakt.io API and SDK to my developers, Is there anything for the non technical person to stress about in order to implement the new security suite properly?
2.1. Does Kontakt.io Secure apply to all Kontakt.io beacons?
2.2 Is there extra cost for using the enhanced security? What is the business model?
2.3 What impact does implementation of Kontakt.io Secure have on battery life?
2.4 Is encryption implemented on the hardware of the beacons?
2.5 Is there any added latency with this new security feature- i.e. lag time between content update from http api or device?
2.6 What will happen if your beacon database gets hacked? Is there any other way to change your beacon password other than to physically update it?
2.7 Does this mean that a DDOS attack is easy to do by sending malformed packets? Is there a way to block the sender of the malformed packets?
2.8 It is 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 (i.e., by developers) and no one else, right?
3.1 Can I shuffle every value - MAC Address, UUID, Major, and Minor using Kontakt.io Secure Beacon Shuffling?
3.2 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?
3.3 Once new configuration is set in the cloud, does the shuffling feature require an application using Kontakt.io 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 Kontakt.io SDK to be in proximity of a beacon every day?
3.4 How near should a beacon be to change its configuration using an authorized application?
3.5 Can overlaps in shuffling happen? e.g. two beacons at the same installation shuffle the same values at the same time?
4.1 Are other beacons (i.e., Estimote, Gimbal, etc…) compatible with the Kontakt.io API and SDKs? Could we deploy a mix of beacons, along with Kontakt.io API, to deploy a secure beacon project? or would they need to only use Kontakt beacons?
4.2 How do we add other 3rd party beacons to the Kontakt.io Cloud?
4.3 Will current mobile apps work in a mixed beacon environment? Can I use other vendors (Estimote) along with Kontakt.io beacons? Will the security work in this scenario?
5.1 Can you access the same level of security using iBeacon and Eddystones? Does these new security features apply to iBeacon and Eddystones?
5.2 If so, when will an Eddystone equivalent be available?
5.3 How does this new update effect Eddystone beacon set to broadcast URL?
Yes, the Kontakt.io 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 Kontakt.io Admin App.
It’s important to note: before updating from firmware version 3.1 to our Kontakt.io 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.
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.
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 Kontakt.io 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.
No, you do not have to do anything more. The only requirement for the security suite to be working properly is to implement Kontakt.io API and SDK into your solution and then update your beacons' firmware.
It's up to you if you want to enable security features on your beacons. You will be able to order beacons with Kontakt.io Secure enabled (with firmware 4.0 or higher) or regular ones without security features (firmware version 3.1).
We believe that bulletproof beacon security should be a basic expectation from a beacon manufacturer. As such the Kontakt.io Security Suite is free to all Kontakt.io customers in its default configuration, which includes daily shuffling of beacon values and a limited advance storage of device shuffled values for applications.
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.
It is implemented on firmware level.
This depends on whether the resolved Major & Minor values are stored in the application (or your SDK) or not. If 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.
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?
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.
Yes it is. This is exactly why we created secure and timely-limited way of sharing of beacon fleet. The Kontakt.io Sharing API makes that possible.
You can shuffle everything but the UUID.
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.
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 recognise the beacon.
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.
It’s statistically somewhere in the “1 in several trillion” chances.
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! 🙂
Yes you can, but you must use different UUIDs in order to avoid beacons broadcasting same values at the same time. Kontakt.io Secure will not update any beacons that are not registered in our API.
Yes, we will have support for both iBeacon and Eddystone.
This will only apply to the Eddystone-UUID frame type, not the TLM or URL ones.
Didn’t find your question? Leave it below or drop us a line.
Note: Updated on 15 October 2015 to clarify a few answers, fix a few typos, and also update with new information about how beacon shuffling works on beacons themselves.