cache attacks on secret key cryptosystems
TRANSCRIPT
Cache Attacks on Secret Key Cryptosystems
Rajesh Ravi
Lawrence Awuah
Agenda
• Introduction
• Background
• Investigation
• Results
• Mitigation
• Future Work
• Conclusion
Introduction
• Side Channel Cryptanalysis– Definition: Any attack on a cryptosystem using information
leaked given off as a byproduct of the physical implementation of the cryptosystem, rather than a theoretical weakness.
• Exploitable Side Channels– Power usage
– Cache accesses
– Noise
– Heat
– Time
Background
AES Overview
•Based on finite mathematics
•Widely analyzed and considered secure
•Used for US Government Top Secret data
•Supports 128, 196, and 256 bit keys
•Expected to be the standard for 20+ years
AES
• AES encrypts 16 byte data n, using a 16 byte key k using Sbox tables S and S’, each of 256 bytes.
• These tables are expanded in to four tables, each of 1024 byte
AES
• AES works with two 16-byte auxiliary arrays, x and y
– First array initialized to k
– Second array to n xor k
• AES modifies x
– Let x be four byte arrays x1,x2,x3,x4
– Compute the four byte array
AES
• Replace x0,x1,x2,x3 with
• y0,y1,y2,y3 are given by
AES
• AES then modifies x again modulo 2, y again and then x again modulo 4 and so on.
• Ten rounds
• Finally y= AESk(n)
Cache
• Special type of computer memory operating at high speed
• Stores frequently accessed data
• Cache Miss :- If data is not found in the cache.
Bernstein’s Attack
• Conducted in 4 phases– Profiling : Known key at server, send plain
text and record timing information using different byte packet sizes of 400, 600, 800
– Attacking : Unknown key at server, repeat the same
– Correlation : Correlate the timing information
– Brute Force Search : Find all possible keys from the correlations
Sample correlations
16 0 d9 db d8 d0 d4 d1 df d3 de d5 d2 da d7 dc d6 dd
70 1 86 8d 85 82 81 8b 8e 88 89 8f 8a 87 83 8c 84 80
32 2 5f 5b 55 50 51 54 5e 57 5a 59 53 5d 5c 58 56 52 63..
240 3 87 86 8b 89 84 85 81 8a 80 83 8f 82 8e 8d 88 8c....
134 4 86 81 8b 8d 87 82 89 8c 83 85 8a 8f 88 80 8e 84...
32 5 88 8b 86 82 8c 81 8e 80 83 8a 8f 85 8d 87 89 84 f1..
16 6 37 3b 33 32 31 34 3e 38 30 36 3c 3f 3d 3a 39 35
16 7 b1 bd b2 b4 b3 b5 bc bf b7 b8 be ba b9 bb b0 b6
16 8 23 2d 2b 28 25 27 24 2c 20 26 2e 2f 22 2a 29 21
48 9 bd bf b5 bc b6 b0 b8 b1 ba be bb b7 b4 b2 b3 b9 ...
16 10 96 91 9f 90 92 93 97 9d 9b 98 9e 9a 9c 94 99 95
16 11 f1 f0 f3 fd fe f8 f2 fa f7 f4 ff fc f9 fb f6 f5
16 12 72 79 70 7a 7f 75 7d 77 73 7c 78 7b 7e 76 71 74
16 13 fc f0 ff f7 fe f9 f4 f2 fa f8 fd f3 f1 fb f6 f5
16 14 0a 0f 05 04 09 01 02 07 06 03 0b 0d 00 0c 0e 08
16 15 82 85 89 8a 87 8e 88 8b 83 84 80 86 8d 8c 81 8f
Bernstein’s Attack
• Input to AES encryption phase is either
pj kj or p’j k’j
• Bernstein’s technique computes two matrices of the form
Bernstein’s Attack
• Individual time profiles for every byte are recorded for every byte of the key.
• Applying the heuristic
pairs that satisfy this equality will have a matching time profile
Bernstein’s Attack
• This leads to correlation between the matrices computed.
• Secret key can be derived by
Investigation of the attack
• 4 attacks conducted– First, we needed to familiarize ourselves with
the code and programs
– Second, the need to verify the attack using three computers in parallel
– Third, we verified the attack on Pentium M architecture
– The fourth attack was to do profiling phase using a known non-zero key
Test Environment
• Tests 1,2 and 4
• Server : Centos 4.4, X86_64 bit edition,
• AMD Athlon 3200+ Venice Core, 2.0 GHz 2 GB RAM
• L1 Cache : 128 KB
• L2 Cache : 512 KB
• Open SSL : 0.9.8 b
Test Environment
• Attacker 1
– Fedora Core 5, 32 bit
– Pentium 4 mobile 3.06 Ghz, 512 MB RAM
– L1 Cache : 8 KB data cache
– L2 Cache: 512 KB
– GCC version: 4.1
– Open SSL version: 0.9.8 b
Test Environment
• Attacker 2 – Fedora Core 5, 32 bit
– Pentium M mobile 1.8 GHz, 512 MB RAM
– L1 Cache : 64 KB
– L2 Cache: 2 MB
– GCC version: 4.1.1
– Open SSL version: 0.9.8 b
– Attacker 3 has similar configuration
Test environment
Test 3
• Server
• Fedora Core 6 32 bit
• Pentium M mobile 1.8 GHz, 512 MB RAM
• L1 Cache : 64 KB
• L2 Cache : 2 MB
• GCC Version : 4.1
• Open SSL Version : 0.9.7a
Test Environment
• Attackers 1,2 & 3
• Fedora Core 6, 32 bit
• Intel Xeon processor, 512 MB RAM
• L1 Cache : 64 KB
• L2 Cache : 512 KB
• GCC Version : 4.1
• Open SSL Version : 0.9.8 b
Investigation
• Tests 2 & Tests 3
– Profiling phase took a total of 4.8 days
– Attacking phase took a total of 10 days
– Attack speed up by approximately 7 days.
Results
• Test 2
– The correlations very small.
– The Brute force search wouldn’t make any sense.
– Possible reasons investigated.
– Open SSL mitigated the attack to certain extent.
• By compressing S-Boxes smaller sizes, approx 2.5 KB
• Making S-Boxes reside in the L2 Cache - bigger size
Results
• Test 3– Same version of Open SSL as used by Bernstein
– Huge improvement in Correlations.
– Still not good enough
– Brute force search would take lot of time.
– Possible reasons investigated.
– Cache sizes much bigger than in Bernstein’s original attack
– Highly dependent on the architecture and software
– Similar results obtained by lot of other researchers
Results
• Profiling using non-zero key
– A known key is setup at the server
– Study program sends different packet sizes and gets timing information
– Required to know how Bernstein’s code implements the heuristic explained before and cycle through and code and make necessary changes in the arguments
Mitigations
• Alternative Look Up tables
– Already implemented in newer Open sslversion
• Storing the S-Boxes in registers
• Adding noise-not perfect
• Operating System Support
Relevance of the attack in real world
• Too much time and packets are required for the attack to succeed
• In a similar paper, researchers found that there was a difference of two orders between network delays and encryption times
• They concluded that the variance of signals of the network is very high when compared to the target signal. Very high number of readings are needed to average out the noise
Conclusion
• Bernstein’s cache attack in original form requires many modifications to work on modern architectures and networks
• Profiling can be done with a non-zero key successfully
Future Work
• Extracting a Larger key
• Replicating improved version of Bernstein’s original attack
• Verification of mitigation techniques
Questions?