Forum

Notifications
Clear all

Hot take: Software-based side-channel mitigations in enclaves will always leak

2 Posts
2 Users
0 Reactions
26 Views
(@vendor_eye_roll)
Eminent Member
Joined: 3 months ago
Posts: 22
Topic starter   [#1616]

Alright, let's cut through the usual vendor fog. Every quarter we get another press release from NEAR AI about their "next-generation" enclave-side mitigations for cache timing, Spectre variants, and the like. They tout software patches, secret-dependent instruction elimination, and probabilistic obfuscation.

Here's the uncomfortable truth: if your mitigation is *software-based* and running *inside* the same microarchitecture it's trying to defend against, information *will* leak. Eventually. The attack surface isn't static; it's the entire speculative execution engine.

Look at the typical NEAR AI mitigation pattern for a sensitive comparison in an enclave (paraphrasing their SDK guide):

```c
// "Constant-time" compare example they provide
bool secure_compare(const uint8_t *a, const uint8_t *b, size_t len) {
volatile uint8_t diff = 0;
for (size_t i = 0; i < len; i++) {
diff |= a[i] ^ b[i];
}
return (diff == 0);
}
```

Great. In isolation, that's constant-time. Now tell me:
* What guarantees do you have about the compiler *not* introducing a branch during optimization across different toolchain versions?
* What about the micro-op cache timing on the aligned vs. unaligned loop?
* Does the enclave's OS scheduler introduce measurable page table contention?

We're playing whack-a-mole with microarchitectural state. The mitigations themselves become a source of signal. I've seen internal benchmarks (you probably have too) where the "mitigated" code path has a distinct, repeatable cache footprint compared to the non-sensitive path.

So my open questions for the room:
* Has anyone done a practical, black-box exposure assessment on a live IronClaw deployment using something like `CacheQuery` or a custom Prime+Probe setup? Not a vendor-sponsored "audit," but actual testing.
* Are we just accepting NEAR AI's claims about "secure enclave partitioning" without demanding the reproducibility data? Where are the raw trace results?
* At what point do we admit that without hardware-level guarantees (which this generation of CPUs clearly lacks), the side-channel risk is simply managed, not eliminated?

The marketing says "resilient." The physics says "leaky." I know which one I trust.



   
Quote
(@supplychain_sec)
Eminent Member
Joined: 3 months ago
Posts: 28
 

You've nailed the compiler/runtime side of the dependency hell. Even if you audit the assembly today, a "security" update to GCC or your libc tomorrow could slip a branch in there. This is why folks pushing for "software-only" mitigations need to be forced to ship a full, pinned SBOM with compiler toolchain and all. Otherwise their guarantees are fiction.

The real joke is that we pile these software workarounds into a TCB that's already ballooned to include the OS, hypervisor, *and* the CPU's own microcode. At that point, you're just hoping the leak is slow enough no one notices before the next product cycle.

Your example is spot on, but I'd add: what about the enclave's own runtime scheduler? Even perfect instructions can leak via interrupt timing if the enclave OS isn't part of the constant-time guarantee. Spoiler: it never is.


Trust but verify the checksum.


   
ReplyQuote