Key Negotiation of Bluetooth Attack(knobattack.com)
knobattack.com
Key Negotiation of Bluetooth Attack
https://knobattack.com/
108 comments
So it looks like this vulnerability is here to stay. They just raise the bar from "trivially breakable" to "you need a bit of cloudcomputing effort to break a connection".
You don't even need that, you can crack 56 bits on a home machine.
Keep in mind, DES was 56 bits, and it was brute forced in 56 hours in 1997.
http://cs-exhibitions.uni-klu.ac.at/index.php?id=263
You don't even need that, you can crack 56 bits on a home machine.
Keep in mind, DES was 56 bits, and it was brute forced in 56 hours in 1997.
http://cs-exhibitions.uni-klu.ac.at/index.php?id=263
Bluetooth physically requires some time to pass between communication. 2^56 seconds is 2 billion years. I doubt you can try more than 100 times a second.
Huh? You simply capture the packets and crack offline.
7 octets is the minimum set by the SIG, not a mandatory length to support for all devices. For devices that transfer sensitive information (phones, keyboards, etc.), a larger key length can be enforced. This would be enforced by the application written by the product designer, not the BT chipset vendor nor the BT SIG.
Why 7? Is that the longest key the NSA can crack quick enough to mount the attack?
My guess is they're trying to support legacy hardware that might not have the crunching power to do 128/256 with the tight timing constraints on channel hopping?
Either way, still not a good decision.
Either way, still not a good decision.
I expect it's a trade-off between power usage and brute-force resilience.
Nope.
DES also used 56 bit keys. It was crackable by the NSA the moment it was introduced in 1975. And by the 2000s, anyone could crack it.
Even back then, the choice of 56 bits had nothing to do with speed. Chips were more than capable of handling 128 bit keys even in 1975. It's 2019 and we're still proposing 56 bit key lengths? Wow.
DES also used 56 bit keys. It was crackable by the NSA the moment it was introduced in 1975. And by the 2000s, anyone could crack it.
Even back then, the choice of 56 bits had nothing to do with speed. Chips were more than capable of handling 128 bit keys even in 1975. It's 2019 and we're still proposing 56 bit key lengths? Wow.
No, they are not proposing 56 bit key lengths. I understand the key is always 128 bits. They are saying that the entropy should be minimum of 56 bits. In fact the entropy is always 128 bits but this negotiation reduces it because 'some' governments didn't want other governments to have stronger encryption. See [1] page 1050, figure 2.
I don't know how much difference that makes (I am not an encryption expert), but it is a fact that affects your comparison to DES.
[1] https://www.usenix.org/system/files/sec19-antonioli.pdf edit: citation
I don't know how much difference that makes (I am not an encryption expert), but it is a fact that affects your comparison to DES.
[1] https://www.usenix.org/system/files/sec19-antonioli.pdf edit: citation
I understand the key is always 128 bits.
No, the article is about KNOB, which allows the attacker to arbitrarily shorten key length. The proposed solution is to have a minimum 56 bit key length, which is still too short.
No, the article is about KNOB, which allows the attacker to arbitrarily shorten key length. The proposed solution is to have a minimum 56 bit key length, which is still too short.
Was DES crackable by the NSA way back when? Are they known to have had the necessary HW?
Any actual sensibly picked tradeoff would have much more entropy.
The rumor is that 7 bytes is the shortest maximum key length of any devices currently in circulation.
7 bytes is still laughably bad, ofc.
The rumor is that 7 bytes is the shortest maximum key length of any devices currently in circulation.
7 bytes is still laughably bad, ofc.
I'm guessing this is because DES was also 7 bytes. And DES is laughably insecure, even 3DES was retired years ago.
Op is correct, this is not a solution.
Op is correct, this is not a solution.
That doesn't sound plausible. Bluetooth still needs to run the radio, even at low power.
Powern and time (latency).
What isn't clear is if you have a device like a laptop, phone, or tablet, and it _is_ updated post-late-2018... will that protect you from the vulnerability even if you're using an older Bluetooth device (e.g. keyboard, headset, etc.) that isn't going to ever get an update?
[Edit] Found some relevant information from the Bluetooth.com security notice[1]
> For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were establishing a BR/EDR connection. If one of the devices did not have the vulnerability, then the attack would not be successful.
[1] https://www.bluetooth.com/security/statement-key-negotiation...
[Edit] Found some relevant information from the Bluetooth.com security notice[1]
> For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were establishing a BR/EDR connection. If one of the devices did not have the vulnerability, then the attack would not be successful.
[1] https://www.bluetooth.com/security/statement-key-negotiation...
According to https://www.kb.cert.org/vuls/id/918987/ either side can propose a new amount of entropy and the other side can accept or reject it. An updated controller firmware on either side could reject the connection.
Another option mentioned in the paper is for the OS to check the entropy level and close the connection after each renegotiation. I'm not sure if OSes have actually been updated to do that, but it would work for all kinds of devices even without hardware vendor support.
Another option mentioned in the paper is for the OS to check the entropy level and close the connection after each renegotiation. I'm not sure if OSes have actually been updated to do that, but it would work for all kinds of devices even without hardware vendor support.
A rejected connection means a bricked device, on the other hand. Sure, newer drivers could protect me against attacks, but simultaneously prevent me from using my BT headphones.
Hopefully this would only be an issue during an attack. Not sure why your headphones would be legitimately negotiating encryption but then only supporting <7 bytes of entropy.
That's not difficult then, order one of these https://www.raspberrypi.org/products/raspberry-pi-zero-w/ , get a battery pack and fix to some unsuspecting CEO or other juicy corporate targets vehicle. Saves trailing the vehicles and thus raising suspicion.
How many car manufacturers do you think update their vehicles Bluetooth stack?
Mr Robot.
How many car manufacturers do you think update their vehicles Bluetooth stack?
Mr Robot.
Direct link to research paper: https://www.usenix.org/system/files/sec19-antonioli.pdf
Relevant results are on page 1057. It's crazy to think all of the devices tested were vulnerable up to Bluetooth 5.0, but at least the attacker would need to be within range of broadcast, as another user pointed out
Relevant results are on page 1057. It's crazy to think all of the devices tested were vulnerable up to Bluetooth 5.0, but at least the attacker would need to be within range of broadcast, as another user pointed out
but at least the attacker would need to be within range of broadcast
So anyone who lives in a small footprint high-rise or spends ample time on a coffee shop. Yikes!
edit: format
So anyone who lives in a small footprint high-rise or spends ample time on a coffee shop. Yikes!
edit: format
This naming is very unfortunate, but hilarious to any Brits.
I think it’s on purpose. One of the authors is from Oxford after all...
>This naming is very unfortunate, but hilarious to any Brits.
The followup attack targets the "Bluetooth Asynchronous Low Latency Subsystem"
The followup attack targets the "Bluetooth Asynchronous Low Latency Subsystem"
Very amusing, but definitely missing a trick on the Blue/KNOB combo.
Sorry for my ignorance. Can you explain the reference?
From the article 'Key Negotiation of Bluetooth'.
Basically, researchers started naming vulnerabilities when they thought they mattered. 'Shellshock' and 'EternalBlue' are both deserving of names, IMO.
Then researchers started naming everything, many of the vulnerabilities had zero real world impact, were almost entirely theoretical (many crypto vulns), or required chaining of other attacks to actually achieve anything.
The KNoB description says 'is vulnerable to packet injection by an unauthenticated, adjacent attacker that could result in information disclosure and/or escalation of privileges.' which is sounds extremely caveated. They haven't demonstrated an actual attack so my guess is they've overplayed the significance of the vulnerability entirely and this grants the ability to PITM traffic (which really isn't a defensible boundary, anyway).
Most decent hackers I know laugh at named vulnerabilities unless their technical impact actually matters. Dirty COW took the piss entirely, https://dirtycow.ninja, https://www.zazzle.com/collections/white_theme-1195879626504... .
Basically, researchers started naming vulnerabilities when they thought they mattered. 'Shellshock' and 'EternalBlue' are both deserving of names, IMO.
Then researchers started naming everything, many of the vulnerabilities had zero real world impact, were almost entirely theoretical (many crypto vulns), or required chaining of other attacks to actually achieve anything.
The KNoB description says 'is vulnerable to packet injection by an unauthenticated, adjacent attacker that could result in information disclosure and/or escalation of privileges.' which is sounds extremely caveated. They haven't demonstrated an actual attack so my guess is they've overplayed the significance of the vulnerability entirely and this grants the ability to PITM traffic (which really isn't a defensible boundary, anyway).
Most decent hackers I know laugh at named vulnerabilities unless their technical impact actually matters. Dirty COW took the piss entirely, https://dirtycow.ninja, https://www.zazzle.com/collections/white_theme-1195879626504... .
I presume that the parent is referring to https://www.urbandictionary.com/define.php?term=Knob. Warning NSFW text.
Calling someone a "knob" is a bit softer than calling someone a "dick", but they both refer to the same body part.
Kind of a tangent, but I was traveling in Portugal last year, and one day as I was headed to a train station I felt my phone buzz. I picked it up and it had a failed Bluetooth file transfer. In the settings, the device name had changed from the default to what looked like a base64 string, if I remember correctly. Unfortunately I didn't think to screenshot anything.
The phone was literally only a couple weeks old. Nothing new had been paired. I changed the name back and figured I would look it up later. The failed file transfer was automatically cleared (just a phone thing) and I wasn't able to find information about it.
The phone was literally only a couple weeks old. Nothing new had been paired. I changed the name back and figured I would look it up later. The failed file transfer was automatically cleared (just a phone thing) and I wasn't able to find information about it.
A similar thing happened to my phone while I was at Defcon several years ago. After that I put my phone on airplane mode. Then when I got home, I reset all my passwords, and wiped the phone.
Is people trying to hack the attendees a common occurrence at Defcon?
Can be, the Wall of Sheep mentioned here is from the traffic on the DefCon network. General practice is to make sure at least your bluetooth and wifi are turned off. Realistically, no one is going to use a 0-day to hack into your personal phone.
It's Defcon, so yes.
So much so there is a 'wall of shame' projector posting attendees credentials for all to see.
That's for unencrypted credentials captured going across the wire by the ops team. That's to highlight insecure comms not hack people.
There was an instance where someone used a wifi pineapple 0day to brick pineapples, which are considered script kiddie tools in many circles.
Generally nobody will waste a valuable 0day at defcon to attack a personal device. If you get popped it's probably because you're running known vulnerable software.
There was an instance where someone used a wifi pineapple 0day to brick pineapples, which are considered script kiddie tools in many circles.
Generally nobody will waste a valuable 0day at defcon to attack a personal device. If you get popped it's probably because you're running known vulnerable software.
I think that should be "wall of sheep".
Always treat Defcon as a dangerous place
No its more of an urban legend. I'm sure there's some hijinks going on but I doubt the hotels would tolerate any kind of large scale malicious activity especially with all the unrelated people staying at the hotel
DefCon sets up its own wifi networks, it doesn't use the hotel's wifi
Do you have sources for that? It’s unlike what many people who attend claim so I’d like to know what it’s based on.
I concur. While I bring a "burner" phone and laptop, it's more so I have a scratch system I can play / experiement on than any real fear that a sensibly configured device is going to get pwned. I used my real phone and laptop during Defcon 27 last week, too. I do have bluetooth off, and I made sure I had no filesharing enabled, and the latest patches, etc.)
I've been to about 10 defcons, and I've never had a device pwned that wasn't a spare device I was playing with.
I've been to about 10 defcons, and I've never had a device pwned that wasn't a spare device I was playing with.
https://en.wikipedia.org/wiki/Bluesnarfing
I might be misremembering technologies, but I think in BT the incoming connection can directly execute commands on your device without any kind of identification/authorization.
I might be misremembering technologies, but I think in BT the incoming connection can directly execute commands on your device without any kind of identification/authorization.
Obvious attack target: Bluetooth keyboards for keylogging.
Obvious solution: never use wireless input devices.
Has the added benefit of never having to deal with charging batteries or charging.
Has the added benefit of never having to deal with charging batteries or charging.
Obvious solution, don't use anything that emits electromagnetic radiation: https://en.m.wikipedia.org/wiki/Van_Eck_phreaking
Well, time to go back to typing everything on a typewriter.
Your data will leak regardless because of typewriter keystroke acoustics [0]. So you better have a soundproof room for that purpose.
Keep any electronics out of the room that might have a microphone. Like phones, laptops, or running mechanical hard drives [1].
[0]: https://arxiv.org/abs/1609.09359
[1]: https://spqr.eecs.umich.edu/papers/Kwong-HDDphone-IEEE-SP-20...
Keep any electronics out of the room that might have a microphone. Like phones, laptops, or running mechanical hard drives [1].
[0]: https://arxiv.org/abs/1609.09359
[1]: https://spqr.eecs.umich.edu/papers/Kwong-HDDphone-IEEE-SP-20...
Well you can avoid all software vulnerabilities by not using computers at all, right?
Maybe I should use an Ethernet cable on my iPhone instead of LTE, that should be convenient.
Maybe I should use an Ethernet cable on my iPhone instead of LTE, that should be convenient.
As soon as people stop treating the physical layer as a security control, the better.
Encrypt your damn comms.
Encrypt your damn comms.
Never trusted wireless keyboards always uses cable connected devices. Although those could still be tapped by a usb sniffer but it’s more safe than wireless.
The Bluetooth attack seems similar to car keyfob attacks. Block and replay.
A directional antenna could do the Bluetooth attack from distance.
Counter measures to key logging use one time passwords otp. A password strength also depends on password age.
The Bluetooth attack seems similar to car keyfob attacks. Block and replay.
A directional antenna could do the Bluetooth attack from distance.
Counter measures to key logging use one time passwords otp. A password strength also depends on password age.
Wireless mice that use their own little receivers and not bluetooth are also very susceptible to monitoring.
See: https://www.theverge.com/2019/7/14/20692471/logitech-mouseja...
I use a wired keyboard, but I also use a wireless mouse! I've been careful at DEFCON not to.
See: https://www.theverge.com/2019/7/14/20692471/logitech-mouseja...
I use a wired keyboard, but I also use a wireless mouse! I've been careful at DEFCON not to.
Only keyboards that use BR/EDR are affected. BLE keyboards are unaffected.
Sadly, many BLE keyboards on the market today are still not using the LE Secure Connections feature during pairing. The LE legacy pairing algorithm does not use Elliptic Curve Diffie-Hellman Key Exchange, and is easily susceptible to having the encryption cracked via passive eavesdropping.
Do you know one keyboard on the market today that has LE Secure Connections feature enabled?
I don't know of any because I haven't tested too many, but LE Secure Connections has been around since the Bluetooth 4.2 spec, which was adopted in 2014. The feature is supported by most single-mode BLE chipsets / stacks that have been released since then. I'd be surprised if there were none that supported it, though I don't know for sure.
How easy is this attack to pull off? Doesn't bluetooth use spread spectrum? If so, you'd need to somehow predict the frequencies that will be used, which is non-trivial because it's generated from the link key.
At least for listening, a $100 software defined radio would be able to sample the whole band in one go without needing to follow the frequency hops.
I don’t think the price point is quite that low yet, is it? I have a couple I bought for $250 that can do that, but I’m not aware of a readily available radio that can receive 80MHz+ at that price point. If you can point me to it, I’ll probably buy a couple immediately.
I own most of the commonly available SDRs, and I’m also not aware of any that can do that wide of a range at $100 price point. Like you, I’d be happy to be proven wrong (albeit my wallet won’t be).
79MHz, so you will need 4x $100 HackRF (price for bare board, no case/cabling). https://www.ebay.com/itm/HackRF-One-1MHz-to-6GHz-Software-De...
I have several HackRF boards. That’s not 80MHz for $100, that’s 20MHz for $100.
This is not a trivial attack. Within the short key negotiation phase, the attacker must simultaneously prevent the two devices from hearing each other, and be transmitting in their place at the exact frequency hop and interval.
"The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window. "
"The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window. "
That quote is from the Bluetooth standardisation group’s response. They are clearly trying to downplay the seriousness with their choice of language here. “All within a narrow time window” is, generally speaking, something computers are capable of handling. I have no idea from that statement how easy/tricky this attack is. Also, is it really necessary to block transmissions, or can the attacker just “get lucky” and have his transmissions received first? (Honest question, I have no idea)
For BT, it's not a matter of transmitting first (for Wifi it would be), but rather transmitting in the exact time slot that the two devices are expecting each other to transmit. This is tightly timed in BT devices (tens of microseconds)--they are only listening on tiny intervals and only expected to transmit on tiny intervals. It would sound like periodic chirping if you were able to hear it with your ears.
Meanwhile, the two BT devices are going to be transmitting in their normal time slots, so you would need to prevent them from being heard by the peer-- otherwise, the combined transmission (of the attacker and original BT device) will look like noise to the receiver and the attack would fail.
The attack is certainly doable, but in a practical setting would be extremely difficult.
Meanwhile, the two BT devices are going to be transmitting in their normal time slots, so you would need to prevent them from being heard by the peer-- otherwise, the combined transmission (of the attacker and original BT device) will look like noise to the receiver and the attack would fail.
The attack is certainly doable, but in a practical setting would be extremely difficult.
You are not thinking like an attacker.
The attacker has to hit the precisely correct time slot. However, there is no penalty for hitting the wrong time slots, so the easy solution is to just sync the timeslot boundaries by listening once and then retransmit on every timeslot.
The attacker has to somehow prevent the listener from hearing the original transmission. If the attacker retransmits at a similar power, as BT devices usually do, the combined transmission will look like noise. However, the attacker doesn't need to care about things like FCC rules or BT standards, and can simply transmit at a power few order of magnitudes greater, so that what the receiver hears is pretty much just the attacker.
The attacker has to hit the precisely correct time slot. However, there is no penalty for hitting the wrong time slots, so the easy solution is to just sync the timeslot boundaries by listening once and then retransmit on every timeslot.
The attacker has to somehow prevent the listener from hearing the original transmission. If the attacker retransmits at a similar power, as BT devices usually do, the combined transmission will look like noise. However, the attacker doesn't need to care about things like FCC rules or BT standards, and can simply transmit at a power few order of magnitudes greater, so that what the receiver hears is pretty much just the attacker.
There certainly is a penalty for missing time slots (especially if you're trying to overpower the other transmitter). There are two reasons for this: (1) the victim device will have hit the time slot and the pairing process will move into the next stage and (2) packet counters will prevent you from using the same packet in the wrong slot.
Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually.
Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually.
> packet counters will prevent you from using the same packet in the wrong slot.
Source to back up that claim? I am not an expert, but have enough experience on the topic to feel justified in feeling that’s wrong.
Source to back up that claim? I am not an expert, but have enough experience on the topic to feel justified in feeling that’s wrong.
The way you're describing this makes it sound like an extremely difficult process. In some ways, it is. However, every BT device that exists is currently capable of doing this frequency tracking and tight timing. It's merely a matter of starting to transmit slightly earlier and significantly louder than a normal BT transmit after sniffing the start of the connection.
This attack should be possible from any software-defined radio that's capable of sniffing on and forming BT connections.
This attack should be possible from any software-defined radio that's capable of sniffing on and forming BT connections.
Quoting my response to Tuna-Fish:
"Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually."
And if you do manage, it's granting the ability to intercept/modify traffic, right?
If so, this won't lead to RCE on a host mobile unless other exploits are used. There's probably some interesting stuff that can be done against shitty IOT-type devices, but they should be assumed vulnerable anyway...
If so, this won't lead to RCE on a host mobile unless other exploits are used. There's probably some interesting stuff that can be done against shitty IOT-type devices, but they should be assumed vulnerable anyway...
That's true for use cases like phones and headsets where the physical device can't reasonably be tampered with. But this sounds like something you could trivially squish on top of an unattended reader device a-la credit card skimmers.
Not sure I understand what you mean.
If one side of the communication is a fixed device subject to simple tampering (e.g. "put your phone here for access") then you can MitM the connection is much the same way as was done with ATM skimmers.
Or with a little more difficulty, you could pop open a bluetooth keyboard, put a shield over the antenna, and MitM what it says to its already-paired desktop to implement a keylogger.
These aren't remotely accessible vulnerabilities to internet hackers, but they're the kind of thing that has been done by amateurs in the past in other realms.
Or with a little more difficulty, you could pop open a bluetooth keyboard, put a shield over the antenna, and MitM what it says to its already-paired desktop to implement a keylogger.
These aren't remotely accessible vulnerabilities to internet hackers, but they're the kind of thing that has been done by amateurs in the past in other realms.
Agree that it would be significantly easier if you had physical access either of the devices. However, with physical access there are probably even easier attack vectors (e.g. in the case of a keyboard, why not just capture the key presses directly instead of trying to capture it as it's going over BT?).
Depending on the BT tech your hopping either 79 or 29 channels, not that many. Find the increment and hop timing and you can hop along with them.
>you can hop along with them
The hopping sequence is determined pesudorandomly (not sequentially) using the link key, so you can't exactly "hop along" once you find the right channel.
The hopping sequence is determined pesudorandomly (not sequentially) using the link key, so you can't exactly "hop along" once you find the right channel.
I thought the hopping sequence and clock was adopted from the master during the paging process, as the slave joins the network, before the link negotiation process even begins.
https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/l...
https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/l...
There are Bluetooth sniffers available for low $ks that can listen on all channels simultaneously.
Haven't worked my way all through the paper yet. But is it correct that an attacker can perform this attack to something like a keyboard that has been previously paired and everything? What kind of user "interaction" would be required? Will the OS re-pair the device and (possibly) notify the user?
This seems really powerful and dangerous. Probably not that many people who uses laptops and BT keyboards, but many of the iPad keyboard covers uses bluetooth.
This seems really powerful and dangerous. Probably not that many people who uses laptops and BT keyboards, but many of the iPad keyboard covers uses bluetooth.
Not a Bluetooth expert and I might have misunderstood the paper but it seemed like it can be done any time two devices initiate a new connection (not when they're paired but anytime they start communicating). AFAIU, it's a firmware level hack so not something you can do with standard Bluetooth functionality. You need to be able to get a custom firmware into the Bluetooth chipset to carry off an attack.
I presume that you could pull it of with a SDR.
Good question. Can the attacker force an existing paired device to re-negotiate the pairing process, or is this attack only viable against devices that have not yet paired?
I think an attacker can disrupt already existing connections causing them to reconnect but if they try to re-pair then operator interaction would be required.
I think that this attack only works when the encryption is being negotiated, which is usually when the connection is made (you can do it later, or redo it at any time)
I think that this attack only works when the encryption is being negotiated, which is usually when the connection is made (you can do it later, or redo it at any time)
In case anyone else is wondering: I believe this doesn't affect Bluetooth LE Secure connections, though the authors don't state that explicitly.
That is correct. The vulnerability note clearly states that this only impacts "Bluetooth BR/EDR Core v5.1 and earlier". "BR/EDR" is the technical term for Classic Bluetooth; in other words not Bluetooth Low Energy.
The authors state that it impacts BR/EDR, but not exclusively so. If the standards shared enough aspects of their key negotiation protocols, then both could potentially be impacted. After scanning through the paper and the relevant details of the LE Secure pairing process, that does not appear to be the case, fortunately.
[deleted]
Was this known previously or was there another entropy attack? I remember reading about this or a similar attack a while ago but don't remember if the details matched.
Are there any known similar vulnerabilities for OpenThread? I suspect Thread would be more secure and probably a better choice for meshed networks
That especially means: don't use a Bluetooth keyboard. Never.
probably need to check the update release notes if there is any mention about fixing this on the devices.
Recently there was an update to my Android on my Samsung Galaxy S8 that makes it HARDER to see if Bluetooth is turned on. I like to leave it off whenever I'm not using it to try to reduce the attack surface.
Not sure this is really the same thing. However in my case I like it harder because I use bluetooth multiple times a day with my phone and it's annoying having a persistent icon showing me it's on despite not caring.
Here's their plan to fix this: "To remedy the vulnerability, the Bluetooth SIG has updated the Bluetooth Core Specification to recommend a minimum encryption key length of 7 octets for BR/EDR connections"
7 octets, aka... 56 bit.
So it looks like this vulnerability is here to stay. They just raise the bar from "trivially breakable" to "you need a bit of cloudcomputing effort to break a connection".