Cache Attacks on the Cloud Thomas Eisenbarth Joint work with Gorka Irazoqui, Mehmet Sinan Inci, Berk Gulmezoglu and Berk Sunar Real World Cryptography 1/8/2016
Outline • Cloud Computing and Isolation • Extracting Information from Co-located VM • Attacking Crypto across VM Boundaries • RSA Key Recovery in a Public Cloud 2
Cloud Computing • Computation increasingly outsourced to cloud servers • CSPs: many users on shared, homogeneous platforms • Users rent VMs, share same computer • Shared resources Information Leakage? 3
Security through Isolation • Virtual machines: Abstraction of physical machine • Hypervisor (VMM) ensures Isolation through virtualization • VMs might feel each other’s load on some low -level resources potential side channels Guest OS #2 Spy Guest OS #1 Victim VM VM VMM Hardware 4
Outline • Cloud Computing and Isolation • Extracting Information from Co-located VM • Attacking Crypto across VM Boundaries • RSA Key Recovery in a Public Cloud 5
Cross-VM Side Channel Attack Suitable covert channel in the cloud? – Cross Core: Last Level Cache (L3 Cache) accesses Adversary and victim share full access to L3 cache Cache Access cannot be virtualized (70x slowdown) 6
Cache Attacks? • Cache attacks are old [Hu92] • General technique: Prime+Probe [OST06]: 1. Prime desired memory lines fill monitored cache lines with data making an eviction set 2. Wait for some time 3. Probe memory lines read eviction set data and time read • Problems: – Usually only applied on L1-Cache (64kB) not cross-core – L3-Cache is too large (25MB!) not controlled by spy – Solution : Huge Pages give spy control over L3$ [Hu92] Hu, W.-M. (Digital Equipment Corp., Littleton, MA, USA) Lattice scheduling and covert channels. IEEE Oakland 92 7 OST06] DA Osvik, A Shamir, E Tromer Cache attacks and countermeasures: the case of AES . CT-RSA 2006
Outline • Cloud Computing and Isolation • Extracting Information from Co-located VM • Attacking Crypto across VM Boundaries • RSA Key Recovery in a Public Cloud 8
Prime+Probe Attack: Concept Steps: ( Preparation: Find eviction set) 1. Prime desired memory lines 2. Wait for some time 3. Probe memory lines and measure reload time. Victim Spy Private L1/L2 CACHE Slow reload time Fast reload time Clean detection if monitored cache set was accessed Shared L3 CACHE Memory 9
How to get crypto keys? Detect key-dependent cache accesses: • RSA/ElGamal: 250 Decryption First Secret Second Secret Exponent (dp) Start Exponent (dq) 200 – Sliding window exponentiation 150 Reload time 100 – Occurrence of multiplicands in 50 0 cache reveals key bits 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 timeslot • AES: – T-table implementation: Xors and table lookups – Detect t-table access in last round (table entry corresponding to 𝑑 𝑗 is always in LLC) [YF14] Y Yarom, KE Falkner Flush+ Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack, USENIX Security 2014 10 [IIES14] Irazoqui, G., Inci, M. S., Eisenbarth, T., & Sunar, B. Wait a minute! A fast, Cross-VM attack on AES . RAID 2014
Are Cross-VM Cache Attacks Realistic? Cross-VM Cache Attacks on El Gamal [LY+15] and on AES [IES15] work if • Server has a shared level of cache • Attacker and the victim are physically co- located • VMM implements memory deduplication [LY+15] Liu, F., Yarom, Y., Ge, Q., Heiser, G., & Lee, R. B. (2015). Last-Level Cache Side-Channel Attacks are Practical . (S&P 2015). [IES15] Irazoqui, G., Eisenbarth, T., & Sunar, B. S$A: A shared cache attack that works across cores and defies VM sandboxing — and 11 Its application to AES . 36th IEEE Symposium on Security and Privacy (S&P 2015)
Outline • Cloud Computing and Isolation • Extracting Information from Co-located VM • Attacking Crypto across VM Boundaries • RSA Key Recovery in a Public Cloud 12
Co-location First success in 2009 [RTS09]: 1. Launch many instances on cloud * In Sept 2008 2. Check if any are co-located • How to detect Co-location? – Ping time? – IP address of instance or hypervisor? – Disk Load? [RTSS09] Ristenpart, T., Tromer, E., Shacham, H., and Savage, S. Hey, You, Get off of My Cloud: Exploring Information Leakage in Third- 13 party Compute Clouds. ACM CCS '09
Test Setup • AWS EC2 m2.medium instances: – Intel Xeon E5 2670 v2 CPU @2.5 GHz – 10 cores share 25 MB of L3 cache – Modified (Hardened) Xen VMM – Up to 10 co-located instances (VMs) • 4 accounts w/ 20 instances (no within-acc colocation) • Ping is constant time • HDDs replaced with SSDs • Dom0 IPs hidden New Co-location detection needed 14
Co-Location Attempt: LLC Cache Accesses + Works reliable and we know how to do it + Difficult to block - Requires slice recovery - Noise? Friday Monday Tuesday Average • Gives Reliable Co-location Detection LLC Noise • Ensures that cache attack will work Alternative: Memory bus contention [XWW15,VZRS15] 00:00 02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 00:00 [XWW15] XU, Z., WANG, H., AND WU, Z. A measurement study on co-residence threat inside the cloud . USENIX Security 15 Hour of Day (EST) 15 [VZRS15] VARADARAJAN, V., ZHANG, Y., RISTENPART, T., AND SWIFT, M. A placement vulnerability study in multi-tenant public clouds . USENIX Security 15
Target Cryptosystem • Libgcrypt 1.6.2 ‘s RSA implementation – RSA CRT with 2048 bit modulus size – Sliding window exponentiation (5 bits) – Message blinding to prevent chosen ciphertext attacks Is this state-of-the-art? • Libgcrypt 1.6.3 (February 2015) – Table accesses now constant execution flow (no more cache games) 16
Attack on RSA-CRT Sliding Window 1. Find cache trace of sliding window multiplicands 2. Observe several exponentiations to reduce noise 3. Align and filter observations to reduce noise 4. Run error correcting key recovery to fix remaining noise errors 17
Identifying a Correct Cache Line 250 200 Reload time • 10x2048 cache lines 150 100 • Source code reveals 50 0 approximate 0 2000 4000 6000 8000 10000 250 timeslot position 200 Reload time 150 • Search through 100 50 remaining choices 0 0 2000 4000 6000 8000 10000 250 timeslot • Once found, repeat First Secret Decryption Second Secret Start Exponent (dp) Exponent (dq) 200 observations 150 Reload time 100 50 0 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 18 11000 timeslot
Processing Noisy Observations 12 11 10 10 9 8 8 7 6 6 5 4 4 3 2 2 1 0 0 1000 2000 3000 4000 5000 6000 0 500 1000 1500 2000 2500 3000 timeslot Accesses to specific cache line during subsequent encryptions 1. Alignment to remove temporal shifts 2. Remove noise artifacts 19
After Processing and Alignment • Correct (red) vs recovered (blue): little remaining noise 20
Final key recovery? • Distance to table initialization reveals multiplicand value • 𝑒 must be recovered from noisy 𝑒 𝑞 and 𝑒 𝑟 More details in: ia.cr/2015/898 21
Conclusions • Cache Attacks in public clouds work – Noise and co-location need to be tackled • Fully patched crypto libraries (at least major open source ones) are no longer vulnerable • Countermeasures are still open problem: Many proposed, but cost overhead prohibitive? • How about non-crypto code? 22
Thank you! vernam.wpi.edu teisenbarth@wpi.edu
Cross Processor Cache Attacks? • Interprocessor Communication: Cache Coherence Protocols use fast direct links between processors: • Faster than memory access Timing behavior [IES15] G Irazoqui and T Eisenbarth and B Sunar Cross Processor Cache Attacks ia.cr/2015/1155 24
Recommend
More recommend