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.
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 learn into android (linux) kernel, and I know that android needs very fast (zero-copy) IPC, but still, I don't get the reason why binder needs to be there.
Can the same thing done with unix socket + mmap /dev/shm file ?
Let's say using dbus, but to achieve zero-copy, create and open file in tmpfs (e.g. /dev/shm) delete it (so another process can accidentally open it), send file descriptor to other process and mmap it.
EDIT:
instead of create file in tmpfs, you can use shm_open too
There are mainly three reason to create new Mechanism of Binder
Complexity
Performance
Security
Complexity - In the smartphone platform, especially the Android system, in order to provide application developers with a variety of functions, this communication method is ubiquitous, such as media playback, video and audio capture, and various sensors that make mobile phones smarter (acceleration, orientation, temperature, brightness, etc.) are all managed by different Servers, and the application can use these services only by establishing a connection with these Servers as a Client
Example : MediaPlayBack -media playback, video and audio capture, and various sensors that make mobile phones smarter (acceleration, orientation, temperature, brightness, etc.) are all managed by different Servers, and the application can use these services only by establishing a connection with these Servers as a Client. It takes a little time and effort to develop dazzling Function.The widespread adoption of the Client-Server approach poses a challenge to inter-process communication (IPC) mechanisms
Performance - As a general-purpose interface, socket has low transmission efficiency and high overhead. It is mainly used for inter-process communication across the network and low-speed communication between processes on the machine.
The message queue and pipeline adopt the store-and-forward method, that is, the data is first copied from the sender buffer to the buffer opened by the kernel, and then copied from the kernel buffer to the receiver buffer. There are at least two copy processes. Although shared memory does not need to be copied, it is complicated to control and difficult to use.
Security- As an open platform with many developers, Android comes from a wide range of sources, so it is very important to ensure the security of smart terminals. Traditional IPC does not have any security measures and relies entirely on upper-layer protocols to ensure it. First of all, the receiver of traditional IPC cannot obtain the reliable UID/PID (user ID/process ID) of the other party's process, so it cannot identify the other party's identity.
Android assigns its own UID to each installed application, so the UID of the process is an important symbol to identify the identity of the process. Using traditional IPC, only the user can fill in the UID/PID in the data packet, but this is unreliable and easy to be used by malicious programs.
Secondly, traditional IPC access points are open, and private channels cannot be established.
Based on the above reasons, Android needs to establish a new IPC mechanism to meet the system's requirements for communication methods, transmission performance and security, which is Binder
I'm studying the Bluetooth Low Energy (BLE) protocol (v4.2), and in particular its security features.
I'm trying to understand how the encryption of data transmitted between a mobile App and a BLE device works.
The official documentation (v4.2) specifies the methods to encrypt data, authenticate the devices, generate the keys used in the encryption and pairing phase, etc..
First doubt (I want to be sure to have understood some concepts):
all these functions are implemented in the host level, so if I want to encrypt data transmitted between an App (Android) and a BLE device (like a fitness tracker),
do I have to implement (or enable) these methods on the BLE device?
In this way, the developer should only care about the implementation of these features on the BLE device, since the Android Bluetooth stack just support these features. Am I right?
If I'm wrong, what is the right way to implement these features (on both mobile app and BLE device)?
Second doubt:
Why some BLE devices, implement their own cryptography, on top the GATT protocol, instead using the security features provided by the SIG?
Third and last doubt:
Are the security features specified by the SIG mandatory or are optional?
As you can see I have some doubts, and maybe some questions could be silly, so if someone could clarify how the security mechanisms (like encryption) can be implemented between an App and a BLE device,
and at which levels these features are implemented (OS or application level), I will appreciate a lot.
If you use the standard BLE encryption, it is actually the link layer at the controller that does the encryption/decryption/verifying auth tags. But it's the host layer (SMP) that defines how two devices pair, bond and exchange keys. It's also that layer that tells the link layer to start encryption using the exchanged keys. On Android and iOS, it's the OS that manages the pairing and bonding and implements the SMP. Whether or not Bluetooth pairing/bonding/encryption is used is fully up to the device, and is optional. If it's not supported it must still support to send the error code "Pairing Not Supported"
The Bluetooth standard only has one "use case". This use case is to provide a method for securing the link between two devices so that, after bonding, no one should be able to impersonate a device or be able to manipulate or decrypt the traffic. As you might know, the "LE Legacy Pairing" which is the only pairing method specified up to Bluetooth v4.1, has several flaws that makes it unsecure if the attacker sniffs the traffic during pairing (both for "Just works" and "MITM/passkey entry", but not OOB). The new "LE Secure Connections" defined by Bluetooth v4.2 however uses Diffie Hellman to make it more secure.
Even though Bluetooth pairing itself provides security, there are some flaws in both the Android API and the iOS API that still may not be enough for an app developer if good security is needed. Notably, iOS does not provide any API whatsoever to detect if a given device is actually bonded or if a link is encrypted. It does however show a popup to the user when the pairing starts, but the app knows nothing about that pairing. So, from an iOS app's point of view, you don't know:
If you have paired to the device.
If you talk to a genuine device or a chinese copy.
The security level, i.e. if the pairing used Just Works, MITM legacy pairing or LE Secure Connections.
If the current link is encrypted.
Android is a little bit better. There the app can at least know if the device is bonded or not (but not the other three). There is also an API "createBond" to start the bonding process. The Windows API is much better here, since you can enforce encrypted link when doing GATT operations.
Any of these reasons may be enough for a developer to implement the security from scratch on top of GATT instead. In particular one often common use case is that the developer wants the use case "log in to the peripheral" with a PIN or password. The Bluetooth standard does not support that use case in any way (and no, using "MITM protected pairing with static passkey" doesn't work, since that protocol by design reveals the passkey after one or a few tries).
Anyway, if you develop your own peripheral with your own hardware and want to use the Bluetooth standard's pairing/bonding/encryption, the SDKs by the manufacturers of the BLE chips have usually already implemented this. However, you still need to set it up correctly for it to work. Usually you only have to configure some parameters (like if you have a display or the user can enter a passkey) and then the rest is automatically handled internally by their SDK.
UPDATE:
Source code for Android can be found at https://android.googlesource.com/platform/system/bt/, https://android.googlesource.com/platform/packages/apps/Bluetooth/ and https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth.
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.
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.