As far as I can tell, there is nothing to restrict any developer from programming their beacon to use a particular UUID, major, minor or identifier.
In the event I create an iBeacon with a UUID of "foo", what is to prevent another developer of creating a beacon with the same ID and (either accidentally or maliciously) causing my app to display incorrect data ?
Have I misunderstood how iBeacons work ? Please correct me if I'm wrong.
This is absolutely true. I have both spoofed the Apple Store's iBeacons (to prove this point) and had my beacons spoofed by Make magazine for the Consumer Electronics Show Scavenger Hunt.
This is not a flaw at all. You just need to design an app that uses iBeacons so spoofing is relatively inconsequential. If you design your app so it doesn't much matter, who cares?
The specific security mechanisms appropriate to counter this depend on the app in question, but there are countless possibilities.
For the CES Scavenger hunt, for example, we simply kept an audit log with timestamps so we'd know if somebody found all the targets impossibly quickly. In the end nobody did this -- our participants were all good sports!
You can't prevent spoofing of the advertisement packet because there is no central authority that issues universal unique identifiers (UUID's). UUIDs are arbitrarily assigned to a beacon and are not actually guaranteed to be unique.
However, once you have paired your handheld with the beacon, the picture is different. You can program a beacon (or, more specifically, a beacon-like device) to generate absolutely unique information when paired, such as a one-time password or some private-key encrypted handshaking between your app and the paired beacon.
The typical process flow would be:
handset detects ibeacon broadcast, reads UUID + Major/Minor.
handset launches your app (using the didEnterRegion event).
your app requests to pair with the beacon, sends it a command to generate an encrypted response.
your app decrypts the response. If successful, display a happy face! If failure, display a sad face.
Moving forward, I suspect that most beacon systems will be implemented this way. Unless and until the iBeacon standard is updated to accommodate encryption, it will have to be a hybrid approach of ping + pair.
Related
Suppose I have three smartphones that sends a beacon with UUID: X.
Two of them have the App called True App:
The first has major:1, minor:1
The second has major:1, minor:2
The third smartphone has the App called Beacon Simulator that clone the beacon of the others two ones.
The first two should be recognise that the third is spoofing beacon.
Which is the best approach to solve this issue for both Android and iOS?
There are three common approaches to avoiding beacon spoofing:
Use a secondary transmitted identifier
You can use a secondary known identifier that is harder to copy (e.g. the bluetooth MAC address) to try and verify that the beacon identifier comes from the expected source. This technique rarely works well, however, because a determined hacker can also spoof the MAC address (or any other transmitted field) with the proper equipment. Using this approach with MAC address is also very limited on mobile devices -- iOS devices cannot read a beacon's MAC address at all, and both Android and iOS transmitters randomize their BLE transmitters periodically.
Rotating identifier hashes
There are a number of beacon systems that attempt to avoid spoofing by using a dedicated beacon format that uses a rotating identifier based on a secure cryptographic hashing algorithm. Two examples of this are Gimbal (proprietary) and Eddystone-EID (open source, but effectively run by Google). In each case, you must make a call to a server to "resolve" the rotating hash you receive from the beacon transmission and effectively convert it to a static identifier your app can use.
This approach is quite secure for many use cases, but there are major shortcomings: (a) The systems are complex and difficult to set up. (b) Network connectivity is required to resolve the identifier. If you lose connectivity or the network is slow, your app won't work. (c) The approach locks you in to specific vendors (Gimbal or Google). (d) The system can still be defeated by recording a beacon transmission in one location and rebroadcasting it in a second location.
Use secondary factors to validate the beacon detection
One example of a secondary factor is verifying the known location of each beacon. If you know the latitude and longitude of each beacon, when you see the beacon, compare the measured latitude and longitude to see if it is reasonably close. This will prevent spoofing except in close proximity. Another example might be time. If you know two different beacons will be placed over one mile apart, but your phone detects both of them within a few seconds, then you can be reasonably sure that one of the two detections was spoofed and respond appropriately. There are many, many other possibilities that are use-case specific. This approach often provides a good tradeoff between basic security and ease of implementation, provided that your use case allows it and your security requirements are not extreme.
I'm trying to build an access control system using BLE beacons and a web server.
A mobile phone will transmit a beacon signal near the gate and the beacon will be forwarded to the server to decide whether this person should pass.
The problem is transmitting a beacon without encryption is not safe, i need to encrypt the beacons.
The question is: is there an API for web applications to resolve the Eddystone EID encrypted beacon without using google web service?
Another question: is the Eddystone EID a good idea for encrypting the beacon for access control (regarding security, time, etc..)?
Eddystone-EID uses a strong hash to secure your beacon transmissions from spoofing or hijacking. However. It comes with a real cost of significant complexity, and very few hardware beacons that support the crypto functions and real time clock components needed to generate the symmetric keys needed to register them as Eddystone-EID. Since you are using a mobile phone, and not a hardware beacon, you'll need to write your own registration crypto functions based on the Google spec, which is not trivial.
To my knowledge, there are no publicly available alternatives to Google's EID resolvers, so if you choose to use this technology, you must register your beacons with Google and trust their services to make your solution work.
I developed an independent resolver server to work with Edsystone-EID early in the development process, even before Google released its own resolver. My intention was to release this to the public, but adoption of the technology was simply not sufficient to warrant the effort. Most companies have decided the downside of encrypted beacons (deployment complexity, network access required for resolution, limited hardware support, proprietary lock-in) outweigh the benefits for almost all use cases.
Be aware that Eddystone-EID is no panacea. The beacon signals can still be spoofed in short time intervals less than the identifier rotation period (configurable between a few minutes and several hours.)
One possible alternative is the proprietary Gimbal system, which is easier to use, and supplies its own proprietary hardware beacons, but otherwise has the same disadvantages as EID. However, they only work with their own hardware beacons, and don't supply a client library to transmit a Gimbal encrypted packet from a phone.
Whichever you choose, make sure this is really required for your use case, and don't commit to a solution until you experiment with one first hand.
I would like to develop an Android app that could automatically open a door (running in background) once the person running my app is near to an iBeacon corresponding to my door.
My problem is the following: since iBeacon's parameters (UUID,Minor and Major) can be seen by other users as they are public, a malicious user could clone my beacon's parameter and act as my iBeacon, causing my app to trigger the door opening even if the user with my app is not physically near a door.
Is there a way to encrypt iBeacon UUID transmission? Or to guarantee that the beacon I see is truly mine?
I found two sources, one discusses the security problems with opening doors withoutusing a physical key and one pretty funny treasure hunt with iBeacons.
In short: To securely open your car when you are near there are multiple factors checked, none of them are available on your everyday iBeacon. Estimote Beacons use a kind of pseudorandomly changing UUID to prevent attackers from spoofing the UUID like the "winner" of the treasure hunt but it is still possible to relay them over a mobile network. Cars analyse timings to prevent this but need a two-way communication and a secure identity.
I'm just reading up on iBeacon, and I might want to use it for a project I'm currently involved in. What I currently understand from it is this:
Simply put, an iBeacon device broadcasts a message to whomever is
within range. This message includes the sender its mac-address, and
from the intensity of its signal, the receiver can calculate the
distance. iBeacon devices can either be senders, receivers, or both.
1) First of all; is this correct?
Secondly, on the wikipedia page I read that it could enable payments at the point of sale (POS). Because I understand that it is basically a very local broadcast service I'm just trying to understand how something like that would work.
2) So would in case of a payment, the store or the customer initiate the payment?
3) And how would you prevent that other nearby devices pick up the payment messages?
4) Lastly; is it possible to send an iBeacon message to only one iBeacon device identified by its mac address?
Any tips and insights are very welcome!
Enabling mobile payments is an example of something you could build on top of iBeacon technology. But iBeacons themselves are very simple building blocks that would only be a small piece of a solution. It is a common misconception to confuse what iBeacons do themselves with what can be done with iBeacons.
In the payment use case, the only function the iBeacon would perform would be to wake up the payment app and tell it the phone is near the point of sale. (With a specific numeric identifier for the point of sale.) That's it! That is all the iBeacon does. Everything else necessary would be built with other software.
There are lots of possible answers to your other questions about payment processing, but they are not specifically related to iBeacons. Typically, a mobile payment system will require entry of a PIN to confirm payment. So an app using iBeacons could simply display an option to pay to any device with the payment app that is a few feet of the point of sale.
In the simplest implementation, the phone would query the payment server with a message like "I am near POS terminal with iBeacon identifier #12345. How much is the payment?" And the server might respond with a message like "$23.95", which would be displayed on the screen of the phone. In this implementation, the user would verify the amount on the screen and enter a PIN to confirm. This confirmation would be the security mechanism ensuring that the wrong device does not pay for the wrong order. Other more sophisticated implementations are possible, but again they are not strictly related to iBeacons.
Two other clarifications:
While an iBeacon does transmit its Bluetooth Mac address, this is typically ignored. In fact, iOS blocks reading this Mac address, so it is useless on that platform. Instead, applications rely on a three part identifier specific to iBeacons: ProximityUUID, Major, Minor.
There is no way to make only a single device see an iBeacon. It is an open radio transmission visible by everything in its approx. 150 ft. range.
How can a device identify the other devices to whom we need to send data and transfer the data to other device.
If the device1 send the data to device2, will other device say device3 near to them will receive same data?
Please read up on the whole Bluetooth story. You seem to have problems with basic concepts. Also, it would probably help to be a bit more specific in your questions for example specifying which BT version are you referring to.
For identifying the devices, each of them has a separate address. They even have human readable names. (Look at the Wiki page linked above Connection and communication) Also, during the pairing process, you should have to get to know and explicitly allow the devices which you really want to communicate with, the goal of the process is exactly to make sure to have an explicit authorization between the devices for communication.
Yes, device3 will receive the radio signals, but if not authorized, it won't be able to tell what is going on - unless it is a misbehaving device cracking the encryption... (Given the communication is actually encrypted, that is.) Reading the Security Concerns part is also useful.
Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it’s unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.
So what if they interfere and there is a erroneous data, the receiving system simply discards it based on correcting bits of the packets transffered.
Bluetooth devices have a parameter or option called visibility. When you enable visibility, then the bluetooth device starts
publishing its presence within the bluetooth frequency range. This presence can then be detected by any other bluetooth device which can connect to this device when
it scans the above bluetooth frequency range.
As they use spread-spectrum frequency hopping described above they
publish data to all receivers but only the intended receiver with whom
the sender is connected will have the key to unlock the data.