Generation and Verification of Masking Countermeasures Against Side-Channel Attacks

Project Information

AMAskZONE

Grant agreement ID: 101077506

DOI

10.3030/101077506

EC signature date 16 December 2022

Start date 1 September 2023

End date 31 August 2028

Funded under

• European Research Council (ERC)

Total cost

€ 1 495 250,00

EU contribution

€ 1 495 250,00

Coordinated by

CRYPTOEXPERTS SAS
France

Periodic Reporting for period 1 - AMAskZONE (Generation and Verification of Masking Countermeasures Against Side-Channel Attacks)

Reporting period: 2023-09-01 to 2026-02-28

Summary of the context and overall objectives of the project

Cryptography is everywhere in our daily life to ensure the confidentiality and authentication of our communications and the integrity of our records. Although there are strong expectations regarding the security of cryptographic schemes against black-box attackers whose knowledge is restricted to a few inputs or outputs, the security of their implementations is less challenged. However, once implemented on embedded devices, cryptographic schemes become vulnerable to powerful side-channel attacks. The latter additionally exploit the physical leakage (e.g. power consumption) released by the device to recover the manipulated secrets. With cheap equipment, side-channel attacks may yield tremendous damage (e.g. full key recovery) within seconds. Nevertheless, the current security level of countermeasures is not yet close to that achieved in the black-box model.

The community is divided on how to assess the security of cryptographic implementations. From practitioners’ perspective, they need to be confronted with concrete side-channel attacks directly on embedded devices. Conversely, theorists consider that such an empirical approach is not portable and does not yield concrete security levels (e.g. not all attacks can be tested). Therefore, they instead investigate security proofs based on abstract leakage models, although the latter are often too far removed from reality to yield practical security.

In this project, I plan to combine the advantages of both worlds with a toolbox to generate and verify cryptographic implementations with practical security. Namely, I aim to:
(i) design new compilers to turn any high-level algorithm into an efficient implementation proven secure for identified concrete devices,
(ii) push the limits of formal verification with device characterization and polynomial complexity for industrial use.

The main challenge of AMAskZONE is to design and verify cryptographic implementations so that they achieve measurable practical security.

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

We advanced both the design of countermeasures against side-channel attacks (where devices unintentionally leak information through timing, power, or electromagnetic signals) and the automatic checking of existing implementations.

Design. We specified a methodology that turns a cryptographic design into an implementation that meets a chosen security level on a given microcontroller. It works in two steps: (i) characterize the device (how well data and the noise can be isolated, how much noise it naturally has); (ii) construct the implementation so that the characterization implies the target security level by using an intermediate random probing compiler: a tool that turns a scheme into an implementation that is secure in a leakage model (the p-random probing model) where each intermediate variable leaks with probability p.

This motivated our main contribution: a new random probing compiler with a better trade-off between security bounds and complexity of the resulting implementations (operations and randomness). The key idea is to assemble small, verified building blocks (as implementations of small basic functions) under simple composition rules with three main constraints: the composition must be verified efficiently, blocks must exist or be designed that satisfy properties corresponding to the composition rules, and the security bounds at the end must be tight. We validated our approach on the post-quantum signature Raccoon and on AES, outperforming prior methods; the results are published and the code is open-source.

Verification. Many industrial implementations are hand-written rather than compiler-generated, so independent checking matters. We developed three new open-source tools:
- IronMaskArithmetic — verifies implementations that use arithmetic over prime fields (common in post-quantum cryptography)
- IronMask+ — checks resistance when both data leakage and faults (intentional glitches) are considered together
- perseus — a fast, probabilistic checker that scales to large designs while still providing tight, informative security estimates.

Together, these results help bridge the gap between theory and practice: they offer a concrete way to build secure implementations for real devices and to verify the security of code already in use.

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

Potential impacts.

Scientifically, the project bridges the gap between idealised leakage models and what engineers measure on devices. It delivers new composition rules, tighter analyses, and verification techniques that make side-channel security closer to real constraints. Technologically, the open-source toolchain (for exact, arithmetic, and scalable/probabilistic verification) lowers the cost and time needed to evaluate implementations for both developers and evaluators and also supports the post-quantum transition.

Further research.

The random probing compiler we designed strikes a useful balance, yet implementations remain heavy at realistic security targets. There is ample room to refine both the building blocks (leaner gadgets) and the composition rules (sharper, still efficiently checkable). At the methodology level for practical security, our current way of enforcing data isolation is too costly, and several security bounds are not tight enough. On the verification side, we still need broader coverage for mixed Boolean–arithmetic code, better efficiency (perseus is a promising step), and wider completeness: exact checkers like IronMask (and its extension) provide strong guarantees, but currently scale only to small, specific blocks.