Cloud Computing Security Quiz

Cloud Computing - Lesson 9 : Security

Course Information

• Course Title: Cloud Computing
• Course Code: LINFO2145
• Lesson: 9 - Cloud Security
• Instructor: Pr. Etienne Rivière
• Contact: [email protected]

Announcements

• Quiz 3: Lectures 5 and 6, results available after this lecture
• Quiz 4: Lectures 7 and 8, available after this lecture, Due: Nov 27, 10:45
• Reviews: Dec 4, 10:45

Lecture Objectives

• Introduce security concerns from cloud computing
• Overview of data and computation integrity protection in cloud
• Describe new approaches for confidential data processing in the cloud

Introduction (1)

• Cloud computing platforms and applications are tempting attack targets
• Large amounts of data are stored centrally
• Sensitive data is often publicly available, making it an attractive target for malicious activity
• Limited control of software stacks, particularly in PaaS.
• Multi-tenancy creates larger attack surfaces
• Co-location of resources creates new attack opportunities.
• Single point of failure within one service can affect other services

Introduction (2)

• High trust required of cloud providers
• Cloud providers need to comply with local privacy regulations (e.g. PATRIOT Act)
• Security concerns are specific to cloud systems
• Application-level and OS-level security practices remain important

Why is Cloud Security Important?

• Major breaches like the Yahoo (1 billion accounts) and Dropbox (68 million) hacks, and the 2012 LinkedIn breach highlight the need for robust cloud security

The Provider Perspective

• Cloud providers must protect their customers from malicious actors
• Hypervisor-based isolation provides a limited security guarantee
• One-way protection: the provider does not protect the customer from the provider

The Client Perspective

• Cloud tenants must trust their providers, including personnel and software components
• Ideally, clients would only trust their portion of the service

Multi-tenancy and Security

• Resource sharing in virtualization creates new security threats
• Hypervisors and VMs are vulnerable to attacks impacting all tenants
• Access to the hypervisor gives access to all VM memory, including the kernel and page tables.
• Dedicated security experts and best practices are important.

Protected Mode Not Sufficient

• Protected mode (rings) is insufficient to prevent exploits
• Malicious applications can exploit flaws, gaining full privileges and potentially compromising the operating system or other applications
• Attack surface includes the entire software stack, comprising applications, OS, VMM, drivers, and BIOS

Example of Protection Rings in Microsoft Hypervisor

• Depicts layers of isolation for different components within a hypervisor
• Emphasizes the separation of different parts of the hypervisor

Attacking the Cloud

• Attacks are performed by executing software on the victim's computer, including remote execution
• Most attacks exploit vulnerabilities in software components, including exploitable memory safety vulnerabilities in C/C++
• Malicious APIs target services and infrastructure management interfaces
• Hardware vulnerabilities like Spectre and Meltdown, and RowHammer attacks are also possible

The Software Stack

• Cloud platforms utilize enormous amounts of code that must be trusted
• Examples of codebases include Linux, KVM, and OpenStack

Bugs are a Reality

• More code generally means more bugs
• Exploited vulnerabilities can lead to complete disclosure of sensitive data
• Xen hypervisor and Linux kernel have a significant number of reported vulnerabilities (e.g., 184 for Xen, 721 for Linux kernel in a given time period)

Examples of Software Attacks

• Control-flow hijacking: Goal is to execute arbitary code.
• Code injection attacks: Overwriting addresses to inject code
• Return-oriented programming: Stack corruption to execute existing instructions

Example: Heartbleed Bug

• Serious vulnerability in OpenSSL
• Widely used; targets web servers, email, chat, and VPNs
• Buffer overrun in heartbeat message handling resulting in exposure of memory
• Exploited to read server memory, including sensitive data like passwords, private keys, etc.

Other Examples

• "All your clouds are belong to us" (2011): attacks targeting EC2 management APIs
• Colocation attacks: targeting VMs on public clouds
• Attacks at hypervisor, OS and CPU level
• Exploit bugs to gain access to cached content from VMs, perform bus sniffing, obtain memory communication or perform cold boot attacks.

Hardware Attacks in the Cloud

• Hardware based attacks may or may not require direct physical access to the host
• With physical access, attacks include bus sniffing, and obtaining memory communication in DRAM
• Cold boot attacks obtain memory values during power cycles using short-lived memory state

Remote Hardware Attacks: "Row Hammer"

• Attacking physical memory to flip bits in neighboring memory
• Can cause sandbox escapes and corrupted page tables

Goals: Security in the Cloud

• Confidentiality: Protecting data from unauthorized access.
• Integrity: Protecting data from unauthorized modification

Tools: Cryptographic Hash Function

• Algorithm mapping arbitrary inputs into fixed-size outputs
• Infeasible inversion. Collision resistant
• More computationally intensive compared to generic hashes

Tools: Symmetric Cryptography

• Shared secret key for encryption and decryption
• Example: Advanced Encryption Standard (AES)

Tools: Symmetric Cryptography - MAC

• Message authentication code (MAC)
• Integrity and authenticity checking of messages
• Key required to produce a MAC
• Does not offer confidentiality

Tools: Asymmetric Cryptography

• Each party has a public and private key pair
• Public key used for encryption; private key for decryption
• Example: Rivest-Shamir-Adleman (RSA)

Tools: Asymmetric Cryptography - MAC (Digital Signature)

• Digital signature in asymmetric cryptography
• Signed using the sender's private key, verified with public key
• Ensures message integrity and authenticity

Ensuring Data Confidentiality

• Data-at-rest protection: Encrypting data directly on disk (e.g., full-disk encryption and encrypted file systems)
• Data-in-flight protection: Using end-to-end encryption mechanisms like TLS

Ensuring Data Confidentiality - TPM (Trusted Platform Module)

• Hardware security chip
• Generates and stores cryptographic keys
• Provides remote attestation

Ensuring Data Confidentiality – In-use Data

• Decrypting data before processing to maintain confidentiality in-use
• Confidentiality required during computations in the cloud

Securing Data During Computation

• Searchable data while protecting against security attacks on data distribution
• Privacy-utility-performance tradeoff consideration when applying security measures

Tools

• Software-Level Encryption
• Specific and generic encryption mechanisms
• Hardware support for trusted computing
• Homomorphic encryption

Encrypted Data Processing - Homomorphic Encryption

• Allows computation on encrypted data without decryption
• Enables operations like addition and multiplication on encrypted data; maintains confidentiality throughout computation.
• Example: Fully homomorphic encryption

Homomorphic Encryption - HELib

• Open-source homomorphic encryption library developed by IBM
• Designed to make homomorphic encryption more practical
• Low-level routines (addition, multiplication, etc.)
• Performance improvements but still requires significant resources, far from being practical in terms of computation time

Specific Encryption Schemes

• Homomorphic encryption (generic but costly)
• Specific schemes for targeted operations (e.g., exact match, nearest match, range, equality)
• Example: CryptDB (encrypted SQL database)

CryptDB: Encrypted SQL Database

• Proxy between the client and the database to handle query rewrites and data encryption/decryption.
• Prevents exposure of sensitive data to the untrusted zone of the cloud environment (especially in servers or proxy)
• Provides standard encryption (AES) but prevents from arbitrary query execution in non-trusted environment

CryptDB: Encryption Levels (1)

• Random encryption (e.g., AES): No data query possible
• Deterministic encryption (e.g., Pseudorandom permutation): Equality searches possible but maintains ciphertext integrity
• Order-preserving encryption: Enables range queries

CryptDB Encryption Levels (2)

• Summation homomorphic: Enables summation operations on encrypted data
• Joins: Enables joins across encrypted data; encryption key may be different
• Word Search: Limited full-word functionality but vulnerable with known frequency attacks

Onion Layers Encryption

• Multi-level encryption layer structure
• Security and privacy depend on how a specific level of encryption can be handled and how many levels of encryption an application requires

CryptDB Performance

• Performance of CryptDB can vary depending on the workload and number of cores
• Performance can be slower by an order of magnitude compared to non-encrypted databases due to the increased processing tasks from encryption/decryption
• Additional proxy server cost

Towards Hardware Support

• Software-based confidentiality or data protections have limited applicability and performance limitations
• The trusted computing base traditionally encompasses hardware and software stack, but there is a need to reduce this trusted code base to allow application enclaves

Intel SGX

• "Software Guard Extensions" in Intel CPUs (e.g. Skylake, Kaby Lake)
• Provides hardware-level protection for code and data in untrusted environments
• Platform owner considered malicious
• Only the CPU chip and isolated enclave are considered trusted

Enclaves

• Isolated memory regions (enclaves) for code and data
• Enclave content is protected by the hardware (Memory Encryption Engine [MEE])
• Plaintext secrets are prevented from being directly stored in main memory
• Enclave memory accessible only by enclave code, protecting against privilege escalation attacks

Enclave Memory

• Enclave memory is not accessible to other software
• Enclaves can access memory within the process
• Application can protect its secrets, reducing attack surface

Enclave Memory APIs

• ECALLs are enclave interface functions, providing input to the enclave
• OCALLs are enclave calls for returning results outside of the enclave

SGX Execution Model

• Trusted execution environment within a process, with dedicated code and data
• Controlled entry points
• Confidentiality and integrity provisioned
• Multiple threads support
• Full access to application memory

Enclave Page Cache (EPC)

• Physical memory region protected by the MEE
• EPC holds enclave contents
• Shared resource for all enclaves on the platform
• Content encryption in DRAM; decryption when brought to CPU
• Larger EPC sizes available in newer versions

SGX Limitations

• Memory limit for enclaves
• Security not absolute (vulnerabilities may exist)
• Performance is generally impacted compared to other approaches (enclave entry/exit, paging are costly)
• Legacy code, and application partitioning considerations

Conclusion

• Cloud security requires both general security practices and new techniques specific to cloud architectures (e.g., attacks on colocated and trusted code)
• Encryption of data in the cloud is beneficial
• Trusted Execution Environments (HW support) offer a way to reduce the trusted code base and trust only the required application enclaves

References (1/2) and (2/2)

• Includes a large list of academic papers which are relevant to cloud security practices

SGX Primer

• Introduction to writing SGX applications

1. Define Interface

• Enclave definition language (myenclave.edl) for function declarations
• untrusted and trusted sections for separating function declarations

2. Write Code

• Application (application.c) code and enclave (myenclave.c) code example (including main() and compute()) functions
• Demonstrate the sgx_initialize_enclave and ecall_compute calls

3. Compile Code

• Compilation of application.c, myenclave.c to generate myenclave.so and a.out
• gcc, different compiler flags

4. Sign Code and Run

• Signing myenclave.so using SGX specific tool (sgx_sign, private_key.pem)
• Execution and results from the application