As someone who finally recently escaped bluetooth firmware development: yes, Bluetooth is leaking secrets and it doesn't even require any silly RF shenanigans. Almost nothing actually implements LESC. Apple refuses to implement OOB pairing, so no peripherals can force you to use it, so everything is subject to MITM attacks. The entire ecosystem is a mess of consultants and underpaid devs copy-pasting Nordic sample code, with no time or financial incentive to do more than the bare minumum. Never trust any product that moves sensitive data through Bluetooth.
Apple claims to have implemented an entire second security level for their Bluetooth apps based on iMessage, but I trust it not at all.
(To be clear, I trust the iMessage protocol with reasonable confidence. I judge the probability that Apple has applied this extra layer of security uniformly to all sensitive data to be about 8%.)
They're on an proprietary extension of Bluetooth, standard compatible but closed to their devices. They usually don't talk much about it, Phil Schiller was the most explicit I think (it was about the airpod's W1 but it's the same deal)
Rotating keys frequently would probably help. But the best thing to do is use implementations that are less leaky in the first place (which is easier said than done).
On the other hand, I’d argue that it’s close enough to trivial to be considered trivial. How many embedded devices transmit sensitive information?
Now, I know that pretty much every Bluetooth based credit card reading device explicitly defends against a channel such as this, but there are tons of access control solutions, and medical devices that don’t
Would you notice a raspberry pi tucked into the mess of wires beneath the security guard guards desk?
> How many embedded devices transmit sensitive information?
Every Zigbee device uses AES keys to secure the network, although the security of the protocol is pretty weak in most deployments, especially when new devices join the network. Leaking the network key would provide access to the entire network. The ARM Cortex-M4 is often used, which the side-channel attack in the article is about.
As someone who finally recently escaped bluetooth firmware development: yes, Bluetooth is leaking secrets and it doesn't even require any silly RF shenanigans. Almost nothing actually implements LESC. Apple refuses to implement OOB pairing, so no peripherals can force you to use it, so everything is subject to MITM attacks. The entire ecosystem is a mess of consultants and underpaid devs copy-pasting Nordic sample code, with no time or financial incentive to do more than the bare minumum. Never trust any product that moves sensitive data through Bluetooth.
Apple claims to have implemented an entire second security level for their Bluetooth apps based on iMessage, but I trust it not at all.
(To be clear, I trust the iMessage protocol with reasonable confidence. I judge the probability that Apple has applied this extra layer of security uniformly to all sensitive data to be about 8%.)
8.75% surely? you need at least two digits of specious precision on that non-random number.
Text written with a non-apple Bluetooth keyboard is green?
> Apple claims to have implemented an entire second security level for their Bluetooth apps based on iMessage,
iMessage... the golden standard for 1click RCE. /s
Just curious if it that insecure how does Magic Keyboard with Touch ID works? Does it use some apple proprietary "magic"?
> "magic"
They're on an proprietary extension of Bluetooth, standard compatible but closed to their devices. They usually don't talk much about it, Phil Schiller was the most explicit I think (it was about the airpod's W1 but it's the same deal)
https://www.theverge.com/2016/9/7/12829190/apple-w1-chip-iph...
> Apple’s Phil Schiller described Apple’s move to a new wireless chip as “fixing the challenges” of wireless audio
Time for everyone to implement some variation of https://www.bluetooth.com/specifications/specs/authorization... ?
I read the abstract, while not familiar with the topic, how would we go about limiting the inpact?
Rotating keys frequently would probably help. But the best thing to do is use implementations that are less leaky in the first place (which is easier said than done).
A side channel attack revealing AES key from just 90,000 traces.
Sigh, side channel attacks seem to be everywhere now.
That 90,000 traces did take 225 hours to capture so it is truly a huge amount of data and not a trivial attack.
On the other hand, I’d argue that it’s close enough to trivial to be considered trivial. How many embedded devices transmit sensitive information?
Now, I know that pretty much every Bluetooth based credit card reading device explicitly defends against a channel such as this, but there are tons of access control solutions, and medical devices that don’t
Would you notice a raspberry pi tucked into the mess of wires beneath the security guard guards desk?
> How many embedded devices transmit sensitive information?
Every Zigbee device uses AES keys to secure the network, although the security of the protocol is pretty weak in most deployments, especially when new devices join the network. Leaking the network key would provide access to the entire network. The ARM Cortex-M4 is often used, which the side-channel attack in the article is about.
That's less than two weeks.
For one key, assuming it does not change within that time.
people are finally aware everything leaks, it's just a matter of how closely you look
Everything leaks if you stare at it long enough
Everything has data exhaust.... the exhaust type just differs.
There's a lot of signal left between you and the noise floor!
Worse: noise floor is a matter of definition.