Fixing BLE Passkey Entry with SRP

Information Security Asked by CompSciGuy on January 21, 2021

First post, not a crypto expert. 🙂


Is it wise to use SRP to implement app-level "passkey entry" pairing in Bluetooth LE? There are known issues with using fixed passkeys in BLE, even with LE Secure Connections.


Andrew Lindell describes an attack where an online brute forcer can guess the BLE passkey in 10 attempts on average- too low for a rate-limiting scheme. He suggests the Bluetooth standard use a PAKE algorithm for each side to prove knowledge of the passkey.
See section 4:

I need to prevent BLE MITM and spoofing attacks between two embedded devices, but the peripheral has no UI or OOB interface. Sadly, I’m stuck using fixed, low-entropy passkeys. The passkey is a 6-digit number unique to each device, and I want to use that as the password in SRP.

My requirements are:

  1. Prevent online brute – Avoid giving on-line brute forcers an advantage as the BLE spec does. Each brute force attempt should reveal minimal info about the passkey, meaning it should eliminate only one possible passkey. (The BLE spec verifies the 20-bit passkey bitwise and reveals 1 bit of the passkey to the brute forcer per attempt.)
  2. Prevent offline brute force – An attacker shouldn’t be able to brute force the passkey using previously captured packets from a successful SRP authentication. (Not to be confused with offline-brute force attacks against a stolen verifier database. See asterisk below.)

The wiki and Stanford page on SRP suggest SRP meets my two requirements, but I’m not confident I’ve understood the inner workings of SRP enough to assertain this. Does SRP fulfill these requirements?

Thoughts on #2: Fortunately, the algorithm doesn’t seem to send a hash of the password, which a sniffer might brute force using a dictionary of hashed passwords. But not sure if this is true, since this requirement will supposedly fail if the server doesn’t check client’s proof of the shared secret first. I’m worried about this since the passkey has such low entropy.


  1. Stolen verifier database – I’m not concerned about the performance of SRP if the verifier database is stolen. I have no verifier database to speak of, since I’m not implementing a web app with centralized storage of credentials. Both the embedded devices will have the plaintext password.
  2. Implementation – I plan to use the libSRP implementation from Tom Wu. It’s old. Any known issues with this? GitHub
  3. I know that dynamic passkeys or OOB pairing is the right answer here, but I’m forced to do the best I can for our current generation of hardware.

Add your own answers!

Related Questions

Whatsapp suspicious message

1  Asked on October 28, 2021 by perpetuallearner


I accidentally downloaded a .bin file, should I be worried?

1  Asked on October 28, 2021 by iknownaught


Secure a virtual machine during a lab exercise

2  Asked on October 28, 2021 by martin-frholz


HTML Injection to blind SSRF testing retrieves only DNS Query

0  Asked on October 28, 2021 by none_none


Ask a Question

Get help from others!

© 2023 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP