Screaming Channels - possible countermeasure?

[Frans Lundberg]

Recently, the side-channel attack "Screaming Channel" was described in a paper (http://s3.eurecom.fr/tools/screaming_channels/). The authors demonstrate a remote, passive, side-channel attack on nrf52 that allows data to be compromised if the processor handles sensitive data at the same time as the chip is transmitting over the radio.

What is a good countermeasure to this attack?

The paper (Section 7.3) mentions one promising countermeasure; "to ensure that the radio is never active in transmit mode during sensitive computations". However, is this possible with the SoftDevice approach. Do I, as a developer, have complete control over when the radio is transmitting or not? In practice, how could this countermeasure be programmed?

[haakonsh]

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.