3. 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
4. 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
5. 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
6. 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
8. 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)
9. Cache Special type of computer memory operating at high speed Stores frequently accessed data Cache Miss :- If data is not found in the cache.
10. 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
12. 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
13. 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
14. Bernstein’s Attack This leads to correlation between the matrices computed. Secret key can be derived by
15. 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
16. 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
17. 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
18. 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
19. 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
20. Test Environment Attackers 1,2 & 3 FedoraCore 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
21. 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.
22. 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
23. 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
24. 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
25. Mitigations Alternative Look Up tables Already implemented in newer Open ssl version Storing the S-Boxes in registers Adding noise-not perfect Operating System Support
26. 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
27. 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
28. Future Work Extracting a Larger key Replicating improved version of Bernstein’s original attack Verification of mitigation techniques