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.
Related
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.
I'm designing a circuit including the RF-BM-BG22A1 BLE 5.2 module and writing the embedded software myself. At the same time, I am writing an Android application that will connect and communicate with this module over BLE.
I am using the following project's classes(SerialListener,SerialService,SerialSocket...) on Android side. (https://github.com/kai-morich/SimpleBluetoothLeTerminal)
For now, I can pair & bond with BLE module using pin(entered from phone) and communicate with it without any problem.
Not sure how safe this is.
I want to use "LE Secure Connections" with "Diffie Hellman Key Exchange".
Which side decides which security method to use and how?
Is there anything extra that needs to be done on the Android side?
Both sides advertise their I/O capabilites and if LE Secure Connections are supported or not. The protocol then picks the highest possible security level based on these properties.
Android supports LESC (at least in recent versions) and all I/O capabilities, so the security level will depend on what the remote device is capable of.
If you simply configure your BLE module to support LESC, then that feature will hence always be used when pairing with an Android device.
Unfortunately, Android's Bluetooth API does not, currently, include any functionality to check or enforce that LE Secure Connections is used or not. This means that MITM attacks, that for example downgrades to non-LESC, when phone acts as central, are still possible without anyone noticing (see https://www.usenix.org/conference/usenixsecurity20/presentation/zhang-yue).
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.
I have to make an application to pair an iOS and Android device (iPhone 5, iPad 3, Galaxy S3, Nexus 7 they all use Bluetooth 4.0) and then send data to each other.
Is this amount of data limited ? Can we send something like a photo or a PDF?
I've already done the pairing and sending data between 2 iOS devices using CoreBluetooth and the sample code from Apple BTLE_Transfer
Of what i understood, a Peripheral (Server) can Advertise to a Central (Client).
This central is scanning around itself, and then try to find the Server by looking for the UUID of the service advertised.
When i make a Server on Android, it is waiting for a connection (listening), i know the UUID and the mac address of my Server.
But when i scan with my iPhone (scanning for the same UUID of course), i can't find the server.
So is there a possibility for the android server to advertise like the Peripheral on iOS?
Or maybe a possibility for my iPhone client to connect using the mac address of the server?
Q: Is this amount of data limited ? Can we send something like a photo or a PDF?
Bluetooth Low Energy was not optimised for sending large amounts of data, nor is it optimised for streaming. It is more suitable for sending small chunks of data periodically (e.g. temperature readings, time, etc). Please have a look at this answer to understand how BLE transfer is different from classic Bluetooth. That being said, you can still send large amounts of data over BLE, and the amount of data is unlimited. However, this might end up being unreliable and relatively slow.
Q: So is there a possibility for the android server to advertise like the Peripheral on iOS?
Being a server/client is a completely different thing from being a peripheral/central:-
Peripheral/central dictates how the connection is made. A central device should initiate the connection. A peripheral device should advertise and wait for a connection request.
Client/Server dictates how the data is distributed. The Gatt Server holds the data. The Gatt Client can read, write or be notified (getting a continuous stream of readings) of this data. In most cases, the server is also the peripheral, but this is not mandatory.
So to answer your question, yes, the server can advertise like the peripheral on iOS. However, for Android, this feature is not yet available and will be part of the next version (Android L) release. Please see this answer for more information.
Q: Or maybe a possibility for my iPhone client to connect using the mac address of the server?
As far as I know, in coreBluetooth you would need the UUID, not the MAC Address, of a peripheral device to connect to it. You do not need to know the services being advertised from the peripheral device. Your best bet would be to scan for peripheral devices, and then connect to the one with the UUID and/or the advertising data that u know belong to your peripheral.
I hope this helps.
I'm not sure. Bluetooth LE isn't good idea to transfer large files. In one request phone you have only 18 bytes.
Nexus 7 bluetooth chip has some defect - not work correctly.
Try free application for IPhone - Light Blue.
so...
First question: yes.
Second: Yes but it's not good idea. MAc address in Iphone is alternating every 10 minutes and all turn on/off bluetooth.
In general, sending large files is best done using an internet connection (over the cloud), there are many frameworks that can cut down the overhead for you.
However, the main question is still how to discover to which device you would want to send the data.
There could be multiple ways of doing that on your own such as using BLE or even sound.
To be honest, its a lot of work so if your app is end-user driven, i would suggest using a framework that can do cross platform discovery for you such as: http://p2pkit.io or google nearby.
Disclaimer: i work for Uepaa developing p2pkit for iOS and Android