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.
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 am trying to create an Android app thats detect a rasperry pi by using the AltBeacon library by davidgyoung. So far I am able to get most data including distance, although the only things that I really need are dBms and the UUID of the device. Inside the rangeNotifier() function I pretty much print every piece of data to see if the UUID might come out somewhere that matches the one of the device but the only thing that resembles a UUID is given to me as "00000000-0000-0000-0000-000000000000" and is found by using the getIdentifier method. Any ideas why I can't see the actual UUID of the device? Thanks!!
If multiple Android apps say the ProximityUUID is 00000000-0000-0000-0000-000000000000, then they are probably right.
The reason iOS apps probably won't detect 00000000-0000-0000-0000-000000000000 is because unlike Android, iOS can only detect a beacon's UUID if it is pre-configured into the app (yeah, that's a chicken and egg problem I know!) and your UUID is probably not configured into those iOS apps. So it may be showing the ProximityUUID of a different beacon in the vicinity.
Also, don't confuse the Bluetooth GATT Service UUID with the iBeacon Proximity UUID. Even though these look superficially similar -- they are completely different identifiers If you are using a more general Bluetooth scanning app on iOS (and not a beacon scanning app) this may be what iOS is seeing.
I'm actually working for a startup I'm building with two other founders. On the side I would like to develop a quick prototype to be able to deepdive into a subject I can use on my project : beacons.
Here is what I want to achieve : I want to be able to use a device as an emitter (using bluetooth, BLE, or wifi) and the other one to be able to know when it enters the first one range. I need that to be able to do indoor localization (just a check in system, not to know exactly where people are in that specific location).
I'm used to code mobile application with Ionic and I'm more a Javascript developer. I saw that there is already something which fit to my needs : Dazting which transform every device mobile as "a beacon" with either bluetooth or Wifi. Problem, I want to do it on my own but to be honest I don't really now how they manage to do that with Wifi. I know that there are some libraries to emit with BLE but what about bluetooth ?
Does it mean I'll have to code it with native code ?
This is what I want to achieve :
Coding an hybrid app (will loose less time and one app for every
platform)
Transforming the mobile device into an emitter : with bluetooth or
wifi
Be able to know the distance between a device which will emit and a
one that will receive the signal
I don't want to go with beacons : I'm not going to use macro-location and buying beacons for my project at the start is not something we would like to do.
Any ideas or suggestions on how did Datzing manage to reach that goal ?
Thanks in advance.
Datzing relies on emission of Bluetooth Classic, Bluetooth LE and WiFi packets from a mobile device that is made discoverable, either programmatically or through manual selection in settings. The unique MAC address or SSID of the device can then be used to tie the detected transmission to a registered "Beacon" on the Datzing system. Basically it just registers the unique identifier associated with a Bluetooth or WiFi transmission with the Datzing servers so they can have meaning.
Using this technology to transmit on an iOS device is severely limited due to operating system restrictions. Users essentially have to manually go to settings screens to start the emissions. Android devices are much more flexible if you have a native app granted the proper permissions.
On the detection side, iOS is also much more limited than Android due to the operating system blocking access to raw MAC addresses of bluetooth devices and preventing detecting SSIDs of WiFi access points unless the network is connected. As of Android 6.0, access to the raw MAC address is also restricted, making such a system work less well with Bluetooth on newer Android devices.
On both platforms, iOS and Android, the ability to use these techniques to the extent they are allowed by the operating system are possible with native code. Doing so with Ionic or Cordova would require cobbling together a number of plugins (if they even exist) to bridge to the native features to access WiFi SSIDs and do Bluetooth discovery and scanning. This is unlikely to be a quick protoype.
Word of caution: It is always a good idea to try out a system like Datzing before trying to reproduce it yourself, as limitations often cause technologies not to live up to the claims of the marketing materials.
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.
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.