Yes I know it is only against the pairing phase (I did say that in my previous email), but as Rodrigo said you can (apparently) force re-pairing so that is a small comfort. And I have read the spec and as far as I can tell, Francisco Corella is correct: 'LE Secure Connections' in BLE 4.2 uses the same Passkey Entry method as in Bluetooth Classic 2.1, which has been broken.
Specifically compare page 6 of the 2008 Lindell attack <https://www.blackhat.com/presentations/bh-usa-08/Lindell/BH_US_08_Lindell_Bluetooth_2.1_New_Vulnerabilities.pdf> on Bluetooth 2.1 to Volume 3, Part H, Section 2.3.5.6.3 (lol) of the Bluetooth 4.2 Core spec <https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439>. The only difference I can see is that they changed from `f1` (HMAC-SHA256) to `f4` (AES-CMAC), presumably because BLE devices have hardware AES support. I can't see how that defeats the attack. Admittedly I'm not a crypto expert so I could be wrong but it's not exactly a complicated attack. Maybe I'll have ago at implementing it! Cheers, Tim On 1 December 2016 at 17:49, Mike Ryan <[email protected]> wrote: > Your link confounds different Bluetooth versions and different attacks. > The TL;DR: > > LE Legacy Pairing is broken and has been known to be broken since its > inception. I wrote on it in 2013[1] and released crackle[2] to > demonstrate it. > > LE Secure Connections address all the weaknesses of legacy pairing. If > both hosts support LE SC, you are invulnerable to a _passive_ attacker. > Without a display, an _active_ attacker can still MitM you. This is a > much more challenging attack. > > Based on my reading of the spec, it's not possible to mandate LE SC even > if both stacks support it. Thus an active attacker can attempt a pairing > downgrade attack to force the use of the weaker legacy pairing. However > in this scenario the attacker can fully MitM the connection, so a > pairing downgrade is basically pointless. > > Finally, all of these attacks are only against the pairing phase. Once > two devices have paired and exchanged keys, the runtime > encryption/authentication (based on AES-CCM) is not vulnerable to any > attacks. > > [1] https://www.usenix.org/conference/woot13/workshop- > program/presentation/ryan > [2] https://github.com/mikeryan/crackle > > On Thu, Dec 01, 2016 at 11:18:30AM +0000, Tim Hutt wrote: > > See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/ > > > > Basically its a mess. As far as I can tell, the actual encryption > (AES-128 > > CCM) is fine, but the key exchange (pairing) methods are all broken in > > various ways. Just Works is vulnerable to MitM by design (a reasonable > > trade-off for the improved usability in some cases). Numeric Comparison > is > > actually secure, but it requires Bluetooth 4.2, a screen and "yes/no" > > buttons on both devices which is very often not possible. Passkey Entry > > (i.e. a PIN) is totallly broken. OOB is secure but you can't use it > anyway > > because of lack of support on Android and iOS. > > > > Also note that the 'LE Secure Connections' feature is optional even in > > Bluetooth 4.2. So even if you have a phone or peripheral that supports > > Bluetooth 4.2, it might still use the legacy methods. > > > > On 30 November 2016 at 17:06, Mike Ryan <[email protected]> wrote: > > > > > This is the first I've heard of LE Secure Connections having any > > > weakness. Can you elaborate and/or provide a citation? > > > > > > On Wed, Nov 30, 2016 at 12:23:06PM +0000, Tim Hutt wrote: > > > > Just in case you weren't aware, OOB is not available on iOS or > Android > > > > (except via NFC). Also all BLE pairing methods except OOB and Numeric > > > > Comparison (which requires a screen) are apparently broken in various > > > ways, > > > > even with LE Secure Connections. > > > >
