Shielding applications from an untrusted cloud...•We assume a malicious cloud provider...

Haven

Andrew Baumann Marcus Peinado Galen Hunt

Microsoft Research

Shielding applicationsfrom an untrusted cloud

Application

Operating system

In the old days…

2

Application

Operating system

In the old days…

2

Application

Operating system

In the old days…

2

Trust…?

In the cloud

Cloud platform

3

Application

Operating system

Trust…?

In the cloud

Cloud platform

3

Application

Operating system

Trust…?

In the cloud

Cloud platform

3

Application

Operating system

Trust…?

In the cloud

Cloud platform

3

Application

Operating system

Our goals for Haven

Secure, private execution

of unmodified applications

(bugs and all)

in an untrusted cloud

on commodity hardware

(Intel SGX)

4

Can you trust the cloud?

• Huge trusted computing base• Privileged software

Hypervisor, firmware, ...

• Management stack

• Staff Sysadmins, cleaners, security, …

• Law enforcement

• Hierarchical security model• Observe or modify any data

• Even if encrypted on disk / net

Application

Hypervisor

Operating system

Firmware/bootloader

…People

Management tools

Tru

st

5

Current approaches

6

Hardware Security Modules

• Dedicated crypto hardware• Expensive

• Limited set of APIs• Key storage

• Crypto operations

• Protects the “crown jewels”, not general-purpose

7

Trusted hypervisors

• Use a small, secure, hypervisor

• Ensures basic security, such as strong isolation

Problem #1: system administrators

Problem #2: physical attacks (e.g. memory snooping)

Problem #3: tampering with hypervisor✓

8

Remote attestation

• Trusted hardware: TPM chip

• Basic idea:• Signed measurement (hash) of privileged software

• Remote user checks measurement

• Incorrect attestation → compromised software

• Problem: what is the expected measurement?• Cloud provider applies patches and updates

• Must trust provider for current hash value

9

What do we really want?

10

Secure colo provides:• Power and cooling• Network access

11

Secure colo provides:• Power and cooling• Network access

Raw resources

Untrusted I/O

11

Shielded execution

• Protection of specific program from rest of system• cf. protection, isolation, sandboxing, etc.

• New term (older concept)

• Program unmodified, naïve to threats

• Confidentiality and integrity of:• The program

• Its intermediate state, control flow, etc.

→ Input and output may be encrypted

• Host may deny service, cannot alter behaviour

12

Threat model

• We assume a malicious cloud provider• Convenient proxy for real threats

• All the provider’s software is malicious• Hypervisor, firmware, management stack, etc.

• All hardware besides the CPU is untrusted• DMA attacks, DRAM snooping, cold boot

• We do not prevent:• Denial-of-service (don’t pay!)• Side-channel attacks

13

Intel SGX

Application (untrusted)

Enclave

Operating system (untrusted)

14

Intel SGX

• Hardware isolation for an enclave• New instructions to

establish, protect

• Call gate to enter

• Remote attestation Application (untrusted)

Enclave

Secret Data

EnclaveEntry:mov fs:[Tcs],rbxmov fs:[CSSA],eaxcmp eax, 0jne ExceptionEntrymov r10,fs:[ResAdr]cmp r10,0je @Fjmp r10

@@:mov rcx, r8mov rdx, r9mov r8, rbx

Operating system (untrusted)

14

EnclaveRAM

Physical memory

SGX at the hardware levelVirtual address space

EPC

Encrypted &integrity-protected

Page table mappingschecked

Code/data

15

EnclaveRAM

Physical memory

SGX at the hardware levelVirtual address space

EPC

Encrypted &integrity-protected

Page table mappingschecked

Code/data

Also:• Protected register file• Secure control transfer

15

Enclave

Operating system

Design challenge: Iago attacks

Application System calls

16

Iago attacks

• malloc() returns pointer to user’s stack

• Scheduler allows two threads to race in a mutex

• System has 379,283 cores and -42MB of RAM

• read() fails with EROFS

• …

Our approach:• Don’t try to check them all

• Admit OS into trusted computing base

17

Picoprocess (protects host from guest)

Untrusted interface

Enclave (protects guest from host)

Windows 8 API

Drawbridge ABI

Drawbridge ABI & SGX priv ops

Windows kernel

Untrusted runtime

Application

Shield module

Drawbridge host SGX driver Mu

tual

d

istr

ust• Shields LibOS from Iago attacks

• Includes typical kernel functionality

• Scheduling, VM, file system

• Untrusted interface with host

Haven

• Unmodified binaries

Library OS (Drawbridge)

• Subset of Windows, enlightened to run in-process

18

Untrusted interface

• Host/guest mutual distrust

• Policy/mechanism with a twist• Virtual resource policy in guest

Virtual address allocation, threads

• Physical resource policy in hostPhysical pages, VCPUs

• ~20 calls, restricted semantics

Picoprocess

Untrusted interface

Enclave

Windows 8 API

Drawbridge ABI

Drawbridge ABI & SGX priv ops

Untrusted runtime

Application

Library OS

Shield module

Windows kernel

Drawbridge host SGX driver

19

Picoprocess

Shield module

• Memory allocator, region manager• Host commits/protects specific pages• No address allocation

• Private file system• Encrypted, integrity-protected VHD

• SchedulerDon’t trust host to schedule threads

• Exception handler• Emulation of some instructions

• Sanity-check of untrusted inputs• Anything wrong → panic!

• 23 KLoC (half in file system)

Untrusted interface

Enclave

Windows 8 API

Drawbridge ABI

Drawbridge ABI & SGX priv ops

Untrusted runtime

Application

Library OS

Windows kernel

Drawbridge host SGX driver

Shield module

20

1. Dynamic memory allocation and protection• New instructions needed

2. Exception handling• SGX doesn’t report page faults or GPFs to the enclave

3. Permitted instructions

• RDTSC/RDTSCP needed, for practicality and performance

1. Thread-local storage• Can’t reliably switch FS and GS

SGX limitations

21

1. Dynamic memory allocation and protection• New instructions needed

2. Exception handling• SGX doesn’t report page faults or GPFs to the enclave

3. Permitted instructions

• RDTSC/RDTSCP needed, for practicality and performance

1. Thread-local storage• Can’t reliably switch FS and GS

Good news!These are fixed in SGX v2

SGX limitations

21

Performance evaluation

• Implemented and tested using SGX emulator• Thanks, Intel!

• Problem: no SGX implementation yet

• Solution: model for SGX performance

1. TLB flush on Enclave crossings2. Variable spin-delay for critical SGX instructions

• Enclave crossings• Dynamic memory allocation, protection

1.Penalty for access to encrypted memory• Slow overall system DRAM clock

22

Performance summary

• Depends on model parameters, details in paper

• 35% (Apache) – 65% (SQL Server) slowdown vs. VM• Assumes 10k+ cycles SGX instructions, 30% slower RAM

• … and you don’t have to trust the cloud!

23

What’s next?

• Rollback of persistent storage• Requires more hardware or communication

• Untrusted time• Network time sync, RDTSC

• Cloud management• Suspend / resume / migrate applications

• Encrypted VLANs

24

Conclusion

• Closer to a true “utility computing” model• Utility provides raw resources

• Doesn’t care what you do with them

• Why trust the cloud when you don’t have to?

Thanks!baumann@microsoft.com

25