Fixing BLE Passkey Entry with SRP

First post, not a crypto expert. 🙂

TLDR

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.

Background

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: https://www.blackhat.com/presentations/bh-usa-08/Lindell/BH_US_08_Lindell_Bluetooth_2.1_New_Vulnerabilities.pdf

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.

Misc

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.