About SideLine Impact
SideLine is unprecedented
This is the first time that intra power side-channel attacks are launched on complex SoCs with rich OS implemented. Especially it introduces internal CPU-vs-MCU side-channel attacks which clearly meet real-life scenarios on state-of-the-art SoCs.
SideLine is not obvious
It does not use a sensor. It leverages a performance mechanism whose security implication was not even questioned until now. It is the starting point of a novel area of research distracting hardware IPs from their primary use to collect information.
SideLine is everywhere
Every processor that uses external memory is potentially vulnerable. While our contribution focused on ARM devices, x86 and RISC-V exploits seem likely to arise in the near future.
SideLine is not a magic bullet
It doesn't pretend thwarting existing counter-measures against SCA. Rather it aims at warning the community that even remote systems, that by nature were not supposed to be the target of SCA, are now at risk.
About Attack Privileges
The attacker is root:
He can use mmapping to access the delay line registers.
He may target an encryption trustlet running within a Trusted Execution Environment.
He may target a crypto module or a security dedicated MCU e.g AP-to-MCU scenario in the paper.
The attacker isn't root:
No access to mmapping
He may take advantage of an existing kernel device that enables user-space processes to access the memory controller registers (e.g through DRAM test program disassembling) and then conduct the above attacks.
Other Questions
About Setup Complexity:
All we need is a laptop (acquisition and CPA), a micro-USB cable and the development board. (an AC adapter was used for the second target).
Was the temperature controlled?
No, during the Covid19 period, we had to conduct the experiments outside the lab with no access to any thermal chamber. However, the temperature noise was taken into account to improve the attack results. We attenuated its effect by applying post-treatment high-pass filtering on the collected SCA traces.
How did you run OpenSSL in a bare metal setting?
The workaround we found was to only download AES related sources. We then used the AES_ecb_encrypt function to conduct the experiments.
How can one actually read out the command register?
By simply reading at the register physical address: DLL_value = *(volatile u32 *) DLL_Addr
Do you assume nothing else is running on the system?
No, there is the whole Linux rich OS running in background with kernel processes, interrupts, etc.
Can you generate a baseline while some other, unknown code is running?
Yes, we are working on multi-core processors that handle simultaneous thread execution.
How do you know when an encryption is being performed?
In local SCA, the attacker needs to trigger an encryption. We believe that the exact same is possible in an internal SCA scenario. Hence, the application processor (attacker) may trigger hardware acceleration (victim) by asking for a signature, an encryption, etc.
About DLL update frequency:
By definition, the DLL update has to be fast to ensure proper DRAM operation. That's why we obtain decent sampling frequency (16MHz) compared to what we could have done with low cost ADCs (<1MHz).
About DLL data type:
The datatype is defined as delay value. The command range is (0:64) for coarse-delay and (0:3) for fine-delay. The delay value can be represented as the phase shift applied to the signal. Unfortunately, SoC providers do not give precise information to convert the delay value into phase shift.
