Aurora: Providing Trusted System Services for Enclaves On an Untrusted System

Intel SGX provisions shielded executions for security-sensitive computation, but lacks support for trusted system services (TSS), such as clock, network and filesystem. This makes \textit{enclaves} vulnerable to Iago attacks~\cite{DBLP:conf/asplos/CheckowayS13} in the face of a powerful malicious system. To mitigate this problem, we present Aurora, a novel architecture that provides TSSes via a secure channel between enclaves and devices on top of an untrusted system, and implement two types of TSSes, i.e. clock and end-to-end network. We evaluate our solution by porting SQLite and OpenSSL into Aurora, experimental results show that SQLite benefits from a \textit{microsecond} accuracy trusted clock and OpenSSL gains end-to-end secure network with about 1ms overhead.

💡 Research Summary

The paper addresses a fundamental limitation of Intel SGX‑based trusted execution environments: while SGX protects an enclave’s memory, it provides no direct, trustworthy access to essential system services such as a reliable clock, networking, or file I/O. Consequently, enclaves must exit to untrusted operating‑system code for these services, exposing them to Iago‑style attacks where a malicious OS can snoop, replay, or forge system‑call results. To close this gap, the authors propose Aurora, a novel architecture that combines SGX with the x86 System Management Mode (SMM) to deliver trusted system services (TSS) to enclaves even when the underlying OS is fully compromised.

Aurora’s design hinges on three components: (1) an SMM Supervisor (SSV) residing in System Management RAM (SMRAM), loaded by a trusted BIOS at boot time; (2) a lightweight TSS library inside the enclave that exposes POSIX‑style APIs (e.g., gettimeofday, BSD sockets); and (3) a secure channel that links the enclave and SSV using shared memory FIFO buffers protected by symmetric‑key encryption. When an enclave needs a service, it encrypts a request in EPC memory, copies it to the shared buffer, and triggers an SMI. The CPU switches to SMM, the SSV reads the encrypted request, decrypts it, invokes the appropriate driver (clock or NIC), constructs a response, encrypts it, and returns to normal mode. The enclave then decrypts the response and proceeds.

Security is enforced at several layers. First, remote attestation guarantees that only a legitimately signed enclave can establish a session; the SSV’s identity is protected by the BIOS signature and the immutability of SMRAM. Second, all inter‑party messages are encrypted with an AES‑GCM (or equivalent) scheme, and the cryptographic operations are implemented in constant‑time to thwart timing side‑channels. Third, the SSV intercepts device interrupts by reprogramming the I/O APIC’s redirection table, ensuring that the untrusted OS never sees raw NIC or timer interrupts, thus preventing interrupt‑spoofing attacks.

The paper implements two concrete TSSes. The clock service supports five commodity hardware timers, reads their registers directly, and applies overflow and latency compensation to deliver microsecond‑level absolute timestamps—far finer than SGX’s built‑in coarse‑grained time source. The network service ports a commodity NIC driver into SMM, handles packet transmission/reception inside SMRAM, and exposes a standard socket API to the enclave. By keeping the entire network stack within the trusted SMM boundary, Aurora eliminates the need for the enclave to rely on the OS’s TCP/IP stack, thereby protecting against traffic analysis, injection, and man‑in‑the‑kernel attacks.

Performance optimizations include event‑driven notifications, “exit‑less” interrupt handling (the SSV processes interrupts without repeatedly exiting SMM), and batching of SMI calls to reduce the overhead of mode switches. In evaluation, the authors port SQLite and OpenSSL to use Aurora’s services. SQLite benefits from the high‑precision trusted clock, achieving microsecond‑accurate timestamps for transaction ordering. OpenSSL’s TLS handshake, when run over Aurora’s network TSS, incurs roughly 1 ms additional latency compared with a native unprotected stack, representing a modest overhead given the security guarantees.

Limitations are acknowledged. Aurora assumes a trustworthy BIOS and that SMRAM cannot be tampered with after boot; a compromised BIOS would break the trust model. The design does not protect against denial‑of‑service attacks that disable SMI generation, nor does it currently provide file‑system or storage services. Extending Aurora to additional peripherals will require porting more drivers into SMM, which may be non‑trivial for complex devices.

In summary, Aurora demonstrates that by leveraging the highest‑privilege execution mode (SMM) together with SGX, it is possible to furnish enclaves with reliable, tamper‑proof system services without involving a malicious OS. This approach broadens the practical applicability of SGX in cloud and multi‑tenant environments, mitigating a class of attacks that have previously limited the security guarantees of enclave‑based applications.