Class 15 CS 480-008 29 March 2016 On the board ------------ 1. Last time 2. Untrusted OSes: threat and scenario 3. SGX --------------------------------------------------------------------------- 1. Last time --EXE --concolic testing --lab notes Today: another isolation mechanism. this one is a bit different in that here, the app is being protected from the layers beneath it. relies on cutting (bleeding?) edge technology (Intel SGX) Threat models we'll consider are strong (powerful adversary, few assumptions) and relevant in practice. 2. Untrusted OSes: threat and scenario --threat model: the OS itself is the attacker. can attack privacy, integrity, or both --example scenario 1: your desktop, laptop, or phone is infected by malware, which controls the OS. important apps (banking client, for example) should still be protected. --example scenario 2: cloud platform provider (Amazon, Google, Microsoft) supplies OS; app writer supplies app. --attack on privacy: OS sees all memory; steals private data; this is easy to do. --attack on integrity: OS can modify app code. --one response: use TPM (Trusted Platform Module) or late boot. Issues with performance and functionality. --another response: Inktag, Overshadow, etc.: trust the VMM but not the OS (still want the OS because it performs lots of useful functions) basic idea: use the VMM to encrypt and authenticate memory; untrusted OS never sees memory "in the clear" Issues: (1) This still requires trusting the VMM (2) Iago attacks are still possible: the OS doesn't directly mess with the app, but gives syscall return values that cause the app to harm itself 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 replay 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 --Haven wants to respond to both issues. Ask yourself: What if anything do they trust? How do they respond to Iago attacks? --Goals of Haven Confidentiality: the app itself and what data it handles Integrity: the app should execute as written --Non-goal of Haven: Availability: why does it seem fundamentally hard to provide availability, given the setup? Begin by discussing SGX, which is the foundation of Haven.... 3. SGX Goal of SGX 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 Root of trust: Intel itself. Assumption: everyone knows and trusts Intel's public key. Intel's private key is inside the processor. Specific threat model for SGX: --Attacker controls OS --Attacker can observe traffic between processor and memory Every component that is not the processor is untrusted --Intel is trusted Chip designed correctly Chip manufactured correctly Private key isn't compromised --Side channels cannot be exploited High-level ideas: Enclaves: trusted execution environment inside a process Processor ensures that enclave memory isn't (directly) accessible to OS, BIOS, etc. Attestation Processor signs content of enclave with private key A remote party (like your bank's server) checks the signature What's required to build an enclave? * Execution needs to be protected. What does that mean? Code cannot jump outside the enclave except at well-defined points When there's an orderly exit, the register state is scrubbed (by the enclave) When there's an async exit (exception, etc), the processor saves the registers, and hides them * Memory needs to be protected. What and how? see Figure 1 in Haven paper, which sort of depicts this ECREATE creates an empty enclave starting virtual address and size EPC: enclave page cache Region in physical memory Processor's memory encryption interface encrypts/decrypts when writing/reading to/from EPC Also integrity protected EADD to add an EPC page to enclave Processor maintains a map (EPCM) that for each EPC page records: page type (REG, ...), the enclave ID, the virtual address for the page, and permissions EPCM is accessible only to processor Map is consulted on each enclave page access. Processor checks: Is the page in enclave mode? Does page belong to the enclave that is accessing it? Is the page for the accessed virtual address? Does access agree with page permissions? Paging an EPC page to external storage The problem: EPC pages are a scarce resource. There might be many more pages that are logically protected than there are slots in the EPC OS is in the business of managing resources. So with SGX, the OS manages which enclaves get which slots, but cannot see inside those slots. Two instructions for this purpose: EWB, ELDB --EWB: OS executes this to evict page from EPC into buffer abstract interface: EWB(EPC page, VA) processor encrypts and authenticates the EPC page (and attaches a version number), and then places the bundle at virtual address VA, which the OS controls. --ELDB: OS executes this to put an encrypted page from a buffer back into the EPC abstract interface: ELDB(VA, EPC page) processor decrypts and authenticates, checks version number (which was stored in an enclave-specific data structure that the OS cannot modify), and places the page in the designated EPC page Notice: this arrangement means that the Host OS knows which virtual pages the enclave is using (because the host OS "sees" the faulting page info) Starting enclave (EXTEND, EINIT) Processor keeps a cryptographic log of how the enclave was built EEXTEND adds 256-byte region to log Log contains content (code, data, stack, heap), location of each page, security flags 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 Enclave identity stored in SECS (SGX Enclave Control Structure) Attestation: Remote party can verify that enclave runs correct code An enclave gets its keys using EGETKEY keys for encrypting and sealing EREPORT generates a signed report Report contains the hash of log and a public key for enclave public is in enclave-provided data in report? This report can be communicated to another enclave The receiving enclave can verify the report using the public key in the enclave A special Quoting 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 Protected bank client (hypothetical and simplified) Goal: Prevent OS from stealing user's password Assume a secure path from keyboard to enclave (Intel ME?) Client downloads bank application and runs it Bank application creates enclaves 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 Server verifies quote server knows that client started with the right software i.e. not some rogue client that maybe emails user password to adversary Server sends challenge client uses password to respond to challenge over SSL password inside enclave, encrypted OS cannot steal it Server checks challenge Security discussion Difficult to evaluate security processors with SGX just have become available no experience with deployments complex specification, hard to reason about What's the TCB (Trusted Computing Base) for SGX? The Processor *design* The Processor *manufacturer* (the foundry or fab) 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 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 Acknowledgments: MIT's 6.858 staff