RE: Screaming Channels - possible countermeasure?

haakonsh — Wed, 19 Sep 2018 11:09:59 GMT

Not running continuous AES-128 computations on the same key in SW while continuously transmitting on a single channel for an extended period of time.

If you use HW accelarated AES-128 then this is not a feasable attack as the digital GND leakage of the HW AES wont carry the same quality of information as the SW AES.

We never run AES encryption while transmitting with our SoftDevices, and we offer HW accelarated AES encryption. There's not really anything you will have to do.

In short this is an extremly difficult attack that requires access to the FW in order to carry out, and a large amount of time. If you've already got access to the FW then you do not need this attack at all. This is interresting research, but it has yet to be re-produced. I'm not doubting the reasearchers, quite the opposite, the attack they have described is increadibly difficult and as of now not practically feasable outside the lab. We're not worried about Screaming Side Channel Attacks today, nor do we worry about it in the future. There are already security flaws in the BLE spec that needs a lot more focus than SSC Attacks: nWP031 - Security Threat in Bluetooth LESC Pairing.

Also note that the reasearchers chose the nRF52 because of its ease of development and not because it is any more vulnerable to screaming side channel attacks than any other radio + MCU solution.