SGX and Haven ============= Why are we reading this paper? Advanced hardware 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 Uses cutting-edge technology (Intel SGX) But, no deployed experience with SGX yet May have design and implementation flaws First hardware is available (see ref below) Process Isolation (lab 2, OKWS, etc.) OS is in charge of isolation processes Each process has its own address space Process cannot even name memory of other processes Implementation OS maintains a page table for each process Application uses systems calls to ask for OS services Allocate memory Send packets, etc. Advanced process isolation Limit systems calls application can make (seccomp, apparmor, etc.) Linux containers Threat model for process isolation OS is trusted Disallow processes to read/write each other memory Disallow process to modify share state (e.g., files) Disallow process to read/write kernel memory SGX Goal Even when OS is compromised, app can still keep secrets Maybe not whole OS compromised But maybe attacker is running a key logger 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 Haven: unmodified windows applications Ambitious goal App relies on OS How to defend against a malicious OS? OS interface is wide How to check for app that OS behaves appropriately? Much opportunity for "Iago" attacks Iago attacks: attacks that untrusted OS can use to attack an application OS modifies getpid() and time() to return a different number, same number getpid() and time() often used to seed a pseudo random generator OS can confuse server running SSL OS can record packets from a successful connection OS can cause the next of instance of SSL to use same server nonce By returning same value for time() and getpid() as for earlier connection OS can replays packets SSL server thinks it is a fresh connection, but it isn't Maybe launch a man-in-the-middle attack OS modifies mmap() to map a physical page that the OS controls over app stack malloc() calls mmap() OS can run arbitrary code OS can read app secrets (e.g., private key of SSL connection) Lesson: simple systems calls (e.g., getpid and time) can cause trouble App must be written defensively Protecting legacy apps against malicious OS seems hard Much research on defending against malicious OS Some use TPM or late boot Some use a trusted hypervisor Some use special processors (e.g., Apple's secure enclave coprocessor) Now Intel's Skylake includes SGX (see ref below) It provides hardware mechanism to help defend against Iago attacks SGX Threat model Attacker controls OS Attacker can observe traffic between processor and memory Every component that is not the processor is untrusted Intel is trusted Chip works correctly Private key isn't compromised Side channels cannot be exploited SGX: Software Guard Extensions Enclave: trusted execution environment inside a process Processor ensures that enclave memory isn't accessible to OS, BIOS, etc. Attestation Processor signs content of enclave with private key baked into chip Verifier uses Intel's public key to check signature Sealing Scheme for sealing enclave on termination, and unsealing later Enclave Figure 1 in Haven paper and Sec 5 in https://eprint.iacr.org/2016/086.pdf PRM Region in physical memory that cannot directly accessed by OS, DMA by IO devices ECREATE(va, sz): creates an empty enclave starting virtual address and size allocates Enclave control structure (SECS) in PRM sets SECS's init bit to false EADD(page, srcpage, SECS, perm) to add a page to enclave OS allocates page in EPC (enclave page cache), which is in PRM SGX fills it with content from srcpage (which lives outside of PRM) Enclave page cache Lives in PRM 4-Kbyte pages Processor maintains a map (EPCM) that for each EPC page records: - page type (REG, SECS, ..) - the enclave ID - the virtual address for the page - permissions EPCM is accessible only to processor Use to check OS translations Map is consulted on each enclave page access Is the page in enclave mode? Does page belong to enclave? Is the page for the accessed virtual address? Does access agree with page permissions? Starting enclave (EXTEND, EINIT) Processor keeps a cryptographic log of how the enclave was built EXTEND adds the hash of a page added by EADD to the log EINIT takes as argument a SIGSTRUCT signed by a sealing authority (enclave writer) includes: expected signed hash of enclave and public key of enclave owner EINIT verifies signature and hash Attestation: Remote party can verify that enclave runs correct code An enclave gets its keys use EGETKEY keys for encrypting and sealing EREPORT generates a signed report Report contains the hash of log and a public key for enclave This report can be communicated to another enclave The receiving enclave can verify the report using the public key in the enclave A special Quoating enclave can create a signed "quote" using processor's private key Uses a group signature key so that an individual processor is identified Entering/exit enclave enter using ENTER with a thread control structure (TCS) exit: EEXIT, interrupt, or exception resume an enclave using ERESUME Paging an EPC page to external storage OS executes EWD to evict page into buffer encrypted, version number, etc. OS can write buffer to external storage OS executes ELDB to load encrypted page into EPC use version number to detect roll-back attacks One-time password scheme from Intel's paper Goal: Prevent OS from stealing OTP key Client downloads OTP application and runs it OTP application creates enclave with code+data code includes reading from keyboard, SSL, etc. generate a quote connect to server, setup secure channel (e.g., SSL), and send quote negotiate user's OTP secret Server verifies quote server knows runs that client started with the right software i.e. not some rogue OTP client that maybe emails OTP code to adversary negotiate OTP secret with user's OTP enclave For subsequent logins: client's OTP enclave connects to server, sends quote receives challenge hashes one-time password and challenge, responds to server OS cannot steal the one-time password One weakness: user does not control authentication adversary can take over user's machine and log into user's bank account need trusted I/O path between OTP enclave and user's keyboard/display weak story in the paper about this Another weakness: bootstrapping how does the user know the OTP enclave got installed on THEIR machine? could be a "cuckoo" attack, as in the Cloud Terminal paper.. Haven Use SGX for executing unmodified Windows applications in the cloud securely Securely means don't trust cloud provider Provide an application environment so that apps can interact with untrusted software Applications need to send packets Applications need to store files ... Application needs operating systems Haven is a research project Haven design (figure 2) Implement Drawbridge's API so that it protects against Iago attacks Shield module implements API inside enclave interacts with host OS using a narrow, untrusted API untrusted API is a subset of drawbridge's API (see figure 3) Untrusted runtime tunnels between Shield in enclave and host kernel Also needed for bootstrap Host kernel contains SGX driver and drawbridge host drawbridge host implements the narrow API using OS calls Haven/SGX interaction Virtual memory Enclave starts at 0 (to handle null pointer deferences by app, libos) Tracking memory pages used by application/libos Adding/removing memory pages from enclave Verifies that changes have been made correctly Never allows host to pick virtual-memory addresses Doesn't allow application and libos to allocate pages outside of enclave Cannot map enclave page at more than virtual address Storage Final lab Threads user-level scheduling (e.g., so that mutexes work) multiplexes threads on a fixed number of threads created at startup Allocate a fixed number of TCSs at start Misc RDRAND for trusted source of randomness No fork No address space randomization Security discussion SGX Difficult to evaluate security processors with SGX just have become available no experience with deployments TCB Processor Fab of processor Intel's private key Iago attacks Can OS read/write data inside enclave Processor's EPC prevents this Can OS remap memory? Processor's EPCM prevent this attack Can OS confuse application? Client must be carefully written to rely on few OS functions Client needs a reliable source of randomness to implement SSL RDRAND Client must be able to send and receive packets check results Side channel attacks Excluded by threat model, but possible in practice Hyperthreading Shared L3 cache Multi-socket 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