Defeating Power Analysis with Threshold Implementation

A cipher can be mathematically unbroken and still hand over its secret key in minutes — not because anyone solved the math, but because they watched the chip's power meter. Part one covered how Piccolo squeezes a block cipher into under 700 logic gates for RFID tags. This post covers the attack that a small, efficient implementation is more exposed to, not less — differential power analysis (DPA) — and the countermeasure researched in my seminar to close it: threshold implementation (TI) masking.

The chip that talks without meaning to

Every logic gate on a chip draws a slightly different amount of current depending on the bits flowing through it. A gate flipping from 0 to 1 draws differently than one staying at 0, and — critically — those tiny differences correlate with the actual data being processed, including secret key bits. Simple power analysis (SPA) is looking at that power trace by eye and picking out patterns. Differential power analysis, introduced to the cryptology community by Kocher, Jaffe, and Jun in 1998, is far more dangerous: it applies statistics across many traces of the same operation with different inputs, and can pull out a correlation between power consumption and a specific key bit even when a single trace is far too noisy to read directly.

The part that should concern anyone building lightweight crypto: DPA doesn't care how strong your cipher's math is. It doesn't attack the algorithm — it attacks the implementation, straight through the power pins, entirely bypassing whatever cryptanalytic resistance went into the cipher's design.

Why lightweight ciphers are the easier target

This is the uncomfortable follow-on from part one's whole premise. Every design choice that makes a cipher cheap to build — fewer gates, simpler S-boxes, fewer rounds — also gives an attacker less noise to hide the leakage in. A large, complex implementation has more simultaneous switching activity to blur together; a lean, 683-gate implementation has comparatively little going on, which makes each operation's power signature cleaner and easier to correlate statistically. Building for the gate budget and building for power-analysis resistance pull in genuinely opposite directions, and a design that only optimizes for the first is leaving the second wide open.

Masking: hide the value, not the math

The classical defense is masking: instead of a gate ever computing directly on the real secret value, split that value into random shares that individually look like noise, and only design the circuit so the shares recombine to the correct answer. Boolean masking, the common form, splits a bit x into shares x1, x2, ..., xn such that they XOR back to x, while no smaller subset of the shares reveals anything about x at all.

Simple masking sounds like it should be watertight, and in practice it wasn't — real-world evaluation showed naive masking schemes don't hold up as cleanly against DPA as the theory promised, especially at low mask orders. That gap is what motivated the more rigorous approach the seminar centered on.

Threshold Implementation: masking with a proof behind it

Threshold Implementation (TI) is a masking discipline built to guarantee three formal properties hold at every stage of the circuit, not just at the input and output:

• Correctness — the shares still recombine to the right answer.
• Completeness — every share genuinely depends on the underlying secret (no share is dead weight that leaks nothing but also protects nothing).
• Non-completeness (balance) — no single share, taken alone, depends on all of the input shares — so any one wire an attacker taps still can't reveal the secret by itself.

The share count isn't arbitrary: TI's theory ties it to the algebraic degree of the function being protected. A function with degree d needs at least d + 1 shares to satisfy non-completeness properly. Piccolo's S-box, once its Boolean expression is worked out, contains cubic (degree-3) terms — which is exactly why the scheme researched here is TI(3,3): three shares, three output paths.

The wrinkle: you can't mask a cubic term directly

Here's the part of the seminar that was genuinely the hardest to follow, and the most interesting: TI's clean guarantees apply to quadratic functions. Piccolo's S-box output includes terms like M1 = b ⊕ (M3 + d), which — once expanded — is a cubic Boolean expression. Splitting a cubic function directly into 3 shares doesn't cleanly satisfy the non-completeness property TI depends on.

The fix is secondary decomposition: instead of masking the cubic function in one step, factor it into a cascade of two quadratic functions, call them K and L, such that computing K and then L reproduces the original cubic S-box output. Each of K and L, being quadratic, can be masked cleanly into 3 shares on its own. The same treatment applies to the inverse S-box (InvS-box) used in decryption, which is harder still, since its Boolean form isn't handed to you — it has to be derived and then decomposed the same way.

S-box (cubic, degree 3)
   │  secondary decomposition
   ▼
K (quadratic) ──▶ L (quadratic)
   │                  │
   ▼                  ▼
share K into 3    share L into 3
   │                  │
   └──── TI(3,3) secret-shared S-box ────┘

It's a small piece of engineering judo: you don't invent a way to mask degree-3 functions safely — you refactor the function until the problem you already know how to solve applies.

What the researched protection actually bought

The paper this seminar reviewed evaluated two hardware schemes on a SASEBO-G board — a purpose-built side-channel evaluation platform (dual FPGAs, one running the target cipher, the other handling communication, with layout specifically designed to minimize measurement noise so an evaluator can trust what they're seeing on the oscilloscope). Two Piccolo implementations were compared:

• Scheme 1 — a plain serialized implementation, no DPA protection: 2155 GE.
• Scheme 2 — the TI(3,3)-masked version: roughly 2000 GE.

The area cost of adding the masking was minimal — TI(3,3) actually landed at a slightly smaller footprint in this evaluation, since serialization elsewhere in the design offset the extra sharing logic. The security payoff was dramatic: breaking Scheme 1 took roughly 200 power traces; breaking the TI-protected Scheme 2 took more than 50,000 — a difference of over two orders of magnitude, for essentially no added silicon cost. That ratio is the entire argument for why TI matters in resource-constrained crypto: real DPA resistance doesn't have to compete with the gate budget that got you a lightweight cipher in the first place.

Why this matters beyond one seminar

The broader lesson generalizes past Piccolo: "the cipher is secure" and "the chip is secure" are different claims, and conflating them is a common, expensive mistake. Anyone shipping cryptography on physical hardware — a payment card, an access badge, an IoT sensor node like the ones in my Accident Aid or LoRaWAN parking projects — is implicitly making claims about both the math and the implementation. Side-channel resistance is exactly why standards bodies certify hardware security modules separately from the algorithms they run, and why "we used AES" is never, on its own, a complete security story for embedded hardware.

Common pitfalls

1. Trusting a mathematically strong cipher to be side-channel safe by default. They're independent properties; a proof of resistance to differential cryptanalysis says nothing about power-trace correlation.
2. Naive masking without formal properties. Splitting a value into shares isn't automatically secure — TI's completeness and non-completeness requirements exist precisely because ad hoc masking has been broken in practice.
3. Masking a cubic function as if it were quadratic. The whole reason secondary decomposition exists is that TI's clean guarantees don't extend past quadratic degree without it.
4. Assuming protection is expensive. The evaluated TI(3,3) scheme cost essentially nothing in gate count here — the "security tax" assumption is often wrong once the sharing is designed properly.
5. Skipping formal side-channel evaluation. A protected design that hasn't been measured on real hardware, on a platform built for this kind of measurement, is a hypothesis, not a result.

FAQ

Interested in embedded security, side-channel resistance, or a full-stack build in Dubai, UAE? Get in touch.