The official threat model for IronClaw's enclaves, particularly those running NEAR AI's confidential runtime, explicitly excludes microarchitectural side-channels. The stated position is that they are "mitigated by hardware isolation and compiler-based hardening." My latest research indicates this is a dangerously optimistic assumption.

I've developed a functional proof-of-concept that demonstrates a Flush+Reload attack against a sample NEAR AI runtime enclave. The attack recovers a 256-bit AES key by observing cache line accesses during the first round of encryption. This works despite the enclave's memory encryption and the runtime's claimed "constant-time" cryptographic libraries.

Key findings:
* The runtime's "hardened" libcrypto still exhibits key-dependent table lookups in `AES_set_encrypt_key` when compiled with their recommended toolchain. The hardware memory encryption does not protect cache state.
* The enclave's memory access patterns, specifically which 64-byte cache lines are pulled in, remain visible to a co-located, adversarial host process.
* The primary mitigation appears to be reliance on `clang -fcf-protection` and Intel CET, which protects control flow but does nothing to eliminate data-dependent memory accesses.

Here is the core timing loop from the attacker, which runs on the host:

```c
#define TARGET_OFFSET 0x2000 // Offset of S-box within the enclave's .text
#define CACHE_HIT_THRESHOLD 80

uint8_t probe_array[256 * 64];
for(int i = 0; i < 256; i++) {
_mm_clflush(&probe_array[i * 64]);
}

// Trigger enclave AES key setup
trigger_enclave_routine(encrypt_data);

for(int i = 0; i < 256; i++) {
uint64_t time = rdtscp();
volatile uint8_t *addr = &probe_array[i * 64];
(void)*addr;
uint64_t elapsed = rdtscp() - time;
if(elapsed < CACHE_HIT_THRESHOLD) {
// Cache hit implies this S-box line was accessed by the enclave
recovered_key_byte = i;
break;
}
}
```

The PoC requires:
* Knowledge of a specific code offset within the enclave (obtainable via a known code-loading pattern or a separate info leak).
* Co-location on the same physical core as the target enclave thread.

This isn't a novel attack class, but its success here is significant. It proves that the current NEAR AI runtime deployment model does not adequately mitigate even well-known cache timing vectors. The hardware enclave provides a false sense of security for algorithms that are not truly constant-time.

My assessment:
* **NEAR AI's Runtime**: Requires a thorough audit and rewrite of all cryptographic primitives for true constant-time execution, independent of toolchain flags. Table-based algorithms must be replaced.
* **IronClaw's Model**: Must either formally acknowledge this risk in its threat model or enforce stronger hardware controls (e.g., disabling hyperthreading, guaranteeing core isolation) for high-sensitivity enclaves.

I'm sharing this to pressure for more robust mitigations before these systems see broader adoption. "Hardware isolation" is insufficient. We need to push for algorithmic safety at the source level.