On Recycling Encryption Schemes or Achieving Resistance to Cache Attacks via Low Bandwidth Encryption Moni Naor Weizmann Institute of Science Crypto in the Clouds, August 2009, MIT

Adversarial Models STANDARD MODEL: REAL LIFE: Ek(m) Abstract models of computation Interactive Turing machines Private memory, randomness ... Well-defined adversarial access Can model powerful attacks REAL LIFE: Physical implementations leak information Adversarial access not always captured by abstract models Ek(m)

Osvik, Tromer and Shamir Adversarial Models Attacks - standard model: Chosen-plaintext attacks Chosen-ciphertext attacks Composition Self-referential encryption Circular encryption .... Attacks outside standard model: Timing attacks [Kocher 96] Fault detection [BDL 97, BS 97] Power analysis [KJJ 99] Cache attacks [OST 05] Memory attacks [HSHCPCFAF 08] ... Osvik, Tromer and Shamir Ek(m) Lampson 1973 Tenex Password with page faults

Any information not captured by the abstract “standard” model Adversarial Models Attacks - standard model: Chosen-plaintext attacks Chosen-ciphertext attacks Composition Self-referential encryption Circular encryption .... Attacks outside standard model: Timing attacks [Kocher 96] Fault detection [BDL 97, BS 97] Power analysis [KJJ 99] Cache attacks [OST 05] Memory attacks [HSHCPCFAF 08] ... Side channel: Any information not captured by the abstract “standard” model

“Outside of a few classified military programs, side-channel attacks have been largely ignored by computer security researchers, who have instead focused on creating ever more robust encryption schemes and network protocols.” W. Wayt Gibbs, Scientific American, May 2009   

Thesis of this talk and not only at implementation time Incorporate side-channel attacks in the design of systems And yesterdays talk and workshop? Many tools developed in the foundations of cryptography are helpful for protecting against side-channel attacks Proof by a 2nd example...

Outline of the Talk Cache Attacks Address Obliviousness Remotely-keyed Encryption Schemes (RKES) Adapting RKES for obtaining Address Oblivious Encryption

Cache Attacks Cryptanalysis through Cache Address Leakage Dag Arne Osvik, Adi Shamir and Eran Tromer Slides based on Eran Tromer Slides shamelessly stolen from Eran Tromer

Cache attacks Pure software Very efficient No special privileges No interaction with the cryptographic code Very efficient Full AES key extraction from Linux encrypted partition in 65 milliseconds) Compromise otherwise well-secured systems “Commoditize” side-channel attacks: Easily deployed software breaks many common systems

Why cache? → timing gap CPU core 60% (until recently) Main memory 7-9% Annual speed increase: CPU core 60% (until recently) Main memory 7-9% Typical latency: 50-150ns 0.3ns → timing gap

Address leakage The cache is a shared resource: cache state affects, and is affected by, all processes leading to crosstalk between processes. Cached data is subject to memory protection Not attacked The “metadata” leaks information about memory access patterns: Which addresses are being accessed.

Associative memory cache memory block (64 bytes) DRAM cache set (4 cache lines) cache line (64 bytes) cache

S-box tables in memory S-box table DRAM cache

Detecting access to AES tables Attacker memory S-box table DRAM cache

What to Measure Two approaches to exploit Inter-process crosstalk: Measuring the effect of the cache on the encryption Need precise timing Measuring the effect of the encryption on the cache Bernstein; Percival; Bonneau and Mironov

Measuring effect of cache on encryption 1. Make sure the tables are cached Attacker memory T0 2. Evict one cache set DRAM 3. Time an encryption. See if it’s slow cache

What to Measure Two approaches to exploit Inter-process crosstalk: Measuring the effect of the cache on the encryption Need precise timing Measuring the effect of the encryption on the cache

Measuring effect of encryption on cache Attacker memory 1. Completely evict tables from cache S-box table DRAM cache

Measuring effect of encryption on cache Attacker memory 1. Completely evict tables from cache 2. Trigger a single encryption S-box table DRAM cache

Measuring effect of encryption on cache 1. Completely evict tables from cache Attacker memory 2. Trigger a single encryption S-box table DRAM 3. Access attacker’s memory. See which cache sets are slow cache

Advantages of Measuring effect of encryption on cache Yields more information (64) from a single encryption Insensitive to timing variance in encryption code path No real need to trigger the encryption – can wait until it happens by itself

Protection Address Obliviousness Want the computation to access addresses in a manner that is oblivious to input Plaintext Keys? There exist slooow implementations of address oblivious encryption True for AES

Protection: The Oblivious RAM Model Oblivious Turing Machine: At any point in time know where the heads are The access pattern is independent of the input Important: to convert to circuits Oblivious RAM The access pattern is independent of the data Probability distribution! Pippenger and Fischer 1979 Suggested by Goldreich 1987

Model CPU needs to simulate locations i1, i2, … Secure zone Accesses addresses q1, q2… qi CPU Main memory Small private memory M[qi]

Oblivious RAM Requirements Any sequence of locations i1, i2, … induces a distribution on sequences of requests q1, q2… Functionality: should be able to figure out the original content Security: for any two sequence of locations i1, i2, … i’1, i’2, … induced distributions of requests should be indistinguishable

Oblivious RAM Constructions Trivial: O(n) slowdown O(log n) bits private memory Known: polylog slowdown [Goldreich-Ostrovsky 96] Some improvements –Williams, Sion and Carbunar 2008 Can we do better? Want constant or less overhead Also need to be able to run a few primitives obliviously

Want: Address Oblivious Encryption At least wrt the key Work on large chunks Partition the encryption process into: A slow but short part: implemented securely Fast and insecure part: should not have consequences beyond values encrypted Want to be able to express that partition is secure Recycle a scheme/definition for remotely keyed encryption Matt Blaze, Joan Feigenbaum and Moni Naor, Eurocrypt 1998

Who will guard the guards? No cryptographic protocol is stronger than the mechanism protecting its secret keys. Almost any computer connected to the world will be corrupted (at least partly) at some point in time. However: in most systems no safe place for storing the keys. Idea: add a special purpose device for encryption Smart­Card Where should I put it....? Quis custodiet ipsos custodes

Special purpose device Advantages: Limited functionality, fewer places to err, easier to design Can design once and for all. Should work with all systems. Can be cheap ­ smart­card Host Crypto device High Bandwidth Channel

Special purpose device Problems: Bandwidth from device to host. Should be as high as any link. Does not grow with the host: Keys/device may live many years. Host Crypto device High Bandwidth Channel

Remotely keyed encryption How to do high bandwidth encryption/decryption Taking advantage of: The power (bandwidth, computing) of the host. Superior security of the crypto device Security risk: host is completely controlled by attacker for certain periods of time.

Model: Communicating parties Two parties: Host and Device. To encrypt/decrypt (Host, Device) interact. Desirable: lower communication than plaintext. Plaintext Host Crypto device Ciphertext

Model: Adversary Adversary A attacks the system: Host Phase ­ Adversary A controls the Host and all its communication links. A cannot see internal computation of the device Challenge Phase ­ Adversary A ceases control of the internal communication. Can still attack the pair (Host, Device) externally. No moderate physical pressure!

What do we know to do Definition of Security for Remotely­Keyed Encryption Schemes (RKES). Length Preserving Encryption and Length Increasing Encryption Constructions where encrypting n blocks requires Fixed communication and computation at the device. Proportional to a single block … n

Length Preserving Encryption Saves on memory and communication bandwidth Easy to embed in existing systems ­ doesn't destroy formats (sectors, packets) Problem: what to do with repeated blocks? Solutions: Chaining (CFB,CBC) ­ reveals prefix information. Permutation on very large blocks ­ our approach.

Definition ­ Length Preserving RKES Input X = (X1, …, Xn) Output Y = (Y1 …,Yn) Each xi, yi 2 {0,1}b : Non­RKES security: Encryption function should be a pseudo­random permutation  Even if adversary A can access  and -1 A cannot distinguish it from a random permutation. Too strong for RKES:  is not random for A: A has a short description of  on the values it saw at the attack phase

Definition ­ Length Preserving RKES Input X = (x1, …, xn) Output Y = (y1 …,yn) Each xi, yi 2 {0,1}b : Idea: call it secure if A cannot distinguish a switch to a random permutation after host­phase. What about X1, …, Xm from Host Phase? Well, except them... Problem: they are not well defined! Due to low communication

Definition: The Arbiter Add a new (fictitious) party: the arbiter B Filters the message of the Challenge Phase. The arbiter B acts as a simple function of the communication of the Host Phase. The number of messages filtered by B in the Challenge Phase should be bounded by m The number of interactions in the Host Phase.

Tools Pseudo­random function Fk : {0, 1}b  {0,1}b Pseudo­random permutation Ek:{0, 1}b  {0,1}b Ek should be a strong pseudo­random permutation E and F may be implemented by ``common'' block ciphers. Length preserving encryption scheme GS:{0, 1}nb  {0,1}nb If S is random, then GS(x1, …, xn) is pseudo­ random for all (x1, …, xn) . Possible realizations: a pseudo­random generator, permutation on large or small blocks. A collision intractable hash function S is used only once!

Tools Pseudo­random function Fk : {0, 1}b  {0,1}b Pseudo­random permutation Ek:{0, 1}b  {0,1}b Length preserving encryption scheme GS:{0, 1}nb  {0,1}nb A collision intractable hash function H H : {0, 1}nb  {0,1}b : Should be infeasible to come up with X  Y such that H(X) = H(Y).

The NR­Framework Compose Q= 1 °  ° 2 where: 1,  and 2 are permutations. 1 and 2 are lightweight mostly Device.  is heavy mostly Host. Plaintext 1  2 Ciphertext

The Construction 1 and 2 change only the first block 1 (x1, …, xn) = (w, x2, …, xn) w is a function of x1 and hx =H(x2, …, xn) 2(y1, …, yn) = (z, y2, …, yn) z is a function of y1 and hy =H(y2, …, yn)  is defined by two keys (k3 , k4) (w, x2, …, xn) = (z, y2, …, yn) where z = Ek3(w) (y2, …, yn) = GFk4(w)(x2, …, xn)

Properties of 1 and 2 Non­Colliding Encryption A­Good sequences ­ different X's have different z's.

Evaluation Evaluation of 1 by (Host, Device) Host: compute hx = H(x2, …, xn) Send (x1; hx). Device: compute w based on its secret keys. Evaluation of  by (Host, Device): Device computes S = Fk4(w) and z = Ek3(w) Sends (S, z). Host computes (y2, …, yn) = GS(x2, …, xn) Evaluation of 2 by (Host, Device) Host: compute hy=H(y2, …, yn) and send it. Device: compute y1 based on its secret keys. Host device Same way for Inversion

The Arbiter Decryption: similar Arbiter B: On encryption query x1, x2, …, xn Compute h = H(x2, …, xn) Check whether (h, x1) occurred in the transcript of the host phase. Decryption: similar

Connecting to Address Obliviousness Device implemented by an address hiding implementation of Block Cipher Host implemented without address obliviousness Security: No information about the key is leaked Only information on actual plaintext may be leaked: If hash function implementation is not address oblivious

Efficiency To encrypt a large number of blocks: Need a fixed number of address oblivious computations Number of encryptions proportional to chunk Compute a cryptographic hash function Do we need a cryptographic hash function H? Adversary need not see the results Open question: come up with an address oblivious universal hash function

תודה רבה Thank You