That's a really good point about the local attacker with root. I was just reading about how some TEEs handle key generation, and I never stopped to think that the power signature could be the weak spot.

If someone has physical access for a probe, aren't there also other physical attacks they could try, like voltage glitching? Or is power analysis considered a much lower barrier to entry?

Spot on. The "local attacker with root" assumption is the trap door. Once you've conceded that, arguing a $500 oscilloscope is a bridge too far is just theater. They've already modeled the attacker sitting at the console with kernel privileges, but suddenly balk at the idea they could plug something into the board.

Memory encryption is a fantastic magic trick for the sales deck. It makes the diagram look clean. Meanwhile, the actual computation on that encrypted data still draws a lovely, detailed power trace of your private key. It's security through pretty architecture diagrams.

The real answer, cynical as it is, is cost and chaos. Hardening against DPA means constant-timing libraries, blinding, dedicated hardware logic. That's a per-silicon-revision nightmare. It's easier to shove it into the "physical attacks" bucket and hope your customers never read the fine print.

You're right that it's a marketing convenience, but I think the 'local attacker with root' model is also a conceptual stopgap. Once you allow physical probes, the threat model doesn't just expand to power analysis, it potentially collapses entirely. You have to consider bus probing, EM emanation, and fault injection. A vendor that acknowledges power analysis opens the door to a question they can't answer: "So what *do* you protect against, physically?" It's easier to draw the line at the socket boundary and call it a day.

That said, your point about signing operations is the critical one. If a TEE's main job is to hold a signing key, and the actual computation of that signature is vulnerable to DPA, then the entire enclave abstraction is a facade for that specific use. The memory encryption becomes set dressing.

I wonder if we'll see a split in TEE categories, where 'software enclaves' ignore physical channels and 'hardware security modules' try to address them, with nothing truly covering the middle ground.

Good point about the marketing. It simplifies the story.

I've seen SOC 2 controls that hinge on TEE attestation for key protection. If DPA is out of scope, that's a major blind spot for any compliance that assumes the key can't be extracted.

Is there a vendor that at least documents the lack of DPA protection in their threat model, or do they all just omit it?

You're right that the leap from root to physical probe isn't as large as vendors pretend. I've reviewed attestation reports where the "physical attack" section just says "assumed infeasible" without justification.

The cost angle is key. Constant-time, blinded scalar multiplication for ECDSA is table stakes for an HSM, but in a general-purpose TEE, that library becomes a shared resource. If one tenant's enclave uses a vulnerable bigint library, it could leak another tenant's key through shared microarchitectural state, even without a direct probe. So the risk isn't just the dedicated attacker; it's contamination across workloads.

They could at least document that keys used for signing require specific, vetted libraries to meet a DPA-resistance claim. Omission is the problem.