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: 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:
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.
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP