Share-slicing: Friend or Foe?

Abstract

Masking is a well loved and widely deployed countermeasure against side channel attacks, in particular in software. Under certain assumptions (w.r.t. independence and noise level), masking provably prevents attacks up to a certain security order and leads to a predictable increase in the number of required leakages for successful attacks beyond this order. The noise level in typical processors where software masking is used may not be very high, thus low masking orders are not sufficient for real world security. Higher order masking however comes at a great cost, and therefore a number techniques have been published over the years that make such implementations more efficient via parallelisation in the form of bit or share slicing. We take two highly regarded schemes (ISW and Barthe et al.), and some corresponding open source implementations that make use of share slicing, and discuss their true security on an ARM Cortex-M0 and an ARM Cortex-M3 processor (both from the LPC series). We show that micro-architectural features of the M0 and M3 undermine the independence assumptions made in masking proofs and thus their theoretical guarantees do not translate into practice (even worse it seems unpredictable at which order leaks can be expected). Our results demonstrate how difficult it is to link theoretical security proofs to practical real-world security guarantees.

Breaking Masked Implementations with Many Shares on 32-bit Software Platforms

“…Second, the parallel nature of the sharesliced implementations makes their evaluation significantly easier in terms of statistical modeling, since removing the need to characterize multivariate distributions as in the bitslice case. Finally, shareslicing has been shown to be a more risky solution (than bitslicing) in terms of security order reductions due to glitches when implemented in an ARM Cortex device [GMPO20]. So while not precluding the possibility that sharesliced implementations can lead to secure and efficient designs in other contexts, bitslicing seems to be a more conservative approach for the devices that we investigate in the current state-of-the-art.…”

“…Then, the same bitwise operation on native words can again be applied. For a masked implementation, a similar approach can be taken by additionally ensuring that each share of a given encoding is placed in a different slice (in order to avoid the shareslicing glitch issue observed in [GMPO20]). Additionally, the bitwise operations are replaced by masked gadgets from such as the ones of Appendix A.…”

Custom Instruction Support for Modular Defense Against Side-Channel and Fault Attacks

“…For non-bitsliced designs, accidental unmasking has been demonstrated when a mask m overwrites a masked variable m ⊕ v [1,36] For bitsliced designs, the risk is lower because each share resides at a different bit-index. Still, bitslices may interfere with each other in unexpected manners [19]. In SKIVA, the SUBROT instruction shifts shares over bit-positions using a dedicated data-path.…”

Rosita: Towards Automatic Elimination of Power-Analysis Leakage in Ciphers

“…However, as mentioned above, algorithms that use high-order masking are significantly more complex in terms of resources they require, than simple firstorder masking. Moreover, Gao et al [42] demonstrate that glitches may further reduce the security level of masked implementations.…”