SGX and Ryoan ============= Why are we reading this paper? Advanced hardware isolation mechanism Last paper in our tour of isolation mechanisms Cutting-edge technology (Intel SGX) New kind of isolation property Prevent untrusted (i.e., possibly malicious) software from leaking secrets Real problem, hard to achieve Ryoan's goal Process confidential user data in a distributed application Make sure the user's data stays confidential Threat model: The server operators might be trying to get the user's data The application code might be trying to get the user's data Fairly general in terms of supporting existing applications C or any other language As long as it uses libc Needs some changes to interact with user, other services Core part of the program seems like it can remain unchanged Two hard technical problems: Run application on untrusted platform Intel SGX Partial defense against untrusted OS interface (Iago attacks) Prevent application from leaking confidential data Sandbox the application using NaCl Control the app's interactions so they don't reveal data "One-shot" execution model: clear memory between requests Don't allow system calls into OS Predefined output size ... 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 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 Somewhat different from TPM Stronger threat model against physical attackers Memory encrypted No external chip, so harder to tamper physically Easier to access from an application: doesn't require running on raw hardware Doesn't promise app is running on bare hardware: relevant for user I/O Some vague suggestions in the SGX paper about how to provide secure I/O (Intel Trusted A/V, Intel ME) but not clear how to do this right 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 Little impact---mostly an intellectually-challenging exercise Now Intel's Skylake includes SGX (see ref below) It provides hardware mechanism to help defend against Iago attacks 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 ECREATE creates an empty enclave starting virtual address and size EPC: enclave page cache Physical memory is split into two portions: regular physical memory, and memory used by enclaves (EPC) Processor's memory interface encrypts/decrypts when writing/reading enclave pages to/from EPC (and also integrity-protects them) 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 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? 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 Version numbers themselves stored in another dedicated EPC page Starting enclave (EEXTEND, EINIT) Processor keeps a cryptographic log of how the enclave was built Log contains ECREATE, EADD, ... 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 Attestation: Remote party can verify that enclave runs correct code EREPORT generates a signed report Report contains the hash of log and a public key for enclave Public key is in enclave-provided data in report This report can be communicated to another enclave The receiving enclave an 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 not identified Entering/exit enclave enter using EENTER with a thread control structure (TCS) exit: EEXIT, interrupt, or exception resume an enclave using ERESUME 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.. SGX goes out of its way to not reveal device identity attestations have group signatures, not a device public key Security discussion 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 Other part of Ryoan: Preventing untrusted code from leaking secrets Why is this difficult? There's two processes involved One process is computing over confidential data, perhaps sandboxed Another colluding process is running somewhere else, not in a sandbox Strawman: Unix program in a Capsicum sandbox? Need capabilities for calling other services, returning result Ways to leak confidential data? Leak to observer on the same machine: Write data to a temporary file, have another process read it Modulate memory usage, other process runs "free" Create lots of temporary files, other process runs "df" Spawn lots of child processes, other process runs "ps" Leak to network observer: Don't encrypt the data when sending it to another service Call different services depending on what the confidential data is Modulate size of input to other services Modulate size of result Ryoan SGX for running on untrusted platforms NaCl for sandboxing application code Strict, almost "static" execution model Services that are called are defined ahead of time DAG Wait for all inputs to arrive in full Run application code, once Send output, padded to fixed size known in advance Application cannot interact with host OS in any way System calls emulated in enclave's memory In-memory file system, pre-allocated mmap page cache, ... Ryoan example application: email spam/virus checking Section 7.1 DAG: /---> Spam filter --->\ Distribute Combine \---> Virus scan ---->/ Message sent to distribution module .. sent to spam filter, virus scanner .. results go to the combine module .. sends response back to the user Why do they worry about randomness? Some small amount of data can be revealed through request completion time Randomness could allow program to leak randomly chosen parts of data By failing the network, adversary can re-process data, leak more parts of data No randomness -> deterministic -> no new leakage by re-executing after failure Limitations: side channels Timing of request completion Hardware side channels (L3 cache) References: http://css.csail.mit.edu/6.858/2017/readings/costan-sgx.pdf https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/january/intel-software-guard-extensions-sgx-a-researchers-primer/ https://cseweb.ucsd.edu/~hovav/dist/iago.pdf