When I was finishing my Ph.D. at NYU Tandon, one of the most clarifying moments in my research came not from a successful attack but from a failed one. I was attempting a power analysis attack on a ring oscillator circuit — trying to recover a secret key through careful measurement of power consumption fluctuations. The attack didn't work the first time, or the second, or the tenth. But each failure taught me something precise about the attack surface: where the signal-to-noise ratio broke down, how environmental factors shifted the measurements, and eventually, what it took to make the technique work reliably. My earlier work on ring oscillator based design-for-trust techniques for hardware trojan detection was actually born from the same impulse — understanding what power and timing signatures can reveal about silicon that's supposed to keep secrets.

That experience shaped how I think about security in general, and it shapes how I think about AI hardware security specifically right now.

Differential power analysis (DPA) on neural networks is a topic that deserves more attention than it's getting. The technique is well-established in the hardware security community — it dates to the late 1990s when Paul Kocher's team applied it to cryptographic implementations — but its application to neural network accelerators is relatively recent, and the AI community has been slow to internalize the implications.

What DPA Actually Is (And Why It Matters for Neural Networks)

Differential power analysis is not simply "measuring power consumption." It's a statistical technique that correlates power measurements with hypothesized intermediate values in a computation. The core insight is that the power consumed by a CMOS circuit varies depending on the data it's processing — not just in aggregate, but in ways that are correlate-able with individual bit values.

For a cryptographic implementation, this means you can recover a secret key by measuring power traces during encryption operations and looking for statistical correlations between bit hypotheses and actual power consumption. The attack is called "differential" because it uses the difference between groups of traces to cancel out noise and reveal the signal.

For a neural network, the analogous target is the weight values stored in memory or processed in the compute units. A neural network's inference computation involves multiplying accumulated values by weight parameters stored in memory — and each of those memory reads and multiply-accumulate operations draws power in patterns that correlate with the underlying data.

Here's the critical difference from cryptographic DPA: the "key" in a neural network isn't a single secret — it's a large matrix of learned parameters. And unlike an encryption key that an attacker might not even know exists, the weights of a deployed model are often known to be the valuable asset. If you're running inference on a competitor's proprietary model on a shared hardware accelerator, there's a real question about whether your power consumption patterns during their inference could leak their model weights.

The Attack Anatomy

A practical DPA attack on a neural network accelerator proceeds through several stages:

Trace collection. You instrument the power supply of the target device — typically using a shunt resistor in series with the power line and a high-bandwidth oscilloscope, or a near-field EM probe positioned near the chip. For deep learning accelerators, this is often easier than for crypto hardware because the power signature is larger and more consistent. You collect thousands of power traces during inference operations.

Signal alignment. Power traces need to be aligned both temporally and in amplitude. Clock synchronization issues can cause small shifts in when operations occur relative to your sampling window. Methods like dynamic time warping or hardware clock extraction can help, but on AI accelerators, the consistent computation cycle makes this somewhat easier than on more variable crypto operations.

Hypothesis formation. Here's where it gets interesting. You need to form hypotheses about what intermediate values in the computation might be, and which bits of those values would correlate with power consumption. For a typical matrix multiplication, you might hypothesize about the partial sums, the activation function inputs, or the memory addresses being accessed.

Correlation analysis. You compute the correlation coefficient between your power measurements and each of your hypotheses across all traces. This produces correlation traces that reveal which hypothesis best explains the observed power consumption — and therefore, which bit value was most likely present in the actual hardware.

The statistical power of DPA comes from combining many traces. A single trace might have too much noise to reveal anything. But with 10,000 traces, even small biases in power consumption become statistically significant.

Why AI Accelerators Are Particularly Vulnerable

There's a structural reason why neural network inference on AI accelerators is more vulnerable to DPA than general-purpose computation: regularity.

General-purpose CPUs and microcontrollers perform a wide variety of operations with variable timing and data-dependent power signatures. A cryptographic implementation running on a general-purpose CPU might execute hundreds of different instructions per clock cycle, making it challenging to isolate the cryptographic operation in a power trace.

AI accelerators, by contrast, are designed for highly regular, predictable computation. A typical deep learning accelerator — whether it's a custom ASIC, a GPU tensor core, or an FPGA-based inference engine — performs matrix multiplications with highly structured data flow. The weights are stored in on-chip SRAM or accessed from external DRAM in predictable patterns. The compute units execute the same operations in the same sequence for each inference pass.

This regularity is what makes AI accelerators efficient. But it's also what makes them vulnerable: if you know the structure of the computation, you can form precise hypotheses about what the intermediate values should be, and you can correlate those hypotheses with power measurements at specific points in the computation cycle.

The other vulnerability factor is the value of what you're attacking. Cryptographic keys are valuable targets because they protect everything else. Model weights are valuable targets because they are the product — the result of months of compute and data investment, representing both financial and competitive value. Stealing a model's weights isn't just a security breach; it's IP theft in the most direct sense.

The Shared Hardware Problem

The most concerning attack scenario isn't stealing weights from your own deployed model — it's stealing weights from a model running on shared or cloud hardware. If you're running inference on a proprietary model using a cloud provider's AI accelerator, and an attacker shares that hardware — even through a virtual partition — there's a theoretical path for power side-channel attacks.

The practical barriers are significant: the attacker needs physical proximity to the hardware, expensive measurement equipment, and the ability to run enough inference operations to collect sufficient traces. But these barriers are not insurmountable, especially for nation-state actors targeting proprietary models of significant strategic value.

The FPGA and ASIC accelerator market is also fragmented, with many custom implementations that haven't been through formal security evaluation. An AI startup deploying a proprietary inference chip might not have considered DPA as a threat model. The techniques are documented in academic literature, the equipment is commercially available, and the attack surface is real.

Defenses: What Actually Works

I've spent years evaluating hardware security defenses, and I can tell you that most of the obvious countermeasures fail against a well-resourced DPA attack. Let me walk through what works and what doesn't.

Masking and randomization is the most effective approach for cryptographic hardware, and the same applies to neural networks. The idea is to randomize the data representation during computation so that power consumption becomes independent of actual data values. For neural networks, this is challenging because the randomization needs to not degrade inference accuracy — you're essentially trying to compute the same result while hiding intermediate values from an observer.

Obfuscation of memory access patterns can help by making it harder for an attacker to predict which weights are being accessed and when. Techniques like shuffling the order of weight loading or adding dummy operations can raise the noise floor of the power traces.

Power supply filtering and decoupling is often proposed but is largely ineffective against DPA. The fundamental issue is that the circuit activity itself creates the information leakage; filtering the power supply just changes the measurement point, not the signal.

Trusted execution environments (TEE) like ARM TrustZone or Intel TDX can help protect model weights from software attacks, but they don't prevent physical power side channels. If the attacker can measure power consumption during the execution of a TEE-protected computation, the physical leakage is independent of the software protection.

The honest assessment is that preventing DPA on neural network accelerators requires hardware designed with DPA resistance as a first-class requirement — not a bolt-on security feature. This means careful attention to power consumption characteristics in the chip design, appropriate masking at the circuit level, and formal evaluation against side-channel analysis techniques.

Practical Recommendations

For teams deploying AI accelerators in sensitive contexts:

First, assume that any inference operation on shared or third-party hardware is potentially observable by a physical attacker with sufficient equipment and motivation. This doesn't mean you shouldn't use cloud infrastructure — it means you should be thoughtful about which models you run where, and be aware of the threat model.

Second, for high-value models, consider whether the computational structure can be modified to reduce side-channel leakage. This might mean using quantization schemes that reduce the precision of intermediate values, or adding dummy operations that increase trace noise.

Third, if you're designing custom AI accelerator hardware, engage hardware security experts early in the design process. DPA resistance is something that needs to be designed in, not tested for afterward. The cost of adding masking and other countermeasures is much lower during chip design than after fabrication.

Fourth, monitor the research literature on this topic. The techniques are advancing rapidly, and what seems impractical today may become feasible as measurement equipment improves and AI accelerator architectures evolve.

The Hard Truth

The AI industry has made enormous progress on model security in the software domain — access control, encryption at rest, secure enclaves for training. But the physical layer has received far less attention, and the stakes are arguably higher. A software vulnerability can be patched. A model whose weights have been extracted is compromised permanently.

From my years in hardware security, I've learned that the most dangerous vulnerabilities are the ones that exist in plain sight in well-understood attack classes that the community has simply chosen not to prioritize. DPA on neural networks fits that description exactly. The technique is documented, the equipment is available, and the target — proprietary model weights — is among the most valuable assets in the AI ecosystem.

The hardware security community knows how to solve this problem. The question is whether the AI industry will engage with hardware security expertise before these attacks become practical enough to matter at scale.