Is there any (big) technial difference between pairing 'normal' Bluetooth devices and pairing Bluetooth LE devices?
I found a lot of information for Bluetooth LE pairing, but not for normal? For example
Info 1.
So is this information for normal Bluetooth correct too?
If you mean Bluetooth Classic or BR/EDR by 'normal',the difference depends on the version of Bluetooth in use.
Bluetooth Classic or BR/EDR 2.1 - 4.1 Vs BLE 4.0-4.1
BR/EDR pairing procedures are handled by the LMP layer of the Bluetooth Controller.
BLE Pairing procedures are handled by SMP in the host stack.
BR/EDR uses ECDH Key generation which prevents passive eavesdropping.
BLE legacy pairing does not use ECDH Key generation and so it is susceptible to passive eavesdropping
BR/EDR defines 4 association models; OOB, Passkey entry, Just works, Numeric Comparison
BLE Legacy Pairing defines 3 association models ; OOB, Passkey entry, Just works.
Although they appear similar from the user perspective, they do not provide the same level of security. See #2
BR/EDR generates the Link Key on both devices.
BLE legacy pairing, generates the STK. The Link Key i.e. LTK in use is distributed by the slave
BR/EDR v4.2 Secure Connection vs BLE v4.2 Secure Connection
BLE 4.2 secure connections added ECDH key generation and the Numeric Comparison association model. It also did away with the STK. The LTK is now generated on both slave and master.
Secure connection association models on the BLE link, are equivalent to BR/EDR secure connection association models, in terms of protection against MITM attacks and Passive eavesdropping.
When two BR/EDR/LE devices support Secure Connections over both transports, keys for both transports may be generated during a single pairing procedure. The ability to convert keys from one transport to the other eliminates the need to pair twice.
There are still some differences.
BR/EDR pairing procedures are handled by the LMP layer of the Bluetooth Controller.
BLE Pairing procedures are handled by SMP in the host stack.
BR/EDR cryptographic functions use HMAC-SHA-256.
BLE cyrptographic functions use AES-CMAC.
More information can be found in the Bluetooth core specification here
Related
What is the diference between Secure Simple Pairing and LE Legacy Pairing in BLE? My assumption is, that the SSP is the older one, rather not used today, am I right with it? Is SSP still used in the devices or it is rather state-of-art method of pairing.
That UG103.14 document seems to be written by some people at Silabs; it is not an official document written by Bluetooth SIG. That BLE would use Secure Simple Pairing is just wrong.
In Bluetooth Classic we have Legacy Pairing, Secure Simple Pairing and Secure Connections (the newest and safest one).
In BLE we have LE Legacy Pairing and LE Secure Connections.
You can read the following in the Bluetooth Core Specification 5.3, Vol 1 Part A (Architecture) section 5.4.1:
Bluetooth LE uses four association models referred to as Just Works, Numeric Comparison, Out of Band and Passkey Entry. LE legacy pairing does not have an equivalent of Numeric Comparison.
In LE legacy pairing, each of these association models is similar to BR/EDR Secure Simple Pairing with the following exceptions.
• Just Works and Passkey Entry do not provide any passive eavesdropping protection. This is because Secure Simple Pairing uses Elliptic Curve Diffie-Hellman and LE legacy pairing does not. In LE Secure Connections pairing, the four association models are functionally equivalent to BR/EDR Secure Connections.
If you want to know more, I suggest you to read the whole of chapter 5 Security Overview. It's just 11 pages.
I am wondering what is state of the art, when developing new products.
We are currently developing a new product and I have to decide, which bluetooth security mode to use. Value ranges from 1 to 4.
If I understand this right, mode 4 was introduced with bluetooth 2.1 and I ask myself, if there is a significant number of smart phones not supporting this.
Moreover we prepare our bluetooth certificaation with the PTS tool. This tool enforces using mode 4 if our device can to BR/EDR and BLE.
Is it state of the art to always enforce mode 4 in new devices?
Thank you.
If you really want to use state of the art security mode in Bluetooth, then this would be "Secure Connections" for classic Bluetooth [1], and "LE Secure Connections" for Bluetooth Low Energy [2]. Secure Connections was introduced in Bluetooth v4.1 and LE Secure Connections was introduced in v4.2. This is the latest and greatest security mode, and it uses Elliptic Curve Diffie-Hellman Cryptography for key calculation [3]. One of the key features of this mode is that if a device is paired over classic Bluetooth, there is no need to pair over LE as well, as a keys for both transports are generated during a single pairing procedure [4].
I hope this helps.
Bluetooth Specification v5.0, Vol 0, Part C, Section 1.3: Core System Package.
Bluetooth Specification v5.0, Vol 0, Part C, Section 1.3: Core System Package.
Bluetooth Specification v5.0, Vol 1, Part A, Section 5.3: Secure
Connections Only Mode.
Bluetooth Specification v5.0, Vol 1, Part A, Section 5.6: Key
Generation Between BR/EDR and LE Physical Transports.
I am programming a device which uses BR/EDR and BLE. BR/EDR is mostly used for audio data while BLE should work as control channel. Access to the used BLE characteristic returns a gatt_status_insufficient_authentication if and only if the central (smart phone) is not bonded. At least, that is what I want.
Moreover, if BLE bonding is triggered, I also get a BR/EDR bonding by Cross Transport Key Derivation (CTKD). Ok.
IF I do BR/EDR pairing from the phones pairing menu, this CTKD does not work. How could this work?
Or is there a way to enforce BLE pairing instead BR/EDR pairing?
Regards
In the Advertising section of a BLE, The Bluetooth SIG Define the "Flags"
which has these plus a few more.
BR/EDR Not Supported
Simultaneous LE and BR/EDR to Same Device Capable (Controller)
Simultaneous LE and BR/EDR to Same Device Capable (Host)
I am having an issue on a CSR chipset design that does not support GATT over BR/EDR.
Apple works great, as it always connects to LE.
..but android devices persistently try to connect GATT over BR/EDR if the audio is already up; therefore fail because CSR cant handle BR/EDR transport for GATT.
I am thinking these flags are at the core of the problem.
In CSR's demo code they do not set "any" of the above flags. I have had limited success with my problem on some handsets by setting the "Not Supported" flag.
The issue is the other two flags. How does Controller/ Host relate to other LE terms. For example Central/Peripheral or later Master/Slave.
I dont know what flags to set for my use case. Any suggestions welcome?
You can use a Static Random address for all LE operations. That way the Android device thinks it's a different device than when talking over Bluetooth Classic since that uses the public BD_ADDR.
Or, one variant of the connectGatt takes a transport parameter which you can set to TRANSPORT_LE to force communication over BLE.
If your device supports BLE and BR/EDR at the same time you should set these flags:
BR/EDR Not Supported=0
Simultaneous LE and BR/EDR to Same Device Capable (Controller)=1
Simultaneous LE and BR/EDR to Same Device Capable (Host)=1
If the flag data is missing completely, it's the same as if all fields are zero.
I'm trying to make a BLE device that actually pairs securely. As far as I know the transport encryption (using AES) is secure in all versions of BLE, once the 'Long Term Key' has been exchanged.
BLE 4.1
BLE 4.1 and earlier use symmetric cryptography and the passkey (PIN) is only 6 digits so it is trivial to passively eavesdrop on the pairing, brute-force the passkey and derive the LTK from that. It seems that this was insecure by design because it was thought that low power BLE devices wouldn't have enough oomph to do asymmetric cryptography.
BLE 4.2
BLE 4.2 adds 'Secure Connections'. This is apparently also broken and what's more it was broken in 2008 when the same pairing method was used in Bluetooth 2.1!! It doesn't totally break pairing - only the passkey entry method - and you only learn the passkey, not the LTK. But it does allow an attacker to perform a MitM attack if the passkey isn't changed for every pairing attempt.
Out-of-Band pairing
The Out-of-Band pairing method would be an excellent choice, then I can use a QR code or something. However there are no public APIs to access the OOB method on either Android or iOS. Android supports OOB pairing via NFC but iOS doesn't, so that's out.
It seems the only option left is to implement a custom encryption scheme, but that is a ridiculous amount of work.
My questions are:
Why did the Bluetooth SIG specify a pairing method in BLE 4.2 that was already known to be insecure 6 years earlier?
Are there any existing encryption schemes for BLE that secure it? Ideally open source and well-tested, but could be commercial. Would I still be able to use GATT?