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.
Related
I am using Bluez 5.50 stack on a Linux device which does not have a display. I want to pair my device with a Mobile device (Android or IOS) with secure pairing which requires a passkey to connect.
Every time I am trying to pair, an auto generated passkey is being generated. I want to set a default passkey which should be used during the pairing instead of auto-generated passkey.
How to resolve this issue?
The Bluetooth standard says that the passkey should be randomly generated and that a static key should not be used. There is a good reason for that: the ad-hoc protocol used in Bluetooth is insecure if the passkey is reused. If you don't have any input or output mechanism, you shall use "Just Works" pairing, which unfortunately does not give you any MITM protection. The security of this is technically more or less the same as when using a static passkey but without giving a false sense of security.
See https://stackoverflow.com/a/70479911/556495 for an answer to a similar question.
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.
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
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?
One of the main features of Bluetooth v4.2 is LE secure connections, where Elliptic Curve Diffie-Hellman (ECDH) is used for the key agreement protocol. As of BlueZ v5.26, support for LE secure connections has been added as follows:-
"BlueZ 5.26 is the first release with support for Blueooth 4.2 features. Perhaps the most notable one of these is Low Energy Secure Connections which will require a 3.19 or newer kernel."[1]
Is there a way to test ECDH pairing through the command line? if not, what is the easiest way to test this?
I'm using BlueZ v5.38 on kernel 3.19 but I can't figure out how to do this.
[1] http://www.bluez.org/release-of-bluez-5-26/
In Linux, the secure connections feature using ECDH can be verified by performing pairing (using bluetoothctl) between two Bluetooth v4.2 devices and observing the output through btmon. Look for HCI Event: Link Key Notification and observe the Key type. If it shows P-256, then Secure Connections feature is verified. If it shows P-192, then it is using Secure Simple Pairing (SSP).
Additional background on this can be found in the Bluetooth Core Specification v4.2 in Vol 1, Part A, Section 5.1: Security Architecture.
I hope this helps.