Cloud Computing - Lesson 9: Cloud Security PDF
Document Details
Uploaded by UserReplaceableWashington1055
UCLouvain - Université catholique de Louvain
Etienne Rivière
Tags
Summary
This document is a lecture presentation on cloud security. It details various security concerns in cloud computing, such as the security of cloud computing platforms and applications, and novel approaches to confidential data processing in clouds. It also discusses different aspects such as the "The Provider perspective" and "The Client perspective" .
Full Transcript
LINFO2145 — Cloud Computing Lesson 9: Cloud Security Pr. Etienne Rivière [email protected] 2 Announcements Quiz #3 on lectures 5 and 6 Results available after this lectur...
LINFO2145 — Cloud Computing Lesson 9: Cloud Security Pr. Etienne Rivière [email protected] 2 Announcements Quiz #3 on lectures 5 and 6 Results available after this lecture Quiz #4 on lectures 7 and 8 Will be available after this lecture Deadline: Nov. 27, 10:45 Reviews: Dec. 4, 10:45 Cloud Computing — E. Rivière 3 Lecture objectives Introduce some of the speci c security concerns introduced by Cloud computing Overview solutions for protecting data and computation integrity Describe novel approaches for con dential data processing in the Cloud Cloud Computing — E. Rivière fi fi 4 Introduction (1) Cloud computing platforms and applications = tempting attack target Large amount of data in the same place Financial gain from selling/trading sensitive data Resources are accessible online, remotely No control over hardware and limited control over software stack (in particular in PaaS) Multi-tenancy offers larger attack surface One provider holds data from multiple companies Co-location of resources = new attack opportunities Vulnerability in one service can affect others Cloud Computing — E. Rivière 5 Introduction (2) Trust towards Cloud provider must be very high 🤔 Is the provider worth this trust? 🤔 Will the provider need to abide by local privacy- threatening regulations? (e.g. PATRIOT act) 🤔 What if the provider gets corrupted? ➡ Focus on security aspects that are speci c to the context of Cloud computing systems Application-level security (authentication, etc.) and OS-level security (patches, best practices, policies) obviously still important! Cloud Computing — E. Rivière fi 6 Why is Cloud security important? Cloud Computing — E. Rivière 7 The Provider perspective Cloud provider needs to protect against malicious Application/service Hypervisor customers Hypervisor-based isolation Application/service Hypervisor One-way protection Application/service Does not protect customer against provider! Hypervisor … Cloud Computing — E. Rivière 8 The Client perspective Cloud tenant is forced to trust the provider… Application/service Including personnel OS Including every software component VMM Firmware Cloud platform Ideally, client would like to trust only her/his service Staff … Cloud Computing — E. Rivière 9 Multi-tenancy and security Cost saving and ef ciency thanks to resource sharing Virtualized machines over same physical hosts Sharing of the network Sharing of services (VM image storage, container repository, …) ❌ Virtualization = new security threats VMM/hypervisor can be attacked to get information about, or access to, virtual resources/machines Very dif cult to detect from inside a VM! Access to the hypervisor = access to all of the VMs memory, including page tables, kernel memory, etc. ✓ On the other hand, cloud platforms also likely to be administered by dedicated security experts who follow security updates and best practices very diligently Cloud Computing — E. Rivière fi fi 10 Protected mode not suf cient Protected mode (rings) protects OS from applications, and isolates applications from one another… until a malicious application exploits a aw to gain full privileges and then tampers with the OS or other applications Applications not protected from privileged code attacks The attack surface is the whole software stack Applications, OS,VMM, drivers, BIOS… Cloud Computing — E. Rivière fl fi 11 Example of protection rings in Microsoft Hypervisor Cloud Computing — E. Rivière 12 Attacking the Cloud Performed by executing software on the victim computer Can be done remotely Vast majority of attacks exploit vulnerabilities in software components E.g., memory safety violations in C/C++ E.g., bogus APIs to services or IaaS infrastructure management interface But now also attack hardware: Spectre and Meltdown for Intel CPUs, RowHammer attacks Cloud Computing — E. Rivière 13 The software stack Cloud platforms contain enormous amounts of code that must be trusted Linux: ~20 MLOC KVM: ~13 MLOC OpenStack: ~2 MLOC Cloud platforms are effectively a trusted computing base (TCB): all components of the system are critical to security Software, hardware Cloud Computing — E. Rivière 14 Bugs are a reality More code more bugs Exploited vulnerability may lead to complete disclosure of con dential data Xen hypervisor 184 vulnerabilities (2012-2016) http://www.cvedetails.com/product/23463/XEN-XEN.html?vendor_id=6276 Linux kernel 721 vulnerabilities (2012-2016) http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 Especially bad in privileged software as it may result in unrestricted access to the system Cloud Computing — E. Rivière fi 15 Examples of software attacks Control- ow hijacking Goal: execute arbitrary code on the target machine Modify application’s control ow Example: format string vulnerabilities Code injection attack Overwrite return address by writing beyond allocated buffer on the stack (inject code, jump to the injected code) Return-oriented programming Hijack control ow by corrupting stack (no injection) Jump to sequences of instructions (gadgets) already present in memory (e.g., libc) ending with a return Chain gadgets to compose arbitrary code Cloud Computing — E. Rivière fl fl fl 16 Example: Heartbleed bug Serious vulnerability in the popular OpenSSL cryptographic software library Very widely used: apache/nginx (66% of Web servers), email servers, chat servers,VPN, etc. Buffer overrun when replying to a heartbeat message Improper input validation (missing a check of bounds) in the implementation of the heartbeat extension Vulnerability introduced in the code in 2012, disclosed in April 2014 together with xed software Could be exploited to get read access to memory The attacker can obtain sensitive data from server’s memory: passwords, private keys, … Cloud Computing — E. Rivière fi 17 Other examples “All your clouds are belong to us”, 2011 Attacks on the EC2 management APIs Using the SOAP WS interface (not REST) Were able to issue VM create/delete for unauthorized user Colocation attacks Reserve machines on public clouds Goal is to be collocated with a victim VM Exploit bug at hypervisor level to inspect VM content Exploit bug at OS/CPU level to obtain cached content from previously-scheduled VMs More recently: Exploit hardware attacks Cloud Computing — E. Rivière 18 Hardware attacks in the Cloud May or may not require physical access to the machine With physical access Bus snif ng Dump CPU memory communication Cold boot attacks DRAM retains its state for a short period of time Power cycle the machine, boot to a lightweight OS, dump memory contents… or remove memory modules, plug into another machine, dump memory contents Cloud Computing — E. Rivière fi 19 Remote hardware attack: “Row hammer” Attack the system by causing bit- ips in memory Accessing physical bits many, many times may cause neighbouring bits to ip Carefully chosen addresses can result in privilege escalation Rapid row activations (yellow rows) may change the Effect values of bits stored in victim row (purple row). [wikipedia] Sandbox escape code1a: Corrupted page table mov (X), %eax mov (Y), %ebx clflush (X) // // // read from address X read from address Y flush cache for address X clflush (Y) // flush cache for address Y mfence jmp code1a 19 Cloud Computing — E. Rivière fl fl 20 Goals: security in the Cloud Con dentiality Information is not made available or disclosed to unauthorized individuals, entities, or processes Encryption Integrity Data cannot be modi ed in an undetected manner MAC, digital signature Cloud Computing — E. Rivière fi fi 21 Tools: cryptographic hash function Algorithm that maps arbitrary input string into a xed-size output (hash) Infeasible to invert (one-way function) Deterministic Collision resistant Probability of two messages having the same hash is negligible “Infeasible” to nd collisions More computationally intensive than non-cryptographic hash functions or Even small changes in the source input (here in the word “over”) drastically change the resulting output, by the so-called avalanche effect. ngerprints (e.g., for deduplication) [wikipedia] Cloud Computing — E. Rivière fi fi fi 22 Tools: symmetric cryptography All parties have a shared secret key Same key for encryption and decryption Example: AES (advanced encryption standard) Alice Bob Eve PlainText PlainText Secret Secret Encryption CipherText Decryption key key Cloud Computing — E. Rivière 23 Tools: symmetric cryptography Message authentication code (MAC) Tag to check the integrity and authenticity of the message Key required to produce correct MAC (Keyed hash function) Does not provide con dentiality Bob Alice Eve Accept PlainText Yes No Correct tag? Reject Secret Secret Compute MAC Tag PlainText Verify MAC key key Cloud Computing — E. Rivière fi 24 Tools: asymmetric cryptography Each party has a key pair Public key: not secret, used for encryption Private key: secret, used for decryption Example: RSA (Rivest-Shamir-Adleman) Alice Bob Eve PlainText PlainText Bob’s Bob’s Encryption CipherText Decryption public key private key Communication channel Cloud Computing — E. Rivière 25 Tools: asymmetric cryptography MAC in asymmetric world: digital signature Sign with sender’s private key Verify with sender’s public key Bob Alice Eve Accept PlainText Yes No Correct Sig? Reject Alice’s Alice’s Sign message Sig PlainText Verify signature private key public key Communication channel Cloud Computing — E. Rivière 26 Ensuring data con dentiality Data-at-rest protection Encrypt data before storing on disk Encrypted le systems, full-disk encryption Data-in- ight (communication) protection Well established end-to-end encryption mechanisms Transport layer security (TLS) Trusted platform module (TPM) Tamper-resistant chip external to the CPU Facilities for secure generation of cryptographic keys, remote attestation, sealed storage Limited protection, susceptible to physical attacks Cloud Computing — E. Rivière fl fi fi 27 Ensuring data con dentiality 🤔 But how to ensure con dentiality during computations (data in use)? Need to decrypt data before processing Encryption keys/plaintext data in main memory/ registers ☹ Memory dump will reveal all secrets Using one of the techniques mentioned previously Cloud Computing — E. Rivière fi fi 28 Securing data during computation Challenges Data should be searchable (e.g., the ability to perform a search for a value, a range query, etc.) Must not leak information (e.g., statistical attack knowing the distribution of values) Privacy-utility-performance tradeoffs Tools Software-level encryption Deterministic or non-deterministic, order-preserving, homomorphic, … Speci c vs. generic encryption mechanisms Hardware support for trusted computing (e.g., SGX) Cloud Computing — E. Rivière fi 29 Encrypted data processing Homomorphic encryption “a form of encryption which allows speci c types of computations to be carried out on ciphertext and generate an encrypted result which, when decrypted, matches the result of operations performed on the plaintext” [wikipedia] Fully homomorphic encryption [Gentry 2010] Generic: supports arbitrary functions on encrypted data Addition, multiplication, binary operations Cloud Computing — E. Rivière fi 30 Homomorphic encryption HELib: open-source homormophic encryption library in C++ by IBM [Shoup and Halevi, 2012] Many optimizations to make HE “practical”, i.e., make homomorphic evaluation run faster Low-level routines (set, add, multiply, shift, etc.) Still far from being practical Addition: ~1+ ms Multiplication: ~10/100+ ms Evaluated the AES-128 circuit in 36 hours in 2012 (vs. 2 ms in the clear) https://mpclounge.files.wordpress.com/2013/04/hespeed.pdf Cloud Computing — E. Rivière 31 Speci c encryption schemes Homomorphic encryption generic but costly Speci c encryption schemes target limited operations on data Exact-match search Nearest-match search Range queries Equalities Example CryptDB: encrypted SQL database Cloud Computing — E. Rivière fi fi 32 CryptDB: encrypted SQL database User 1 untrusted Threat zone 1 Threat 2 Password P1 Active Application Database proxy Unmodified DBMS CryptDB UDFs session User 2 Key setup Password P2 Active keys: Annotated Data Encrypted P1 schema (encrypted) key table Users' computers Application server CryptDB proxy server DBMS server gure 1: CryptDB’s architecture consisting of two parts: a database proxy and an unmodified DBMS. CryptDB uses user-defined functions (UDF Proxy between client running in trusted zone perform cryptographic operations in the DBMS. Rectangular and rounded boxes represent processes and data, respectively. Shading indicat omponents added by CryptDB. Dashed lines indicate separation between users’ computers, the application server, a server running CryptDB’s databa and database running in untrusted zone (Cloud) oxy (which is usually the same as the application server), and the DBMS server. CryptDB addresses two kinds of threats, shown as dotted lines. reat 1, a curious database administrator with complete access to the DBMS server snoops on private data, in which case CryptDB prevents the DB om accessing any private information. In threat 2, an adversary gains complete control over both the software and hardware of the application, pro Query rewriting and data encryption nd DBMS servers, in which case CryptDB ensures the adversary cannot obtain data belonging to users that are not logged in (e.g., user 2). Decryption of received query well-defined set of primitive operators, such as equality checks, results fields (including a new policy in HotCRP for handling papers order comparisons, aggregates Handling (sums), and of keys joins. By adapt- ing known encryption schemes (for equality, additions, and or- conflict with a PC chair) and 2–7 lines of source code changes f three multi-user web applications. Untrusted zone der checks) and using a new privacy-preserving only sees The cryptographic method for joins, CryptDB encrypts each data item in a way that encrypted data rest of this paper is structured as follows. In §2, we discu the threats that CryptDB defends against in more detail. Then, w allows the DBMS to execute on the transformed data. CryptDB is describe CryptDB’s design for encrypted query processing in gureavoids efficient because it mostly uses symmetric-key encryption, from original paper and for key chaining to user passwords in §4. In §5, we prese fully homomorphic encryption, and runs on unmodified DBMS several case studies of how applications can use CryptDB, and Cloud Computing — E. Rivière fi 33 CryptDB: encrypted SQL database Standard encryption (AES) prevents from performing any type of query Ciphertext for same value encrypted twice is different: not possible to do even equality queries If e(x) is encrypted value of x: even if x == y, e(x) ≠ e(y) This randomization is a good thing in general: prevents Known-Plaintext Attacks Not possible to determine y even if x and e(x) known Use instead speci c encryptions allowing queries Various privacy-query expressiveness tradeoffs Cloud Computing — E. Rivière fi 34 CryptDB: encryption levels (1) Encryption Security Query expressiveness Two equal values map to different Random ciphertexts w.h.p.: indistinguishability No query possible (e.g. AES) under adaptive chosen-plaintext attack (IND-CPA) Deterministic Two equal values map to same + Equality search (e.g. Pseudo- ciphertext, but ciphertexts do not SELECT * FROM t random preserve ordering WHERE v=x permutation) Order-preserving For two values x and y, guarantees that + Range queries (random order (1) ciphertext for x is always e(x) and ORDER BY, MIN, MAX, preserving (2) if x < y then e(x) < e(y). SORT mapping) Cloud Computing — E. Rivière 35 CryptDB: encryption levels (2) Encryption Security Query expressiveness Summation- For two values x and y, guarantees that + Summations homomorphic (1) ciphertext for x is always e(x) and SUM(col), COUNT(col), (Paillier) (2) e(x) * e(y) = e(x+y). AVG(col), etc. Provided with a transformation T1 and T2, can compare the values in two Allow joins between two columns C1 and C2 encrypted with K1 columns even if Join and K2. T1 transforms values in C1 to encryption key used was values encrypted with K1 then K2, and different vice versa for T2. Word search Vulnerable to statistics attacks if word Limited full-word version (speci c enc. frequency is known by attacker of LIKE scheme) Cloud Computing — E. Rivière fi 36 Onion layers encryption SEARCH column, the colum RND: no functionality RND: no functionality text value that require equa OPE: order fices. However, th DET: equality selection Onion Search OPE-JOIN: we need an adap range join JOIN: equality join HOM: add strategies. any value any value int value Our idea is to e is, each value is dr Onion Eq Onion Ord Onion Add as illustrated in F certain kinds of fu Figure 2: Onion encryption layers and the classes of computation they CryptDB with allow. Onioncan store names data stand for encrypted the operations multiple they allow at some of layers (Equality, Order, Search, and Addition). In practice, some onions increasingly times their For example, ou maximum securit or onion layers may bestrong cipherson column types or schema omitted, depending functionality. annotations provided by application developers (§3.5.2). DET and JOIN Multiple onion If support up ofa needed are often merged for onion into a single more expressiveness, layer, DET and JOIN-ADJ (§3.4). A random IV for RND (§3.1), shared by layer of security and provide server with must givetations supported since JOIN is a concatenation strictly ordered, a the RND layers in Eq and Ord, is also stored for each data item. ciphertext and enc decryption key for this layer on the type of the e.g. provide Word key for RND search (SEARCH). layer is SEARCH toused allow exact searches to perform on encrypted text to support operations such as MySQL’s LIKE oper- match search cation developer CryptDB may not ator. We implemented the cryptographic protocol of Song et al. , the Search onion which was not previously gure implemented from originalby the authors; we also use paper onion does not m their protocol in a different way, which results in better security For each layer Cloud Computing — E. Rivière fi 37 CryptDB performance Example: throughput for TPC-C queries (standard benchmark) varying number of cores on the underlying MySQL DBMS server. CryptDB requires an additional machine for the proxy! Favourable example, performance highly dependent on workload Can be an order of magnitude (10x) slower in some cases Also requires the cost of encryption/decryption at client 50000 My Query (& scheme) Se 40000 Select by = (DET) 0.10 Select join (JOIN) 0.10 Queries / sec Select range (OPE) 0.16 30000 Select sum (HOM) 0.11 Delete 0.07 20000 Insert (all) 0.08 Update set (all) 0.11 10000 MySQL Update inc (HOM) 0.10 CryptDB Overall 0.10 0 Figure 12: Server and proxy 1 2 3 4 5 6 7 8 from TPC-C. For each query Number of server cores scheme used at the server. Du query type affects a different Figure 10: Throughput Cloudfor TPC-C queries, Computing for a varying number of — E. Rivière number of cryptographic oper 38 Towards hardware support Software-based con dentiality or data protection mechanisms are either: of limited applicability (only target some speci c problem/computation) with limited performance And often both! Trusted computing base remains the entire hardware and software stack Can we do better with some help from the hardware? Cloud Computing — E. Rivière fi fi 39 Intel SGX “Software guard extensions” Hardware extension in recent Intel CPUs since Skylake (2015) and Kaby lake (2016) Protects con dentiality and integrity of code and data in untrusted environments Platform owner is considered malicious Only the CPU chip and the isolated region are trusted Cloud Computing — E. Rivière fi 40 Enclaves SGX introduces the notion of an “enclave” Isolated memory region for code and data New CPU instructions to manipulate enclaves and a new enclave execution mode Enclave memory is encrypted and integrity- protected by the hardware Memory encryption engine (MEE) No plaintext secrets in main memory Enclave memory can be accessed only by the enclave code Protection from privileged code (OS, hypervisor) Cloud Computing — E. Rivière 41 Enclave memory Enclave memory is not accessible to other software But enclave can access memory within its process Application has ability to defend its secrets Attack surface reduced to just enclaves and CPU Compromised software cannot steal application secrets Process ✘ ✘ Enclave OS Hypervisor Cloud Computing — E. Rivière 42 Enclave memory Enclave de ne APIs Enclave interface functions: ECalls to provide input data to the enclave Calls outside the enclave: OCalls to return results from the enclave Constitute the enclave boundary interface SGX application Edge routines Edge routines Untrusted ECalls Trusted component component (application) OCalls (enclave) Cloud Computing — E. Rivière fi 43 SGX execution model User process Trusted execution Enclave environment in a process OS With its own code and data Enclave code With controlled entry points Provides con dentiality Enclave Enclave data Provides integrity Supporting multiple threads Application Threads With full access to application memory code … Application data Cloud Computing — E. Rivière fi 44 Enclave page cache (EPC) Physical memory region protected by the MEE EPC holds enclave contents Shared resource between all enclaves running on a platform First generation: only 128MB ~96MB available to the user, the rest is for metadata Much increased in newer versions (several GB, depending on processor model) Content encrypted while in DRAM, decrypted when brought to CPU Plaintext in CPU caches Cloud Computing — E. Rivière Example 45 SGX application: unstrusted code char request_buf[BUFFER_SIZE]; Enclave: Enclave: trusted trusted codecode char response_buf[BUFFER_SIZE]; char char input_buf[BUFFER_SIZE]; input_buf[BUFFER_SIZE]; int main() char char output_buf[BUFFER_SIZE]; output_buf[BUFFER_SIZE]; {... int process_request(char int process_request(char *in, *in, char char *out)*out) while(1) { { { copy_msg(in, copy_msg(in, input_buf); input_buf); receive(request_buf); if(verify_MAC(input_buf)) if(verify_MAC(input_buf)) ret = EENTER(request_buf, response_buf); { { if (ret < 0) decrypt_msg(input_buf); decrypt_msg(input_buf); process_msg(input_buf, fprintf(stderr, "Corrupted message\n"); process_msg(input_buf, output_buf); output_buf); else encrypt_msg(output_buf); encrypt_msg(output_buf); send(response_buf); copy_msg(output_buf, copy_msg(output_buf, out);out); } EEXIT(0); EEXIT(0);... } else } else } EEXIT(-1); EEXIT(-1); } } Server: Receives encrypted requests Processes them in enclave Sends encrypted responses Cloud Computing — E. Rivière Example 46 SGX application: unstrusted code char request_buf[BUFFER_SIZE]; Enclave: trusted code char response_buf[BUFFER_SIZE]; char input_buf[BUFFER_SIZE]; int main() char output_buf[BUFFER_SIZE]; {... int process_request(char *in, char *out) while(1) { { copy_msg(in, input_buf); 1 receive(request_buf); if(verify_MAC(input_buf)) 2 ret = EENTER(request_buf, response_buf); { if (ret < 0) decrypt_msg(input_buf); 3 fprintf(stderr, "Corrupted message\n"); process_msg(input_buf, output_buf); else encrypt_msg(output_buf); 4 send(response_buf); copy_msg(output_buf, out); } EEXIT(0);... } else } EEXIT(-1); } 1. Receive a request 2. Enter the enclave with two arguments: pointer to a buffer with encrypted request and pointer to a response buffer (EENTER instruction switches CPU to the enclave mode and transfers control to predefined location in enclave) 3. Print error message if enclave returns an error 4. Send the response provided by the enclave Cloud Computing — E. Rivière Example 47 SGX application: unstrusted code char request_buf[BUFFER_SIZE]; Enclave: Enclave: trusted trusted code code char response_buf[BUFFER_SIZE]; char char input_buf[BUFFER_SIZE]; input_buf[BUFFER_SIZE]; int main() char char output_buf[BUFFER_SIZE]; output_buf[BUFFER_SIZE]; { 1... intint process_request(char process_request(char *in, *in, char char *out) *out) while(1) { { { 2 copy_msg(in, copy_msg(in, input_buf); input_buf); receive(request_buf); 3 if(verify_MAC(input_buf)) if(verify_MAC(input_buf)) ret = EENTER(request_buf, response_buf); { { if (ret < 0) 4 decrypt_msg(input_buf); decrypt_msg(input_buf); fprintf(stderr, "Corrupted message\n"); process_msg(input_buf, process_msg(input_buf, output_buf); output_buf); else encrypt_msg(output_buf); encrypt_msg(output_buf); send(response_buf); copy_msg(output_buf, copy_msg(output_buf, out); out); } EEXIT(0); EEXIT(0);... } else } else } EEXIT(-1); EEXIT(-1); } } 1. Enclave entry point 2. Copy request into enclave memory (enclave can access in buffer in untrusted memory while untrusted part cannot access input_buf buffer in trusted memory) 3. Check the MAC (assuming keys were already exchanged) 4. Decrypt request Cloud Computing — E. Rivière Example 48 SGX application: unstrusted code char request_buf[BUFFER_SIZE]; Enclave:trusted Enclave: trustedcode code char response_buf[BUFFER_SIZE]; charinput_buf[BUFFER_SIZE]; char input_buf[BUFFER_SIZE]; int main() charoutput_buf[BUFFER_SIZE]; char output_buf[BUFFER_SIZE]; {... intprocess_request(char int process_request(char*in, *in,char char*out) *out) while(1) {{ { copy_msg(in,input_buf); copy_msg(in, input_buf); receive(request_buf); if(verify_MAC(input_buf)) if(verify_MAC(input_buf)) ret = EENTER(request_buf, response_buf); {{ if (ret < 0) decrypt_msg(input_buf); decrypt_msg(input_buf); fprintf(stderr, "Corrupted message\n"); 5 process_msg(input_buf, process_msg(input_buf,output_buf); output_buf); else 6 encrypt_msg(output_buf); encrypt_msg(output_buf); send(response_buf); 7 copy_msg(output_buf, copy_msg(output_buf,out); out); } 8 EEXIT(0); EEXIT(0);... } }else else } EEXIT(-1); EEXIT(-1); }} 5. Process request and store result in output buffer 6. Encrypt result and add MAC 7. Write result to untrusted memory for access from outside 8. Exit the enclave (EEXIT instruction switches from enclave to normal mode and transfer control to the next location after EENTER, similar to regular return) Cloud Computing — E. Rivière 49 Enclave construction DRAM 1 char input_buf[BUFFER_SIZE]; 2 char output_buf[BUFFER_SIZE]; int process_request(char *in, char *out) { copy_msg(in, input_buf); if(verify_MAC(input_buf)) { decrypt_msg(input_buf); 3 process_msg(input_buf, output_buf); encrypt_msg(output_buf); copy_msg(output_buf, out); EEXIT(0); } else EPC EEXIT(-1); } Enclave is populated using a special instruction (EADD) Contents are initially in untrusted memory Copied into the EPC in 4KB pages Both data and code are copied before starting execution in enclave Cloud Computing — E. Rivière 50 Enclave construction Enclave content distributed in plaintext Can be inspected Must not contain any (plaintext) con dential data Secrets are provisioned after the enclave was constructed and its integrity veri ed Problem: what if someone tampers with the enclave? Remember that its content is initially in untrusted memory Cloud Computing — E. Rivière fi fi 51 Enclave construction Someone may tamper with the enclave by modifying the code int process_request(char *in, char *out) int process_request(char *in, char *out) { { copy_msg(in, input_buf); copy_msg(in, input_buf); if(verify_MAC(input_buf)) if(verify_MAC(input_buf)) { { decrypt_msg(input_buf); decrypt_msg(input_buf); process_msg(input_buf, output_buf); process_msg(input_buf, output_buf); encrypt_msg(output_buf); copy_msg(output_buf, external_buf); copy_msg(output_buf, out); encrypt_msg(output_buf); EEXIT(0); copy_msg(output_buf, out); } else EEXIT(0); EEXIT(-1); } else } EEXIT(-1); } Write unencrypted response to outside memory Cloud Computing — E. Rivière 52 Enclave construction CPU calculates enclave’s measurement hash during enclave construction Each new page extends the hash with the page content and attributes (read/write/execute) Hash computed with SHA-256 Measurement can then be used to attest the enclave to a local or remote entity Cloud Computing — E. Rivière 53 Enclave attestation Is my code running on remote machine intact? Is code really running inside an SGX enclave? Local attestation Prove enclave’s identity (=measurement) to another enclave on the same CPU Remote attestation Prove enclave’s identity to a remote party Once attested, an enclave can be trusted with secrets Cloud Computing — E. Rivière 54 Enclave construction DRAM CPU c0 94 7d bc 35 52 ba 9a 16 a6 63 0b 72 09 0d 0f 15 0b d0 2d ae 1a 55 f9 2f a8 20 98 EPC CPU calculates enclave’s measurement hash during enclave construction Different measurement if enclave is modified Cloud Computing — E. Rivière 55 Local attestation Prove identity of A to a local enclave B Enclave A Enclave B 1. Hi! I’m 5f904ba8910bff! Who are you? 0d 0f 15 0b d0 2d ae 5f 90 4b a8 91 0b ff 4. Here is my report Measurement (enclave A) 3. Here you go! 6. Here you go! 0d 0f 15 0b d0 2d ae 2. Please create a report for Measurement (enclave B) 5. Please give me my report 5f904ba8910bff verification key 5f 90 4b a8 91 0b ff CPU 1. Target enclave B measurement is required for key generation 2. Report contains information about target enclave B, including its measurement 3. CPU fills in the report and creates a MAC using the report key, which depends on random CPU fuses and the target enclave B measurement 4. Report sent back to target enclave B 5. Verify report by CPU to check that it was generated on the same platform, i.e., its MAC was created with the same report key (available only on the same CPU) 6. Check the MAC received with the report and do not trust A upon mismatch Cloud Computing — E. Rivière 56 Remote attestation Transform a local report to a remotely veri able “quote” Based on provisioning enclave (PE) and quoting enclave (QE) Architectural enclaves provided by Intel Execute locally on user platform Each SGX-enabled CPU has a unique key fused during manufacturing Intel maintains a database of these keys Cloud Computing — E. Rivière fi 57 Remote attestation PE communicates with Intel attestation service Proves it has a key installed by Intel Receives asymmetric attestation key QE performs local attestation for enclave QE veri es report and signs it using attestation key Creates a quote that can be veri ed outside platform The quote and signature are sent to the remote attester, which communicates with Intel attestation service to verify quote validity Cloud Computing — E. Rivière fi fi 58 SGX paging SGX provides a mechanism to evict an EPC page to unprotected memory EPC is limited in size (v1: 128 GB, more in recent versions) Paging performed by the OS Validated by the HW to prevent attacks on address translations Metadata (MAC, version) kept within EPC Accessing evicted page results in page fault The page is brought back into the EPC by the OS Hardware veri es integrity of the page Another page might be evicted if the EPC is full Cloud Computing — E. Rivière fi 59 SGX limitations Amount of memory the enclave can use needs to be known in advance Security is not perfect Vulnerabilities within the enclave can still be exploited Side-channel attacks and hardware attacks still possible (active research eld!) Performance bottlenecks Enclave entry/exit is costly Paging is very expensive Application partitioning? Legacy code? … Cloud Computing — E. Rivière fi 60 Conclusion Security of applications in the Cloud require Using good practices as for in-premises IT Together with new techniques for Cloud-speci c attacks Colocation and increased trusted code based More attack opportunities Must trust Cloud provider and large code base Store only encrypted data in the Cloud: yes but… … encrypted processing OK in some applications, too costly in others — security balance with expressiveness Trusted Execution Environment = HW support for reducing trusted code base to application enclaves Cloud Computing — E. Rivière fi 61 References (1/2) Luis Miguel Vaquero, Luis Rodero-Merino, Daniel Morán: Locking the sky: a survey on IaaS cloud security. Computing 91(1): 93-118 (2011) Luis Rodero-Merino, Luis Miguel Vaquero, Eddy Caron, Adrian Muresan, Frédéric Desprez: Building safe PaaS clouds: A survey on security in multitenant software platforms. Computers & Security 31(1): 96-108 (2012) Claudio Agostino Ardagna, Rasool Asal, Ernesto Damiani, Quang Hieu Vu: From Security to Assurance in the Cloud: A Survey. ACM Comput. Surv. 48(1): 2:1-2:50 (2015) Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono: All your clouds are belong to us: security analysis of cloud management interfaces. CCSW 2011: 3-14 Craig Gentry: Computing arbitrary functions of encrypted data. Commun. ACM 53(3): 97-105 (2010) Michael Naehrig, Kristin E. Lauter, Vinod Vaikuntanathan: Can homomorphic encryption be practical? CCSW 2011: 113-124 Shai Halevi, Victor Shoup: Algorithms in HElib. CRYPTO (1) 2014: 554-571 Cloud Computing — E. Rivière 62 References (2/2) Raluca A. Popa, Catherine M. S. Red eld, Nickolai Zeldovich, Hari Balakrishnan: CryptDB: protecting con dentiality with encrypted query processing. SOSP 2011: 85-100 Sunoh Choi, Gabriel Ghinita, Elisa Bertino: A Privacy-Enhancing Content-Based Publish Subscribe System Using Scalar Product Preserving Transformations. DEXA (1) 2010: 368-384 Wong, W.K., Cheung, D.W., Kao, B., Mamoulis, N.: Secure kNN Computation on Encrypted Databases. In: ACM SIGMOD International Conference on Management of Data, pp. 139 152 (2009) Emanuel Onica, Pascal Felber, Hugues Mercier, Etienne Rivière: Con dentiality-Preserving Publish/Subscribe: A Survey. ACM Comput. Surv. 49(2): 27:1-27:43 (2016) Emanuel Onica, Pascal Felber, Hugues Mercier, Etienne Rivière: Ef cient Key Updates through Subscription Re-encryption for Privacy-Preserving Publish/Subscribe. Middleware 2015: 25-36 Cloud Computing — E. Rivière fi fi fi fi 63 SGX primer Writing your rst SGX application… Cloud Computing — E. Rivière fi 64 1. De ne interface Enclave definition language: myenclave.edl enclave { untrusted{ void ocall_error([in,string] const char *msg); }; trusted { public int ecall_compute( int a, int b); }; }; Untrusted Trusted sgx_edger8r myenclave_u.h myenclave_t.h myenclave_u.c myenclave_t.c Cloud Computing — E. Rivière fi 65 2. Write code Application: application.c Enclave: myenclave.c #include #include #include int ecall_compute( int a, int b ) { void ocall_error( const char *msg ) { int res = a + b; printf( msg ); // syscall if( res < 0 ) } ocall_error("SGX says: I do not like " "negative results\n"); int main() { return res; sgx_enclave_id_t eid = 0; } // initalize enclave int ret; ecall_compute(eid, &ret, 4, -5); printf("Result: %d\n", ret); // destroy enclave return 0; } Cloud Computing — E. Rivière 66 3. Compile code Untrusted Trusted myenclave_u.c myenclave_t.c application.c myenclave.c -nostdinc -fno-builtin-printf gcc/g++ -nostdlib -nodefaultlibs -nostartfiles (...) a.out myenclave.so Cloud Computing — E. Rivière 67 4. Sign code and run Trusted myenclave.so private_key.pem sgx_sign myenclave.signed.so $ ls a.out myenclave.signed.so $./a.out SGX says: I do not like negative results Result: -1 Cloud Computing — E. Rivière