Hi guys! This is actually a problem we will need to solve in the product I'm currently developing at my company.
In our case, we have a peripheral with no screen or I/O capabilities that connects to an app via BLE. As I understand it (and mike explained very well in his videos), once the key are generated, the communication is secure. The problem is you can do an attack that forces a reconnection with the smartphone, and forces to generate new keys, and then the system is completely vulnerable. As Tim said, the more secure way of doing the pairing is NFC, but the problem is that is not available on iOS. In our case, because we have GPRS communication with a server, we can try to do the key exchange with a server request, therefore protecting the system from the MITM / reconnection hack. Does anyone have experience doing this? Do you believe is a viable option? Thanks beforehand. 2016-12-01 18:49 GMT+01:00 Mike Ryan <[email protected]>: > 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. > > > >
