Cutting-edge System-on-Chip (SoC) models are embedded with increasingly sophisticated technologies, yet the security of these powerful features remains under-investigated. As cyberattacks that exploit vulnerabilities in microarchitecture surge, researchers at Télécom Paris are working with Arm technology to fill the knowledge gap.
The team is implementing an SoC processor named ARCHISEC (micro-ARCHItectural SECurity) that models security vulnerabilities. The novel technology is deployed on a virtual platform based on the open-source processor simulator gem5. ARCHISEC will identify security weaknesses, anticipate future attacks, and propose protections. It will also increase performance level and reduce consumption, say the team.
ARCHISEC is a large-scale, collaborative project that is composed of:
Together, the partners have built an active research community around the platform that will provide essential security insights for the industry.
We spoke to Quentin Forcioli, a PhD researcher specializing in microarchitecture security at Télécom Paris, to find out more.
The key aim of the ARCHISEC project is to build system-on-chip models to investigate security properties using gem5. We can add different elements and use monitoring tools to and interact with the simulation.
In security research, we cannot only have proof of concept. We must create attacks and scenarios which are realistic. We also must demonstrate that a micro architecture attack that is possible in theory is also possible in a real environment. We want to show that the attack can be scaled from a simple proof of concept to a real-life attack. Statistical analysis is not enough, we need to have ‘remodel’ abilities to effectively understand how cyberattacks and security behaviors work on real systems.
ARCHISEC demonstrates that we can implement a sufficiently precise model with gem5 that can emulate real-life security issues. We can then create countermeasures in-program or in-implementation to defend against microarchitecture attacks. That is the key element. But you can also use gem5 to provide more information, when you connect to other external tools, about how those attacks behave. We can create dynamic models and reactive elements. We can reorganize or monitor simulation behavior to extract security information dynamically.
“We chose Arm as a research platform because of the elements that we wanted to demonstrate in the project. There have been multiple research projects based on x86 in-server environments where the user has full control, but Arm – being used in smartphones or other environments – is more on the embedded side. It has more security features that are generally less studied.”
For me, it is a very interesting project because I like simulation. Reproducing real-life behaviors to better understand them. I am specifically working on cyberattacks that require execution ability but not necessarily physical access. Some colleagues are working on attacks that use power effects and power side effects, but generally, we try to focus on remote access.
New research frontiers
We chose Arm as a research platform because of the elements that we wanted to demonstrate in the project. There have been multiple research projects based on x86 in-server environments where the user has full control. However, Arm, being used in smartphones or other environments, is more on the embedded side. It has more security features that are generally less studied. We also wanted to have SoCs that have a diverse variety of elements inside them, and this was not possible in x86.
Most of our work is not really identifying new attacks but identifying how to use existing attacks, or already discovered attacks. We have been using models that we can modify to reproduce specific behaviors that we know can be used in real-life but have never been demonstrated as an actual attack.
For example, I am generally using cache timing attacks that we know can likely be used against a specific secure enclave. However, no one has really demonstrated how to use them. So, we have these attacks that we already know can exist in real-life but are only working in theory. We can reproduce an attack in a simulation and then use said simulation to build a real attack on a real program – not only on the proof of concept.
As an architecture researcher, I want to build knowledge on how processes are implemented. Security is one of the key prospects you can research in this area. In my work, I am trying as much as I can to have an influence on what the field is doing. My hope is that we will see more precise use of simulators and more interesting research on using simulators to study security. We want to be able to reproduce security side effects without reproducing the full system.
“We also wanted to have SoCs that have a diverse variety of elements inside them, and this was not possible in x86.”
In the future, we would like to have improved understanding of how to use, and how to hide, the side effects of an attack in the real system. How to mitigate these possibilities of attack without having to change the design. Without having to create a new cache implementation or system implementation that stays on the drawing board and never goes inside a real system. It is about studying a full simulation so you can modify software to mitigate most of the side effects of an attack.
Some of our ARCHISEC partners in other parts of France have been focusing on different elements of SoCs in the project. There are people working mostly on RAM and people working mostly on FPGA. It is by working together and assembling different models, that we can create a full model of the SoC. With a complete model we can demonstrate multimodal attacks or multimodal information leaking.
Maybe one victory will be a multimodal attack that uses different parts of a SoC to attack the same program. It will be really interesting if we can do that.