Preventing Your Faults From Telling Your Secrets: Defenses Against Pigeonhole Attacks

New hardware primitives such as Intel SGX secure a user-level process in presence of an untrusted or compromised OS. Such “enclaved execution” systems are vulnerable to several side-channels, one of which is the page fault channel. In this paper, we show that the page fault side-channel has sufficient channel capacity to extract bits of encryption keys from commodity implementations of cryptographic routines in OpenSSL and Libgcrypt — leaking 27% on average and up to 100% of the secret bits in many case-studies. To mitigate this, we propose a software-only defense that masks page fault patterns by determinising the program’s memory access behavior. We show that such a technique can be built into a compiler, and implement it for a subset of C which is sufficient to handle the cryptographic routines we study. This defense when implemented generically can have significant overhead of up to 4000X, but with help of developer-assisted compiler optimizations, the overhead reduces to at most 29.22% in our case studies. Finally, we discuss scope for hardware-assisted defenses, and show one solution that can reduce overheads to 6.77% with support from hardware changes.

💡 Research Summary

The paper investigates a powerful side‑channel attack that exploits page‑fault information in enclave‑based execution environments such as Intel SGX. Because the untrusted operating system still controls the page tables, it can observe every page‑fault event, including the faulting virtual page address. The authors formalize this threat as a “pigeonhole attack”: the OS deliberately limits the number of physical pages allocated to the enclave so that almost every memory reference causes a page fault, thereby maximizing the observable leakage.

Through extensive experiments on widely used cryptographic libraries (OpenSSL and Libgcrypt), the authors demonstrate that the page‑fault channel can recover a substantial fraction of secret material. In the Libgcrypt AES implementation, lookup tables for the S‑Box and MixColumns are split across page boundaries. Depending on the value of a secret key byte, the routine accesses either page P1 or page P2. By correlating the observed page‑fault sequence with chosen plaintexts, the attacker can reduce the key‑space dramatically, extracting at least 25 bits of key information in a single round—far exceeding the few bits typically leaked by cache‑based attacks. A similar analysis of EdDSA shows that each bit of the secret scalar determines which code page (P1, P2, or P3) is executed, allowing the OS to reconstruct the entire scalar. These case studies prove that the page‑fault side‑channel has enough capacity to compromise cryptographic secrets that were previously considered hardened against timing and cache attacks.

To counter this, the authors introduce the notion of page‑fault obliviousness (PF‑obliviousness): an enclave program must exhibit an identical page‑fault pattern regardless of secret inputs. They propose a software‑only defense called deterministic multiplexing, implemented as a compiler transformation. The compiler rewrites the program so that it proactively accesses all data and code pages in a fixed order before performing any secret‑dependent computation. This “pre‑fetch and multiplex” approach masks the true secret‑dependent accesses, making the observable page‑fault trace independent of the secret.

A naïve implementation of deterministic multiplexing incurs massive overhead—on average 705× slowdown, with worst‑case factors up to 4000×—because it forces the program to touch every page on every execution. Recognizing that cryptographic routines have regular structure, the authors devise three optimization techniques: (1) page‑level loop unrolling to eliminate redundant accesses, (2) merging secret‑dependent control flow into a single page to reduce page switches, and (3) static analysis to skip multiplexing when it is provably unnecessary. After applying these optimizations, the average overhead drops to 29.22 % and the worst‑case overhead falls to 6.77 % for the evaluated benchmarks.

The paper also explores hardware‑assisted defenses. By masking the offset within a faulting page and by randomizing or periodically flushing page‑fault logs at the hardware level, the OS’s ability to correlate faults with secret data is further weakened. The authors estimate that such hardware changes could reduce the software‑only overhead by an additional factor of six, making the overall performance impact acceptable for real‑world deployment.

In summary, the work makes three major contributions: (1) it reveals that page‑fault side‑channels can extract significant secret information from standard cryptographic implementations, (2) it defines PF‑obliviousness and provides a practical deterministic multiplexing compiler that achieves this property, and (3) it demonstrates that, with targeted optimizations and modest hardware support, the defense can be deployed with overheads well below 30 % in typical cases. This research highlights the need to consider page‑fault leakage alongside traditional cache and timing attacks when designing secure enclave systems.