I am trying to create an iPhone and Android application that accesses a device with sensitive personal information, such as a body composition analyzer, via BLE (Bluetooth Low Energy).
At that time, it is problematic if anyone can read the device's information, so we are thinking of creating the following mechanism.
Some users of the body composition analyzer will store their passwords and usernames in the device.
Reading from the app via BLE is only possible if the username/password combination is correct
I know that if Bluetooth Classic is available, this can be done using SPP communication, but since SPP is not available from the iPhone, it must be done via BLE.
However, since BLE Peripheral data can be read by anyone with an app like nRF Connect during advertisements, is BLE not suitable for this kind of application?
Is it possible to create such an authentication system with BLE? If so, what kind of mechanism is possible?
If the pairing model and I/O capability requirements offered by standard BLE pairing does not fit for you, you will need to treat the BLE communication as a generic public (non secure) channel. On top of this you can put any type of generic security mechanism that fits your needs such as TLS or any PAKE.
Related
Can an Android device pretend and connect as a Bluetooth controller?
Can Android devices connect as a device to, say, a PC and act as a gamepad or similar device?
Is it allowed and doable in code without root access?
I tried this code: Connect Bluetooth devices. But it can not get it to pair.
Short answer, yes.
I recommend looking at Google's example project on Bluetooth communication BlueToothChat initially. Based on what you've written, I think you're missing several important steps.
You need all of the following components / steps:
General Overview
Set up Bluetooth
Set Permissions
Scan for other Bluetooth devices
Query the local Bluetooth adapter for paired Bluetooth devices
Connect to a remote device as client or server
Transfer data over Bluetooth
If you have access to the device your attempting work with as a controller, then you can create your own communication setup. Define a set of parameters to write and read on both sides that emulate the functionality you're looking for.
If you do not have access to creating your own read/write setup, or you want to use standard interaction methods for the industry, then the best bet is the Bluetooth HID Device profile mentioned by #Morrison Chang.
The HID profile basically establish an industry standard of required device features, read/write formats, combinations of features equaling a controller type (ie: "this is a keyboard"), and data mappings for what read/write numbers mean on either side of the client / server connection.
From the linked comment thread, the Kontroller project on Github has source available for your peruse.
There's also a reasonable Intro to Bluetooth HID that covers some of the topics on what Bluetooth HID is actually doing.
Finally, also recommend looking at Google's own BluetoothHidDevice page.
So far I am able to do things two different ways.
I can advertise a service on the Pi, connect from an Android app, and read/write characteristics. From my understanding, this communication is not encrypted.
I have been able to do the same thing adding pairing and bonding to the mix. I advertise a service on the Pi with an agent, connect from an Android app, and as soon as I try to read/write a characteristic I get a prompt on my phone asking to pair. From my understanding, after pairing is succesful the communication is encrypted.
That last part is great. However, I am looking to pair without bonding, mainly because I don't want to end up with a huge list of devices on my bluetooth settings. Android seems to use this term interchangeably, which just makes everything more confusing.
I know it's possible to do it as per this video. I just haven't figured out how to actually do it myself.
Any help is appreciated.
This is totally possible according to the Bluetooth protocol specification. If at least one device sets "bonding flags" to "no bonding" in the AuthReq field of the Pairing Request or Pairing Response, no bonding information shall be permanently stored.
If you're using BlueZ, I'm not sure if it allows you to configure this though.
For Android, people report that Android does not respect this flag and creates a bond anyway (Why does Android bond even when asked not to bond?).
Technically speaking, pairing is the process of exchanging the keys with a remote device, while bonding is the process of storing these keys. Some devices use the terminology "pairing" to indicate the the keys are exchanged and the connection is encrypted, but the keys will not be stored for future use. On Android this is not possible as far as I'm aware, and you always need to store the keys. This can be seen in the link below (see the section Bonding with a BLE Device):-
The Ultimate Guide to Android BLE
Some other useful links:-
Android BluetoothDevice API
Should One Create a Bond with a BLE Device
BLE Pairing and Bonding
I have an android application which pairs to a BLE device and read/write data. Now, my client needs to make this more secure through TLS encryption. I am trying to figure out an efficient way to transfer data via Bluetooth Low Energy between Mobile App & BLE device using TLS/SSL. Could someone please guide me on this?
In my opinion TLS has very much overhead and is not really made for the situation with BLE where every saved byte counts. So using TLS over BLE is per definition not efficient. If you still want to do this, you could for example use SSLEngine in Java which is a transport-independent TLS solution. Use L2CAP CoC sockets over BLE instead of GATT to make the I/O simple.
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.
Is there any inbuilt security while exchanging data after connecting to a Bluetooth LE device using this method? Here I wanted to be clarified about the following -
1. Is the communication channel is secured after device gets connected (but not pared/bonded yet)?
Or
2. Is it mandatory to bond/pair the BLE device (using createBond()) to make the communication secured?
I had a look into the following thread, and the question 4 seems similar to my question.
Bluetooth Low Energy encryption and data safety
But the answer differs in different response. Please respond if anyone has clarity on this.
Regards,
Paul
No, the pairing process is seperate from the connection procedure in LE. You could be connected and exchange data without pairing.
When you say secured, do you mean encrypted? There are different features in LE security. You could sign and add integrity without pairing.
Data enncryption requires pairing, regardless of using Secure Simple Pairing or LE Secure Connections.