Delay-Lines Leak Secrets from your SoC
SideLine is a software-based power side-channel analysis vector. It uses delay-lines (located in SoC memory controllers) as power meters.
There is a strong and reliable relationship between the delay-line state and your CPU activity.
A SideLine-based malware may monitor your power activity without your consent and steal your personal data. Logical isolation, restricted access or tamper resistance do not mitigate Sideline.

SideLine Demo Videos

On Cortex-A and Cortex-M based SoC
Using SideLine we perform several core-vs-core Correlation Power Analysis attacks. For each scenario, one core (the victim) runs Openssl AES encryptions. The other core (attacker) uses SideLine to eavesdrop the victim's core activity.
We target high-end SoCs designed for IoT, automotive or mobile solutions which can run complex OS such as Linux or Android. In the paper, a dual-core Cortex-A9 processor and a dual-core Cortex-A7 processor associated with a Cortex-M4 processor (demo below) are evaluated.

#

Q & A

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.

#

Reproducing SideLine

Responsible Disclosure ongoing...

© Joseph Gravellier 2020, All Rights Reserved