Higher-Order Attacks Aren't Always Stronger: Test HO-ASPA

Evaluating a masked cryptographic implementation often begins with the assumption that increasing the attack order to match the masking order will yield better results. However, recent work on Higher-Order Adjusted Spearman Coefficient Analysis (HO-ASPA) challenges this notion. Unlike Higher-Order Correlation Power Analysis (HO-CPA), where higher orders often outperform the lowest feasible order, HO-ASPA shows no significant performance gap between higher-order and lower-order attacks. This matters for your evaluation budget.

This guide demonstrates how to incorporate rank-based analysis into a side-channel evaluation of a masked implementation, such as the DEK-handling code in an HSM-adjacent library or a PIN-block routine in a payment terminal.

1. The Problem and Why It Matters

Boolean Masking (BM) and Inner Product Masking (IPM) split sensitive intermediates into shares so no single leakage point reveals the secret. Evaluators typically combine share leakages with higher-order attacks. If you plan every test around the highest feasible order, you may waste trace-acquisition and compute time on the assumption it pays off.

Rank-based attacks change the approach in two ways:

• HO-ASPA remains effective against monotonic nonlinear leakage, which real devices produce, rather than the idealized linear model.
• Under the Hamming weight (HW) leakage model, HO-ASPA aligns with existing results and counteracts security order amplification. It significantly outperforms Kruskal-Wallis Analysis (KWA)-based attacks at various order combinations.

If your current toolchain relies on KWA or only on HO-CPA, you may be under-testing or overspending.

2. What You Need Before Starting

• Trace set. Power or EM traces from the target, with known plaintexts or ciphertexts. Non-profiling attacks don't need a clone device, which suits evaluations of certified modules where you can't build a profiling setup.
• Target scope. The masked operation under test, the masking scheme (two-share BM or IPM), and the claimed masking order.
• Leakage hypotheses. At least two models: HW and Least-Significant-Bit (LSB). The optimal attack forms differ by model, so run both.
• Tooling. Python with NumPy and SciPy (scipy.stats.rankdata handles the rank transform). Use existing SCA frameworks for acquisition and alignment, such as ChipWhisperer or your lab's equivalent.
• Baselines. A working HO-CPA implementation and, if available, a KWA-based attack for comparison.
• Governance. Evaluation scope, reporting format, and a way to feed findings back into your assessment of FIPS 140-3 module claims or vendor attestations.

3. Step-by-Step Implementation

Step 1: Preprocess Traces. Align traces, remove outliers, and confirm sampling captures the leakage windows of each share. Rank methods tolerate some nonlinearity, but they don't fix misalignment.

Step 2: Locate Share Leakage Points. For two-share masking, identify the time samples where each share is manipulated. Use a first-order test on the unmasked intermediate to confirm your windows are correct.

Step 3: Apply the Rank Transform. Convert the trace values at each selected sample to ranks per sample point across all traces:

from scipy.stats import rankdata
ranked = np.apply_along_axis(rankdata, 0, traces[:, window])

Step 4: Combine Share Leakages. Use the centered-product combination: center each ranked share leakage, then multiply across share points. For order combinations beyond the lowest, center each share's leakage raised to its chosen order. The optimal HO-ASPA form preserves this centered-product structure.

Step 5: Correlate Against Hypotheses. For each key guess, compute the hypothetical leakage under the HW model, then under the LSB model. Correlate the combined ranked leakage with the rank of the hypothesis, as in Spearman analysis, applying the adjustment that defines HO-ASPA. Retain the optimal form for your masking scheme; the BM and IPM forms are not interchangeable.

Step 6: Sweep Order Combinations. Run the lowest feasible order and at least one higher combination. This tests the central finding. Record the number of traces needed for key recovery at each combination.

Step 7: Run the Baselines. Repeat with HO-CPA and, if you have it, a KWA-based attack on identical trace sets and windows. Keep everything else constant for a fair comparison.

Step 8: Repeat for IPM Targets. If the implementation uses IPM, apply the IPM-specific optimal form. Don't reuse BM parameters.

4. Validation: How to Verify It Works

• Positive Control. Run the attack against a deliberately weakened build, such as masking disabled or a known-broken mask refresh. If HO-ASPA can't recover the key there, your pipeline has a defect.
• Cross-Model Check. Under HW, results should align with published expectations for rank-based attacks. A large discrepancy points to window selection or preprocessing errors.
• Comparative Reporting. Plot success rate against trace count for each method and order combination. The expected pattern: HO-CPA improves noticeably at higher orders under LSB; HO-ASPA shows no significant gap between orders; HO-ASPA beats KWA-based attacks at various order combinations.
• Simulated Before Real. Validate on simulated leakage with a known signal-to-noise ratio first, then on captured traces, so you can separate algorithm errors from acquisition noise.
• Reproducibility. Fix random seeds, log trace counts and parameters, and have a second engineer rerun the analysis.

5. Maintenance and Ongoing Tasks

• Re-test on Every Firmware or Masking Change. A refreshed mask generator or a compiler update can shift leakage timing.
• Keep the Order Sweep in Your Standard Test Plan. Since HO-ASPA's lower orders perform comparably to higher ones, you can often start at the lowest feasible order and escalate only if results warrant it. Document that decision so reviewers see it was deliberate.
• Track Leakage Model Assumptions. HW and LSB are two models, not the whole space. Revisit them when hardware changes.
• Retain Evidence. Store trace sets, scripts, and results alongside your assessment records so you can support findings during vendor reviews and audits of Data Encryption Key (DEK) protection, including any Key Encryption Key (KEK) hierarchies the masked code touches.
• Review the Literature Periodically. Rank-based analysis is still maturing; revisit your attack suite as new variants appear.

The practical takeaway: stop treating attack order as a free upgrade. Measure it, and let the data decide where your evaluation hours go.