Abstract

Implementing the masking countermeasure in hardware is a delicate task. Various solutions have been proposed for this purpose over the last years: we focus on Threshold Implementations (TIs), Domain-Oriented Masking (DOM), the Unified Masking Approach (UMA) and Generic Low Latency Masking (GLM). The latter generally come with innovative ideas to cope with physical defaults such as glitches. Yet, and in contrast to the situation in software-oriented masking, these schemes have not been formally proven at arbitrary security orders and their composability properties were left unclear. So far, only a 2-cycle implementation of the seminal masking scheme by Ishai, Sahai and Wagner has been shown secure and composable in the robust probing model – a variation of the probing model aimed to capture physical defaults such as glitches – for any number of shares.In this paper, we argue that this lack of proofs for TIs, DOM, UMA and GLM makes the interpretation of their security guarantees difficult as the number of shares increases. For this purpose, we first put forward that the higher-order variants of all these schemes are affected by (local or composability) security flaws in the (robust) probing model, due to insufficient refreshing. We then show that composability and robustness against glitches cannot be analyzed independently. We finally detail how these abstract flaws translate into concrete (experimental) attacks, and discuss the additional constraints robust probing security implies on the need of registers. Despite not systematically leading to improved complexities at low security orders, e.g., with respect to the required number of measurements for a successful attack, we argue that these weaknesses provide a case for the need of security proofs in the robust probing model (or a similar abstraction) at higher security orders.

Highlights

  • Masking is one of the most popular countermeasures against sidechannel attacks [CJRR99]

  • Our main claim is that this collection of examples illustrates the difficulty to interpret the higher-order security guarantees provided by Consolidated Masking Scheme (CMS), Domain-Oriented Masking (DOM), Unified Masking Approach (UMA) and Generic Low Latency Masking (GLM), and that, without the appropriate tweaks, these schemes cannot be extended beyond the contexts in which they were exhaustively analyzed

  • It may very well be that using Strong Non-Interference (SNI) gadgets in this context is an overkill and that the biases caused by the lack of composability remain hard to exploit given the noise levels considered in concrete implementations until quite large security orders, or even that additional refreshings are not needed for this particular circuit

Read more

Summary

Introduction

Masking (aka secret sharing) is one of the most popular countermeasures against sidechannel attacks [CJRR99]. We note that these flaws do not invalidate the innovative ideas in these schemes: they only show that when moving to higher security orders, the engineering intuition that led to the successful design of gadgets secure at low orders benefits from a more formal analysis In this regard, our main claim is that this collection of examples illustrates the difficulty to interpret the (lack of) higher-order security guarantees provided by CMS, DOM, UMA and GLM, and that, without the appropriate tweaks, these schemes cannot be extended beyond the contexts in which they were exhaustively analyzed. Our main claim is that this collection of examples illustrates the difficulty to interpret the (lack of) higher-order security guarantees provided by CMS, DOM, UMA and GLM, and that, without the appropriate tweaks, these schemes cannot be extended beyond the contexts in which they were exhaustively analyzed The latter leads to an error-prone situation for engineers willing to implement higher-order (glitch-resistant) masking in hardware. We use our experiments to discuss the additional constraints that the robust probing security abstraction implies on the placement of registers within masked hardware implementations

Background
Multiplication with Independent Inputs
A Third-Order Flaw
Discussion
Multiplication with Dependent Inputs
A Systematic Composability Flaw
Low-Latency Masking and Compression
Combining Previous Attacks
Exploiting the Flaws
Composability in Hardware - A Matter of Registers
Pipelining Registers
Further remarks and conclusions
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call