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.
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.
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?
This is a basic questiion but I am not able to know it.. I have read the spec but still I am not clear.. My question is that In bluetooth low energy, we use Short term and long term keys in security. What are the differences between them? and also please tell me are these keys used in BR/EDR too? Thanks in advance..
Short Term Key (STK) is used as the first step for encryption (just after pairing is completed). Once a link is encrypted, Long Term Key ( LTK ) is then generated.
Basically, if master doesn't have an LTK generated against a slave, and the same slave attempts to connect again to master, the master assumes that the slave is not authenticated and hence attempts to pair again with the slave. If LTK is present, master understands that this device is already authenticated and proceeds for session encryption.
To know the difference between the two, one should understand the phases of pairing in BLE:
Phase 1: two devices exchange device info such as capabilities etc.
Phase 2: the Short Term Key (STK) is generated based on defined procedure by BLE spec.
Phase 3: Long Term Key (LTK), Connection Signature Resolving Key (CSRK) and the Identity Resolving Key (IRK) are encrypted using STK and exchanged between the two devices.
After Phase 3, STK won't be used any more. Instead, LTK is used for link layer encryption, while CSRK is used for AAT layer encryption depending on the security mode.
In short, STK is used during pairing to encrypt the LTK and other information between the devices, LTK is used afterwards in normal data transmission.
It's too late but for the information of others.
1.What is the difference between STK and LTK?
From the GUIDE TO BLE SECURITY :
LE pairing begins with the two devices agreeing on a Temporary Key (TK), whose value depends on the pairing method being used. The devices then exchange random values and generate a Short Term Key (STK) based on these values and the TK. The link is then encrypted using the STK, which allows secure key distribution of the LTK, IRK and CSRK.
2.Are these keys used in BR/EDR too?
No, LTK and STK are not used in BR/EDR. The underlying pairing process is different in BR/EDR and BLE. BR/EDR uses key agreement while BLE uses key transport for pairing. In BR/EDR, link key is equivalent to LTK in BLE.