Home > Enterprise >  Does BLE device generates new LTK, CSRK, and IRK every time it bonds with new device?
Does BLE device generates new LTK, CSRK, and IRK every time it bonds with new device?

Time:01-06

I have a conceptual question, for BLE experts, regarding the keys generated and exchanged when bonding occurs between two BLE devices. I might be wrong or my question might be naive, so please bear with me.

Consider the following example, let's call it Case-1.

Let's say we have a peripheral device (P1) and a central device (C1).

P1 sends advertisements to connect to a nearby device. C1 initiates the connection and both devices start the connection procedure in which both devices exchange their I/O capabilities, pairing method, and some keys. Eventually, once the bonding is complete, both devices have exchanged LTK, IRK, and CSRK for encrypting the connection, resolving random addresses, and resolving signatures, along with EDIV, RAND. Now both P1 and C1 can communicate while using these keys for their respective purposes.

I have the following question:

Q1. The connection is terminated between P1 and C1. Later, when both P1 and C1 connect again, will the two devices use the same LTK, IRK, and CSRK keys that they used in Case-1?

Q2. Let's say a new central (C2) comes into the picture. P1 is no longer connected to C1. P1 now wants to connect (with bonding) with C2. Will the P1 use the same LTK, EDIV, RAND, IRK, and CSRK that it had used(generated) earlier to connect with C1 in Case-1?

Q3. Do the BLE devices use different keys (LTK, EDIV, RAND, IRK, and CSRK) with every new device they connect with?

Q4. If I take the keys (LTK, EDIV, RAND, IRK, and CSRK) stored in the C1 and store them in C2, can P1 connect to C2 using the same keys? Is it possible to make this work or it is incorrect logically and from the security point of view?

It would be a lifesaver if someone can clarify these points. Thanks

PS: I am consulting core-spec v5.3 and some online resources for my reading.

CodePudding user response:

The connection is terminated between P1 and C1. Later, when both P1 and C1 connect again, will the two devices use the same LTK, IRK, and CSRK keys that they used in Case-1?

Yes, they will use the same keys. You only disconnected, the bond is still there. You need to remove the bond to delete the keys.

Let's say a new central (C2) comes into the picture. P1 is no longer connected to C1. P1 now wants to connect (with bonding) with C2. Will the P1 use the same LTK, EDIV, RAND, IRK, and CSRK that it had used(generated) earlier to connect with C1 in Case-1?

No, P1 and C2 will come up with new keys for this connection during the pairing process.

Do the BLE devices use different keys (LTK, EDIV, RAND, IRK, and CSRK) with every new device they connect with?

Yes, they do. The keys depend on the devices and are therefore different for each device.

If I take the keys (LTK, EDIV, RAND, IRK, and CSRK) stored in the C1 and store them in C2, can P1 connect to C2 using the same keys? Is it possible to make this work or it is incorrect logically and from the security point of view?

Theoretically yes, but it might be impossible to extract the keys from a system due to security reasons. It is a security feature that every connection uses its own keys in case one connection gets compromised.

Without bonding, the devices need to pair for each new connection and will use new keys. They get stored during bonding to prevent the devices from needing to pair again next time.

The pairing process is described further in chapter 2.3 of the BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part H (page 1636).

CodePudding user response:

The IRK is always constant (the same IRK is shared in every pairing attempt) and is used to create random resolvable addresses. Devices that receive an IRK from a remote device can then figure out if a random resolvable address belongs to a particular IRK.

All other keys are unique for every bond.

The CSRK must in particular be unique for every bond since there is a counter associated with it, incremented on every packet write to avoid replay attacks. This would not work security wise if two bonds have the same CSRK, since an attacker could then replay packets from bond 1 when impersonating bond 2 (assuming the packet counter is less for bond 2).

The LTK, EDIV and RAND are used to derive a session key for encryption the next time a connection between the same pair of devices connect.

Thus the answer to Q1 is that the keys are reused for every new connection attempt between the same pair of devices, as long as the bond exists.

If you in particular copy the IRK from one central to another, then yes a connection between P1 and C2 can be made and all the other keys can be used during this connection, if C2 uses a random resolvable address. This is because P1 believes it talks to C1 due to the random resolvable address. After all, on the Link Layer it's impossible to tell C2 and C1 apart if random resolvable addresses are used with the same IRK.

If random resolvable addresses are not used, then it's usually not possible to copy a set of keys between devices. This is because the keys are associated with the Bluetooth device address (public or static random). If a central using a different address connects to a peripheral, the peripheral will look up bonding keys in its database to find out there are no LTK, EDIV, RAND, CSRK stored for this address. In some implementations though for encryption setup, the peripheral will look up the LTK based on EDIV and RAND instead of the address. In this case copying of keys will work, at least to establish encryption. The CSRK is always looked up from the address though. Note that for LE Secure Connections, EDIV and RAND are always 0 so in this case the LTK is always looked up from the address.

Note that the use of CSRK is not widespread at all. I have not seen any implementation use it in a real product. Since only the "Write Without Response" command can be used with CSRK and the fact that a counter must be stored persistently, normal authenticated encryption that covers every kind of packet is usually a better idea, since the few encryption setup packets can usually be tolerated.

  •  Tags:  
  • Related