Tim. Thanks for the reply! So there's no way for the BLE library on iOS and Android to get the key from an external source? (like a server request) and use that?
I'm more experienced on the firmware/peripheral side than in the app one (I just did some minor test projects on Android). Also, how does an in house developed crypto will work and how could be implemented? 2016-12-02 11:22 GMT+01:00 Tim Hutt <tdh...@gmail.com>: > 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 <miker...@lacklustre.net> 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 <miker...@lacklustre.net> > 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. > > > > > > >
