• caglararli@hotmail.com
  • 05386281520

Why does Bluetooth Low Energy Secure Connections with Passkey Entry check the Passkey bit by bit?

Çağlar Arlı      -    11 Views

Why does Bluetooth Low Energy Secure Connections with Passkey Entry check the Passkey bit by bit?

If we want to enable an authenticated connection via BLE the passkey method seems like a good idea. A 6-digit PIN is generated randomly on one device and has to be entered on the other - these 20 Bit of entropy should be a reasonable countermeasure against authenticated connections and MitM attacks, taking into account that the speed for connection attempts is limited by the advertising protocol.

But according to this article the generated passkey is not used for generating the LTK or something similar. It is instead just compared bit by bit, thus telling the attacker immediately wether the transmitted bit is correct or not. This interesting implementation basically reduces the amount of different values to check (at maximum!) from 1 million to only 20. Thus 20 Bits of entropy became only 4.3 Bits...?

Quotes from the article:

BLE uses an interesting approach for comparing the parties’ passkeys. It uses a bitwise commit-based approach where each bit of the passkey is committed individually by each party. After committing to the bit, the parties reveal the committed bits to each other to verify that the bit has the expected value. As soon as there is a discrepancy, the authentication procedure is canceled.
[...]
As each bit in the passkey is verified individually, we can effectively brute-force the passkey bit-by-bit. The design of the protocol makes this very effective. We need to brute-force only 20 bits, and each correctly guessed bit does not introduce any overhead. For every incorrectly guessed bit, we need to reconnect. However, as soon as the remote device signals that the bit was incorrect, we immediately know the correct bit value — the inverse of the value we sent. So in the worst case, if every bit is guessed wrong, this requires 19 reconnection attempts.

What could be the reason to implement it this way? I completely fail to see a benefit of this approach, yet I assume the Bluetooth SIG had put some thought into it before releasing the spec.