by Frédéric Besson, Célia Le Du (Inria), and Pierre Wilke (Centrale Supélec Rennes)

Hardware and software solutions for protectecting against timing side-channel attacks are effective in securing sensitive data, but significantly impact the performance of the programs they protect. The SCRATCHS project, which stands for Side-Channel Resistant Applications through Co-designed Hardware/Software, aims to combine security and execution speed by developing a new hybrid protection solution based on hardware and software co-design.

Observing fingerprints left on a building’s keypad to guess the entry code, or analysing the sound of keyboard keys to deduce a typed password are examples of side-channel attacks. These attacks are numerous and extend into more advanced cybersecurity contexts. This type of attack involves extracting sensitive information by observing and interpreting signals emitted by a computer system. Attackers use information such as the execution time of a program, its power consumption, or the state of the memory cache to deduce cryptographic information, such as encryption keys.

The SCRATCHS project aims to create a new protection solution that combines hardware and software solutions, focusing particularly on cache-based timing side-channels. This solution would ensure security while maintaining high performance.

Started in 2021, this project is supported by the LabEx CominLabs and brings together researchers located in Rennes, Lorient, and Brest, working in the Lab-STICC and IRISA research laboratories. These researchers are affiliated with institutions such as INRIA, CentraleSupélec, ENSTA Bretagne, and the University of South Brittany. SCRATCHS benefits from collaboration among experts in the fields of formal methods, software-hardware interface security, hardware design, and microarchitecture.

Hardware and Software Countermeasures
The main types of hardware countermeasures against cache-based side-channel attacks are randomisation and partitioning. In the first case, the address-to-cache-set mapping may be randomised. Randomisation alters the links between the cache areas that are accessed and the memory areas visited in the sensitive application. The mapping between memory areas in the application and the cache areas is randomised. However, this random mapping needs to be changed regularly. In the second case, the cache can be partitioned into multiple security domains, preventing attackers from inspecting and modifying the state of the cache corresponding to the domain where the secure data applications reside. These approaches induce overhead and slow down the programs by protecting all data, including that which does not require protection.

Software countermeasures, on the other hand, operate independently of the underlying hardware and thus do not rely on the mechanisms of the hardware in question. Constant-time programming, which could be a solution, forbids memory accesses based on secret data as well as conditional branches with conditions dependent on a secret. Although effective, this type of programming is prone to errors and also induces overhead.

The SCRATCHS Solution: a Fine-grained Dynamic Partitioning Mechanism via Cache Locking
SCRATCHS involves the co-design of a RISC-V processor and a compiler toolchain to ensure the security of sensitive data while maintaining optimal program execution speed. This hybrid solution aims to enable communication between software and hardware components to reduce the risk of secret data recovery only when necessary.

To put this into practice, dynamic partitioning is used, where the sensitive program can instruct the system to always keep sensitive data in the cache, a process known as locking. As long as this data is locked, it cannot be evicted from the cache, and all accesses to it are necessarily cache hits. Access to sensitive data will thus always take the same quick time, preventing the attacker from using access time measurements to decode secret data. Figure 1 illustrates a PRIME+PROBE [3] analysis after one round of AES. This shows that our locking mechanism prevents the attacker from learning information about the secret key. Through this process, the necessary data is locked in the cache until operations are completed, and the rest of the cache remains available for other applications, maintaining optimal performance.

Figure 1: For a given secret key (0x42), the hit rate for each cache set (on the Y-axis) is shown relative to the first byte of the plaintext (X-axis). In the unprotected case, discernible patterns allow information about the secret key to be recovered. In the locked case, the hit rate remains constant, making the attack ineffective. (Figure adapted from [1]).
Figure 1: For a given secret key (0x42), the hit rate for each cache set (on the Y-axis) is shown relative to the first byte of the plaintext (X-axis). In the unprotected case, discernible patterns allow information about the secret key to be recovered. In the locked case, the hit rate remains constant, making the attack ineffective. (Figure adapted from [1]).

Technically, this involves modifying the processor and the cache. Lock and unlock commands are added to the instruction set architecture, specifically the RISC-V ISA [1]. Meanwhile, mathematical calculations on the security of this solution have provided formal proof of this co-design approach [2].

The SCRATCHS project will conclude in 2025 and will give way to the follow-up action LockOS. The goal of LockOS will be to implement the developed solutions on more complex processors with different privilege levels while adding operating system support. The aim is to create a demonstration to prove that the developed protections can achieve a high level of security while maintaining strong performance.

References: 
[1] N. Gaudin et al., “A fine-grained dynamic partitioning against cache-based timing attacks via cache locking,” ISVLSI, 2024. 
[2] J.-L. Hatchikian-Houdot et al., “Formal hardware/software models for cache locking enabling Fast and Secure Code,” ESORICS, 2024.
[3] F. Liu et al, “Last-level cache side-channel attacks are practical,” SP 2015.

Please contact: 
Frédéric Besson, Inria, France
This email address is being protected from spambots. You need JavaScript enabled to view it.
 

Next issue: January 2025
Special theme:
Large-Scale Data Analytics
Call for the next issue
Image ERCIM News 139
This issue in pdf

 

Image ERCIM News 139 epub
This issue in ePub format

Get the latest issue to your desktop
RSS Feed