1. Home
  2. Countermeasure
  3. Power Masking

Power Masking

Power masking is a side-channel countermeasure in which secret-dependent values and intermediate computations are represented using multiple randomized shares. A masking scheme of order d is designed so that observations involving up to dcovered intermediate values do not reveal information about the protected secret under the scheme’s defined leakage and adversary model. Correctly implemented masking can prevent straightforward lower-order exploitation and increase the complexity or number of observations required for successful power or electromagnetic analysis. It does not guarantee protection regardless of the number of measurements: higher-order, profiled, multivariate, or implementation-specific attacks may combine leakage from multiple shares or observations and recover the protected secret. The masking scheme generates randomized shares and performs the protected computation using masking operations designed to preserve the required security order. Reconstruction or conversion to an unmasked representation must occur only at an explicitly authorized boundary and must not expose secret-dependent values through registers, memory, buses, transitions, glitches, control flow, or other observable implementation state. Power masking applies secret-sharing principles to the secret key, cryptographic state, and other secret-dependent intermediate values throughout a computation. CM0060 may describe the general share-based protection concept, while CM0061 should focus on implementing and preserving that sharing across cryptographic operations to reduce exploitable power and electromagnetic leakage. Effective masking requires correct implementation across the entire cryptographic execution path, as a single unmasked intermediate value anywhere in the computation can restore exploitable correlation and defeat the protection.

Sources

  • M.-L. Akkar and C. Giraud. An implementation of des and aes, secure against some attacks. In CHES ’01: Proceedings of the Third International Workshop on Cryptographic Hardware and Embedded Systems, pages 309–318, London, UK, 2001. Springer-Verlag.
  • J.-S. Coron and L. Goubin. On boolean and arithmetic masking against differential power analysis. In CHES ’00: Proceedings of the Second International Workshop on Cryptographic Hardware and Embedded Systems, pages 231–237, London, UK, 2000. Springer-Verlag.
  • L. Goubin. A sound method for switching between boolean and arithmetic masking. In CHES ’01: Proceedings of the Third International Workshop on Cryptographic Hardware and Embedded Systems, pages 3–15, London, UK, 2001. Springer-Verlag.
ID: CM0061
Tier: III
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should define side-channel resistance for cryptographic and security-sensitive implementations where the threat model identifies credible access to power, electromagnetic, or related physical leakage and where secret compromise would create unacceptable mission consequences. Power masking should be evaluated as one candidate protection, with requirements defining the protected operations, masking order, applicable leakage model, adversary capabilities, observation budget, implementation platform, and required assurance evidence. Requirements should specify that masking implementations be evaluated through empirical side-channel testing on production-representative hardware rather than accepted solely on design documentation, with the evaluation methodology and pass/fail criteria defined before testing begins. Contract language should require that masking scheme design documentation be submitted as a controlled security deliverable, including the masking order, the randomness source used for mask generation, the points in the execution path at which masks are applied and removed, and a demonstration that no unmasked intermediate values appear in power-observable contexts. Evaluation criteria should assess offerors' experience implementing verified masking schemes in embedded cryptographic applications, their proposed side-channel evaluation approach, and their demonstrated understanding of common masking implementation pitfalls such as compiler optimization stripping masks or unexpected register reuse exposing unmasked values. Verification must include implementation-level analysis and physical side-channel evaluation on production-representative hardware using approved software, compiler settings, operating modes, clocking, and power configurations. Testing must document the methods used, trace counts, measurement sensitivity, detected leakage, attack outcomes, coverage limitations, and residual risk. Failure to detect leakage within the evaluation must not be interpreted as proof that no exploitable leakage exists.

Pre-Operations Developer/Supplier

Masking requirements should be incorporated during cryptographic software or hardware architecture design because masking affects algorithms, intermediate representations, randomness consumption, compiler constraints, processor selection, timing, and resource budgets. An existing implementation may be converted to a masked implementation, but the resulting design must be treated as a security-sensitive reimplementation and validated across the complete execution path. The masking order must be justified against the applicable leakage and adversary model. A masking scheme of order dcommonly uses d+1 shares and is intended to resist attacks combining up to dcovered leakages under its security assumptions. Increasing the order can increase attack complexity but does not independently guarantee practical resistance; security also depends on joint leakage, physical implementation, profiling capability, noise, share refreshing, and processor behavior. Execution-time, memory, randomness, power, and code-size impacts must be measured for the selected implementation. Mask generation, share refreshing, and masked nonlinear operations must use an approved random-bit generation mechanism that provides the strength, freshness, independence, and throughput required by the selected masking scheme. Masks or random values must not repeat or exhibit relationships that violate the scheme’s security assumptions. The design must define randomness health monitoring and fail-secure behavior for loss, degradation, or exhaustion of required randomness. Implementation assurance must account for compiler transformations, instruction scheduling, register allocation, memory reuse, pipeline and bus transitions, processor flags, speculative or shared microarchitectural state, and other target-specific behavior that can create joint leakage between shares. Verification must include review of generated code and, where necessary, processor-aware formal or gate-level analysis together with empirical evaluation on the target hardware. Side-channel evaluation should be conducted at both the simulation level and through physical measurement on production hardware, as simulation cannot reliably predict all power-observable behaviors arising from hardware implementation details.