AEX-NStep: Probabilistic Interrupt Counting Attacks on Intel SGX

TL;DR

AEX-Notify was designed to prevent deterministic single-stepping in SGX enclaves, but this work shows that probabilistic interrupt counting remains viable. The authors introduce AEX-NStep and two attack primitives, PSS and LBMS, which exploit SMT co-location, performance counters, and IPI-based timing to infer enclave progress even with AEX-Notify. They demonstrate practical attacks that leak an ECDSA private key and replicate memcmp-based leakage, underscoring limitations in the mitigation and prompting new defensive directions. The results highlight the need for architectural mitigations that address microarchitectural leakage and interrupt timing directly, beyond obfuscating forward progress or reducing the execution window.

Abstract

To mitigate interrupt-based stepping attacks (notably using SGX-Step), Intel introduced AEX-Notify, an ISA extension to Intel SGX that aims to prevent deterministic single-stepping. In this work, we introduce AEX-NStep, the first interrupt counting attack on AEX-Notify-enabled Enclaves. We show that deterministic single-stepping is not required for interrupt counting attacks to be practical and that, therefore, AEX-Notify does not entirely prevent such attacks. We specifically show that one of AEX-Notify's security guarantees, obfuscated forward progress, does not hold, and we introduce two new probabilistic interrupt counting attacks. We use these attacks to construct a practical ECDSA key leakage attack on an AEX-Notify-enabled SGX enclave. Our results extend the original security analysis of AEX-Notify and inform the design of future mitigations.

Figures (14)

• Figure 1: Simplified control flow of the AEX-Notify mitigation stage II, which ensures that PTE attributes will not cause any faults (hence preventing zero-stepping) and that EARP will execute as fast as possible by priming its code ($c_p$), data ($d_p$), and stack ($s_p$) pages. If a random bit $r$ (passed implicitly as part of $c_p$ )is set to 1, additional random cycles are executed. Any interrupts during the atomic part will cause a roll-back of the previous $s_p$, $d_p$, and $s_p$ parameters, effectively restarting the mitigation.
• Figure 2: Comparison of our attack primitives to SGX-Step and AEX-Notify. The attacker resumes the enclave with ERESUME after finishing with the necessary preparations (Prep.). (a) SGX-Step: The attacker extends the execution time of the first enclave instruction, arms a timer-based interrupt, and filters out zero-steps by examining PTE attributes. AEX-Notify introduces a mitigation phase (Mitig.), which ensures that instructions are pre-fetched, reducing their execution time and preventing enclave progress from being determined through page table entries (PTEs). (b) We extend the execution time of enclave instructions by disabling caches and use IPIs to reduce the variability of interrupt arrivals. For PSS, we align the arrival distribution such that interrupts land in the mitigation or at the first enclave instructions. Interrupts hitting the mitigation are filtered out by breaking obfuscated forward progress. For LBMS, we align the interrupt arrival redistribution such that interrupts trigger after at least $n$ instructions.
• Figure 3: Conceptual overview of probabilistic single-stepping. The attacker wants to determine which branch is taken in Listing \ref{['list:secret_pss']}. The vulnerable branch is delimited by accesses to another page (f()), which allows the attacker to locate the vulnerable code section with the help of page faults. Enclave resumption after an AEX will lead to the execution of the AEX-Notify mitigation (Mitig.). When an AEX is encountered, the attacker resumes the enclave and fires an IPI from a concurrent thread, which is calibrated such that the right tail of the interrupt's arrival distribution overlaps with the first instructions executed after the AEX-Notify mitigation. The attacker counts the interrupts observed in the vulnerable code section for each bit of the secret. On average, non-zero secret bits entail more interrupts, as the corresponding branch executes more instructions.
• Figure 4: Secret-dependent branch with a static secret. Attackers can use cross-page memory accesses to isolate the vulnerable branch, represented here by function calls residing on different pages.
• Figure 5: Secret-dependent branch with an ephemeral secret. The branch executes different numbers of instructions depending on the most significant bits of a nonce $k$. If the nonce is biased (i.e, its most significant bits are 0xFFFF), more instructions will be executed between the two page fault triggers than in the non-biased case.