CPU as the New Perimeter AiAttestation and Memory EEincryption Protect SSiiensitive Data in the Cloud

Oded Horovitz Co‐Founder & CEO PrivateCore Inc the private computing company Computation

Input Processing Internal State 10010010101 10010010101 Output f(x) = y 01001001001 00100100010 10010010101 Processing composition

Input Processing Internal State 10010010101 10010010101 Output f(x) = y 01001001001 00100100010 10010010101

Composed of:

Hardware Software Policy

Mutable Internal Storage hierarchy

Input Processing Internal State 10010010101 10010010101 Output f(x) = y 01001001001 00100100010 10010010101

Storage Hierarchy

CPU HDD Flash RAM Registers Cache

Persistent Hacking, exploits existing vulnerabilities

Input Processing Internal State 10110101101 10010010101 Output f(x) = y 01001001001 00100100010 10010010101 Physical attack, walking with the data

Input Processing Internal State 10010010101 10010010101 Out of f(x) = y 01001001001 Output bound 00100100010 10010010101 Lets add Operations

User I/O Processing

10010010101 f(x) = y Internal State

Developers 10010010101 01001001001 f‐upgrade(x) New code 00100100010 IT f‐config(x) Settings Admin hack ‐ self provision access

User I/O Processing

10010010101 f(x) = y Internal State

Developers 10010010101 01001001001 f‐upgrade(x) New code 00100100010 IT f‐config(x) Settings Developer hack – Introducing backdoors

User I/O Processing

10010010101 f(x) = y Internal State f‐backdoor(x) Developers 10010010101 01001001001 f‐upgrade(x) Backdoor 00100100010 IT f‐config(x) Settings Add risk of public communications

Processing Internal State User I/O 10010010101 10010010101 Internet f(x) = y 01001001001 00100100010

1001 0010 Also, real systems show complex composition

App App App App

Guest Guest OS OS Up the stack! VM VM

Host OS

Physical server Still, real systems show complex composition

Host OS

CPU RAM Down the stack!

I/O PCIe

TPM NIC HDD Sample attacks at the IaaS level

Integrity attacks SMM infection HDD firmware infection injected kernel arguments

Physical attacks Grabbing clear private SSH keys Cold‐boot

Logical access attacks Inception DMA capture of mysql records Malicious device I/O SMM Infection, execution integrity forever lost HDD firmware infection, WYSINWYG Injected kernel argument & SSH key grab

http://youtu. be/6C0b3nMXeGU Cold‐boot attack, grabbing memory

httpp//://youtu.be//q5SKq9o0Lu yo Inception rewriting your memory

http://youtu. be/wki66w1iJHA DMA IaaS (Inception‐as‐a‐Service)

http://youtu.be/AI‐XbzKO7HM Malicious device I/O

OS Developers are not writing defensive device drivers…

In response for our submitted drivers vulnerabilities: "These are lengths written by hardware, so will only be wrong if the hardware is broken. If the hardware is broken (or replaced by something malicious) then it can do anything it likes. Invalid values in ring entries are the least of your worries." So how do we protect against such attacks? IT Security Job I: Prevent physical grab

User I/O Processing

10010010101 f(x) = y Internal State

Developers 10010010101 01001001001 f‐upgrade(x) New code 00100100010 IT f‐config(x) Settings

Physical security control IT Security Job II: Check system integrity & lockdown

Processing

User 10010010101 Internal State f(x) = y 10010010101 Dev New code f‐upgrade(x) 01001001001 00100100010 f‐config(x) IT Settings

Hardware Software Policy

OK OK OK IT Security Job III: Secure logical access

Processing

User 10010010101 Internal State f(x) = y Control 10010010101 ty Dev New code ii f‐upgrade(x) 01001001001 00100100010 Secur f‐config(x) IT Settings ical gg Lo IT Security Job IV: Encrypt public I/O

Processing Internal State User I/O 10010010101 10010010101 Internet f(x) = y 01001001001 00100100010

%$F2 Physical security control Y&5u So how do we protect against such attacks?

Integrity attacks SMM infection Hardware Software Policy HDD firmware infection OK OK OK injected kernel arguments

Physical attacks 100100 %$F2 Grabbing clear private SSH keys 100110 Y&5u Cold‐boot 110010

Physical security control Encrypt elsewhere Logical access attacks Inception DMA capture of mysql records Logical Security Control (IO‐MMU) Malicious device I/O The Cloud Challenge

SaaS How can a tenant verify integrity? App Who defines an “OK” stack?

What’s a good physical perimeter? VM The data‐center? Cage? IaaS Server? KVM CPU?

Host OS ( depends on the above question)

Bare‐Metal‐aaS Should IaaS CSPs take more Server responsibility? Or give more control to customer? Our mantra for secure IaaS (in world)

SaaS 1. Enable TPM & TXT App 2. Choose a policy for hypervisor (i.e. “below the VM”) secure configuration. Tip: Consider stateless hypervisors. VM 3. Verify than trust. Give no secrets to unverified systems IaaS KVM 4. Decide on physical perimeter Best – CPU Good –The server Host OS Risky –Data‐center Bare‐Metal‐aaS 5. Encrypt outside your chosen perimeter! Server (storage & network) PrivateCore vCage Host

The CPU as the perimeter of computation PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself • Loading stateless image into CPU cache

vCage Host PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself • Loading stateless image into CPU cache • Test system integrity via TXT

vCage Host OK PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself • Loading stateless image into CPU cache • Test system integrity via Intel TXT • Provision secrets (keys) vCage 100100 Host 100110 110010 OK PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself • Loading stateless image into CPU cache • Test system integrity via Intel TXT • Provision secrets (keys) • Add logical security vCage – DMA protection 100100 Host 100110 – Filter device IO 110010 OK

LilLogical SitSecurity CtlControl PrivateCore vCage Host

The CPU as the perimeter of computation

• Physical security is the CPU package itself • Loading stateless image into CPU cache • Test system integrity via Intel TXT • Provision secrets (keys) • Add logical security vCage – DMA protection 100100 Host 100110 – Filter device IO 110010 OK • Encrypt anything outside the CPU LilLogical SitSecurity CtlControl %$F2 Y&5u PiPriva te Core Pinned Encrypted

CARMA Pinned Disabled

Frozen Cache No‐fill Exposed Encrypted

Tresor Exposed Encrypted

Cryptkeeper Encrypt

Status quo Encrypted

Registers CPU Cache RAM DISK A reasonable performance tradeoff

The CPU & DRAM as the perimeter of computation

• Encrypt anything outside the CPU & DRAM • Cons: Vulnerable to “cold‐boot”, vCage “malicious DIMM” & bus analysis 100100 Host 100110 • Pro: High integrity without the 110010 OK performance penalties • Ideal for public cloud environments Logical Security Control

%$F2 Y&5u Biggest challenges

• Squeeze the Linux kernel into < 10MB while – Keeping all virtualization features – KiKeeping it sttblable (No OOM allowe d)

• Keep CPU cache under our control

• Performance work – Squeeze different data structure to reduce working set – Identify new hot‐paths in the kernel – Utilize AESNI capabilities What’s coming?

Offensive

Deeper down the stack we go! Sniffing and MITM any bus facedancer – USB hacking in python! 55$

Defensive

Intel SGX –A huge step toward CPU as physical perimeter More Open Source software & hardware Q & A

Oddded Horovitz [email protected]