Secure enclaves =============== Why are we reading this paper? Advanced isolation mechanism Last paper in our tour of isolation mechanisms Strong threat model that is relevant in practice Many desktops run malware Malware may control complete OS On servers, may want strong guarantees about running your code Cutting-edge technology Intel SGX released by Intel a few years ago Available in many Intel CPUs -- e.g., most recent laptops ARM, AMD have their own enclave-like machinery Design, use cases still in flux This paper argues for a different approach to build enclaves Process isolation (lab 2, OKWS, etc.) OS kernel is in charge of isolation processes Each process has its own address space Process cannot even name memory of other processes Implementation OS kernel maintains a page table for each process Application uses system calls to ask for OS services Start a process Allocate memory Advanced process isolation Limit systems calls application can make (seccomp, apparmor, etc.) Linux containers Threat model for process isolation OS kernel is trusted Disallow processes from reading/writing each other's memory Disallow process from modifying shared state (e.g., files) Disallow process from reading/writing kernel memory Enclave goal Even when OS kernel is compromised, app can still keep secrets Subsumes many potential attacks Maybe attacker is running a key logger Maybe attacker is trying to steal data out of an application Non-goal: availability If an adversary controls the OS, can prevent enclave from working Don't let the enclave run; misconfigure network; misconfigure display; etc Target applications: Logging in to your bank Secure: OS/key logger cannot steal your password+PIN to login Video/music player for copyrighted content (DRM) Secure: OS cannot steal key to decrypt content Running some computation on a remote server (e.g., something like AWS) Secure: compromised OS on server can't tamper with my computation Ambitious goal OS is traditionally in full control of computer Applications rely on OS to load, allocate memory, run threads, etc. Much prior research on defending against malicious OS TPM, secure boot: verifying what OS is booted Focus on attacks that try to boot a modified OS Special processors (e.g., Apple's secure enclave coprocessor) Strong isolation but requires special hardware Does not help applications that want to launch their own enclaves Use a trusted hypervisor Run sensitive tasks in a separate VM Hypervisor might be comparable to OS in complexity Setting up separate VM often heavy-weight compared to fork() SGX is the most recent big shift in this space High-level enclave abstraction Similar to a process, but strong isolation from OS, other enclaves Create enclave, like starting a process Mostly secure pages: isolated from OS, other enclaves Insecure pages allow sharing/comm. with other processes, OS, network Calls/messages between enclave and regular processes, OS syscalls Attestation: prove enclave identity Signed message indicates what software is running in the enclave Clients can check attestation before sending secrets or trusting results Enclaves (SGX, Komodo) Interpose between the OS kernel and hardware Minimal machinery for isolation, attestation Ideally, simple enough to be correct SGX: heavily relying on CPU microcode Komodo: trying to disentangle what should go into hardware vs software Threat model Attacker controls OS Attacker might be able to get access to DRAM contents Physical tampering with computer DMA attacks from peripherals controlled by OS Mis-configuring DRAM controller itself Enclave machinery is implemented correctly CPU chip Private key stored in chip Intel's microcode or Komodo's monitor software What's needed in hardware? Komodo section 3.2 Isolated memory: prevent adversary from accessing enclave memory Prevent OS kernel from accessing all of memory Prevent physical attacks on memory, perhaps Encrypt and authenticate all data stored in DRAM Prevent peripheral devices from accessing all of memory, if not encrypted IOMMU to limit what parts of DRAM a device can access Komodo: reserve region of "secure" physical memory in ARM SoC SoC does not connect peripherals to this secure memory region SGX: encrypt and authenticate all "secure" memory leaving CPU Deals with physical memory attacks, peripherals, DRAM controller, etc. Execution modes for monitor, enclaves Run monitor code on CPU with access to "secure" memory More privileged than OS kernel Run enclave code with limited access to memory Has access to parts of secure memory assigned to enclave Should not have access to entire secure memory region Switch between monitor and regular OS Calls from enclave to monitor; calls from enclave to OS; interrupts; .. Komodo: ARM TrustZone, Figure 1 in Komodo paper "Secure world" vs "Normal world" Only the secure world has access to secure memory Switch between worlds through special CPU instructions, registers Controlled entry into secure world: only through the trap handler Run enclave as a user-mode process in secure world Much like a regular OS process: page tables to isolate Monitor is much simpler than traditional OS kernel SGX: special CPU instructions trigger microcode as the monitor equivalent Remote attestation Monitor computes a cryptographic hash to describe enclave contents Log of operations used to build up the enclave (in both SGX and Komodo) Allocated pages, initial contents, thread starting point, etc. Remote party computes the hash it expects for specific enclave binary Well-known rules for how to load a binary into an enclave Private key known only to the monitor Remote party must know the corresponding public key of the monitor Device manufacturer "blesses" public keys of devices they sell Intel SGX is along these lines (but more complex: group signatures) Remote party checks signed message from monitor key matches expected hash Signature should also contain public key of enclave Bootstraps subsequent communication with software in the enclave Monitor API: Table 1 Everything is a page (4 KBytes) of memory PageDB tracks the state of every secure page Unallocated Address space (enclave) Thread state L1 page table L2 page table Data page Spare page PageDB lives in monitor's secure memory Accessible only through monitor calls OS responsible for tracking which secure pages are free, etc. PageDB helps guard against OS mis-managing secure pages Creating an enclave InitAddrspace(aspg, l1pg) aspg, l1pg must be unallocated Bug (section 9.1): must be distinct! Otherwise monitor could get confused, corrupt data in this page Sets up initial enclave state in aspg: Pointer to page table (l1pg) Hash of log of creation steps Count of pages used by enclave .. InitL2PTable(aspg, l2pg, position) aspg must be an Address space page l2pg must be unallocated Adds l2pg into enclave's l1pg Adds entry to enclave creation log MapSecure(aspg, datapg, va, content) datapg must be unallocated Page table must have free slot for va Adds entry for mapping content at va into log InitThread(aspg, threadpg, entryaddr) threadpg must be unallocated Adds entryaddr to log Finalize(aspg) Set flag in aspg to indicate no more changes Running enclave Enter(thread, args..) Start running in enclave mode using thread's aspg's L1 page table Enclave can invoke monitor calls, OS syscalls Enclave must explicitly copy data before making an OS syscall Otherwise OS has no way of accessing enclave's syscall arguments Enclave might get suspended OS can resume enclave thread: Resume(thread) Thread state tracks whether thread is indeed suspended or not Otherwise, malicious OS could resume a thread that's not suspended Enclave applications? Running computations on remote server Seems like the cleanest fit Attestation guarantees your code, data is really running Enclave guarantees adversary cannot tamper with your code, data Actual application: contact discovery for Signal [[ Ref: https://signal.org/blog/private-contact-discovery/ ]] Want to look up if any of my friends are using Signal's messaging system Send all of my friends' phone numbers to the server: server could disclose Send all Signal users' phone numbers to my phone: slow, bad for privacy too With SGX: get attestation that server is running contact discovery program Sending contacts to the server is OK if the code doesn't leak them Could examine the code of the server corresponding to the known binary DRM Server can request attestation that client is running approved media player Media player runs in enclave to hide sensitive movie file from the user How to play the movie without revealing the movie file? Possibly HDCP: encrypted link to the monitor [[ Ref: https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection ]] User authentication, logging into a bank U2F in an enclave instead of a separate USB device Many nice properties but user I/O seems hard No way for enclave to know if user really wants to log in With USB device, physical button cannot be pressed by malware Promising applications, but secure user I/O is a problem for some use cases Is a monitor more secure than an OS kernel or hypervisor? Table 2 Hard to tell exactly what the lines-of-code / assembly numbers mean, but seems like Komodo's monitor is under a few thousand lines of code Tiny compared to OS kernel, VMM Sections 5, 6: formally verified! Eliminates large classes of bugs in monitor software Big topic on its own -- see 6.822, 6.826 What's in the TCB? CPU manufacturer Komodo's monitor (or verification tools and the specs) Boot loader that starts running the monitor Remote attestation brings in a more complex set of assumptions Key was correctly embedded into CPU by manufacturer If clients trust any CPU key, then must trust that no CPU was compromised Komodo vs SGX? Plausible argument for software flexibility Nice decomposition of what's required to implement enclaves Verification seems a big plus (could be done for SGX microcode too, perhaps?) Komodo is simpler than SGX Some simplicity is probably a better design: no shared address space, paging Some simplicity is a lack of features: no concurrency, remote attestation, .. Summary Enclaves are a recent development in isolation mechanisms Important threat model: compromised OS Still many open questions: right design, side channels, applications, .. SGX references: SGX Overview: http://www.pdl.cmu.edu/SDI/2013/slides/rozas-SGX.pdf SGX Instructions overview https://software.intel.com/sites/default/files/article/413936/hasp-2013-innovative-instructions-and-software-model-for-isolated-execution.pdf Attestation https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing SGX hardware https://jbeekman.nl/blog/2015/10/sgx-hardware-first-look/ SGX Security discussion https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/january/intel-software-guard-extensions-sgx-a-researchers-primer/ Iago attacks https://cseweb.ucsd.edu/~hovav/dist/iago.pdf Drawbridge http://research.microsoft.com/pubs/141071/asplos2011-drawbridge.pdf Side-channel attack https://www.usenix.org/system/files/conference/woot17/woot17-paper-brasser.pdf https://www.ieee-security.org/TC/SP2015/papers-archived/6949a640.pdf SGX explained https://eprint.iacr.org/2016/086.pdf Malware in enclave https://regmedia.co.uk/2019/02/12/sgxmalware.pdf