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?