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.
Related
From the Bluetooth client example at http://people.csail.mit.edu/albert/bluez-intro/x502.html, it seems I can simply connect to a remote Bluetooth socket as long as I have the Bluetooth MAC address of the device.
If I can simply connect to a remote Bluetooth device, I am wondering what exactly does Bluetooth pairing do. When is pairing really needed?
Update:
From How does Bluetooth pairing work?, it appears the final result of pairing is that an encryption key gets stored on both sides. I assume, when you open a remote socket connection, the call is intercepted by the local bluetooth daemon. In turn, the daemon encrypts the data and sends to the remote device. The daemon on the remote device decrypts the data and sends to the remote client application:
Device1Client-->Device1Daemon-->Device2Daemon-->Device2Client
Is this assumption correct?
Yes, your assumption is partially correct. Encryption is one of the uses of Passkey.
Bluetooth pairing is necessary whenever two Bluetooth devices connect to each other to share resources. A trusted relationship is established between the devices using a numerical password, commonly referred to as a passkey. Depending on how often one Bluetooth device connects to another, the user might opt to have the passkey saved for future connection attempts or prompt to enter the passkey each time the devices request communication with each other.
This is already explained on Stack Overflow please check- How does Bluetooth pairing work?
In the below answer, I will try to explain what is not mentioned in the above link or answers.
In Pairing process, when the initiating device sends a ‘Pairing Request” to the other device. The two devices then exchange I/O capabilities, authentication requirements, maximum link key size, and bonding requirements. Basically, all this phase consists of, is the two devices exchanging their capabilities and determining how they are going to go about setting up a secure connection. It is also important to note that all data being exchanged during this phase is unencrypted.
Now the question is why this Phase is needed?
As mentioned- “two devices exchanging their capabilities.” The pairing should happen between compatible device there is no point in Pairing you Mouse with a Headphone as Mouse capabilities are different than Headphone.
One more use of Pairing is – “determining how they are going to go about setting up a secure connection.” Here the frequency hopping pattern is determined for two reasons-
To avoid Middle Man Attack.
To avoid Collision
Bluetooth uses 79 radio frequency channels in the band starting at 2402 MHz and continuing every 1 MHz. It is these frequency channels that Bluetooth technology is "hopping" over. The signal switches carrier channels rapidly, at a rate of 1600 hops per second, over a determined pattern of channels. The hopping pattern is determined well during the pairing process so that no other device will know in which band of the frequency the data is being transferred at an instance. Its rare case that frequency hopping pattern can be the same for a couple of devices communicating hence collision is avoided.
Note: If any third device is able to capture the passkey then it can replicate the whole communication pattern and capture the data being transferred. This is how the BT Sniffers work.
I am not able to cover all the details as per SIG specs. I hope the above answers give you a clearer picture of the need for the Pairing process. Feel free to point out, if you want me to explain any specific point in detail.
Below are the reference Links for more information-
http://large.stanford.edu/courses/2012/ph250/roth1/
https://www.bluetooth.com/blog/bluetooth-pairing-part-1-pairing-feature-exchange/
I have some Bluetooth LE v4.2 beacons that I will connect ONLY with known devices that we may call "readers". The beacons are program and installed by me. I consume the data and I sell the service.
I want to use a hard-coded shared secret to realize the pairing or communication. My primary concern is that only a known and authenticated device SHALL be able to send data (with integrity protection).
What would be my best option ?
A few previsions :
We are talking about 1000s of devices, and more will join the network every day.
I am already doing advertisement filter, etc. I only connect to devices with my vendor id.
Replacement if preferable to any kind of lack of security in the authentication, my added value is the trust in data.
I have an OTA update system for all the devices.
Interesting documentation I found about Bluetooth Low Energy (BLE) security :
NIST Guide to Bluetooth Security
An answer to my question on the Nordicsemi devzone gave me some hints. Find below the answers I was looking for. I hope that will help.
Mode 1 Level 4 (encryption) vs Mode 2 Level 2 (signing)
Resources :
Dev zone semi question
Forget about CSRK. It's a bad idea that almost no BLE stacks support. One reason is that it only supports Write Without Response in one direction. Another is that you need to keep a write counter stored in flash. A third is that a MITM could potentially delay a message for an arbitrary time and doesn't need an active connection during this time. It has no benefits at all compared to the normal AES-CCM except that CCM takes 2.5 round trips to set up for BLE.
How to ensure secure encryption with a pre-shared secret
Resources :
Dev zone semi question
Stackoverflow question
Dev zone semi : Pre-shared key = OOB
Dev zone semi : OOB LESC vs Legacy
Do we need pairing ?
No pairing :
If you remove the pairing step from BLE security you basically just have AES-CCM with pre-shared keys, where each connection has an own key derived from the shared key and a nonce from each side. LESC is about the pairing step which you want to remove, so that doesn't apply in that case.
Vs Out Of Band (OOB) :
A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing.
Preferred solution is Out of band pairing.
LESC with pre-shared passkey vs OOB with pre-shared key ?
Resources :
Dev zone semi : Pre-shared key
The first time you connect you should authenticate the other device, and you can do this by using your pre-shared key when you bond. You can bond by using Passkey Entry or OOB. The key used with Passkey Entry is short, so I would recommend using a 128-bit key with OOB, this is much more secure.
Out of band LESC Vs Out Of Band Legacy
Both LESC and Legacy end up with 128-bit encryption keys, and these are equally secure. The power consumption will be the same after pairing is done. LESC uses a more complex algorithm so it will use more power during the pairing process. The difference is in the key generation algorithm. It depends on what kind of attacks you want to protect against. If you do OOB with legacy and you are sure that the attacker can't get the OOB data, you are secure. If the attacker can get this data, you should go for LESC. What kind of central device are you connecting to? Does it support OOB and/or LESC?
In fact LESC out of band with pre-shared key is quite complicated to archive because of the calculation of the oob payload is supposed to be a random number signed with private key, and this mechanism is implemented in the softdevice but not accessible. Thus we could either re-invent the wheel, or just decide that this computation is useless as evedrop of out-of-band is just impossible with pre-shared key. Also, LESC oob pairing is more calculation intensive for no benefits.
Out of band Legacy
For more detailed explanations of Out of band Legacy pairing, see bluetooth.com.
Temporary key calculation
A master key will be included in the new FW release code (that's probably my major weakness, but I cannot do much about it). I will use legacy Out Of Band pairing. The Temporary Key (TK), used for paring communication encryption, will be derivated from the master key using generation function fc (inspired by the f5 function described in the Bluetooth specification).
The definition of this key generation function fc makes use of the MAC function AES-CMACT with a 128-bit key T.
The input of the function are:
M is 128 bits
A1 is 56 bits
A2 is 56 bits
The string “******” is mapped into keyID using extended ASCII as follows:
keyID = 0xXXXXXXXXXXXX
The output of the key generation function fc is as follows:
fc(M, A1, A2) = AES-CMACM(keyID || 0x00 || A1 || A2 || Length = 128)
The TK is calculated as:
TK = fc(Master key, DB_ADDR_master, DB_ADDR_slave)
I wouldn’t pair in factory, but instead add other programmatically controlled mechanisms in the FW. I’m thinking bondable LE links, whitelisted MAC-addresses (as long as we’re not talking about random/obfuscated addresses).
If you have access to the chip/design in production, you could let the production test station use wired/wireless available interface and add the whitelisted MAC addresses in there...?
Or, use Vendor-specific data in the BLE advertisements data and add X identification bytes that you filter on in the LE central.
Or, use groups of custom Service UUIDs and add to the adv data, allowing centrals to filter on that.
Etc etc — the point is; my experience of setting production pre-paired stuff has always ended up in chaos, and there should always be a mechanism to clear your pairing and manually setup thing as you, or your customer, want. How else would you deal with replacements, upgrades etc and sudden implicit or explicit breaking changes — always design things so that there’s a way to get thing up and running from scratch again. Depending on the product, that might be using a Config tool from PC, or Admin-mode from your phone/app, or the like — but don’t rely on production-defined pairings.
Suppose you have 2 BLE devices that periodically randomize their MAC addresses for security reasons. But they were paired. How do these 2 BLE devices w/random MACs know if they're paired when they meet again after being out of range? i.e. What kind of packets are sent back and forth to determine this?
Random addresses are created using a specific algorithm so that only those possessing the Identity Resolving Key, which is distributed during pairing, can verify that a given random address belongs to a given device.
If you want to know the details you should simply read the Security Manager specification in the Bluetooth Core documentation.
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.