Download presentation
Presentation is loading. Please wait.
1
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
2
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)
3
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
4
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
5
“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
6
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...
7
Outline of the Talk Cache Attacks Address Obliviousness
Remotely-keyed Encryption Schemes (RKES) Adapting RKES for obtaining Address Oblivious Encryption
8
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
9
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
10
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
11
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.
12
Associative memory cache
memory block (64 bytes) DRAM cache set (4 cache lines) cache line (64 bytes) cache
13
S-box tables in memory S-box table DRAM cache
14
Detecting access to AES tables
Attacker memory S-box table DRAM cache
15
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
16
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
17
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
18
Measuring effect of encryption on cache
Attacker memory 1. Completely evict tables from cache S-box table DRAM cache
19
Measuring effect of encryption on cache
Attacker memory 1. Completely evict tables from cache 2. Trigger a single encryption S-box table DRAM cache
20
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
21
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
22
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
23
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
24
Model CPU needs to simulate locations i1, i2, … Secure zone
Accesses addresses q1, q2… qi CPU Main memory Small private memory M[qi]
25
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
26
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
27
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
28
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 SmartCard Where should I put it....? Quis custodiet ipsos custodes
29
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 smartcard Host Crypto device High Bandwidth Channel
30
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
31
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.
32
Model: Communicating parties
Two parties: Host and Device. To encrypt/decrypt (Host, Device) interact. Desirable: lower communication than plaintext. Plaintext Host Crypto device Ciphertext
33
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!
34
What do we know to do Definition of Security for RemotelyKeyed 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
35
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.
36
Definition Length Preserving RKES
Input X = (X1, …, Xn) Output Y = (Y1 …,Yn) Each xi, yi 2 {0,1}b : NonRKES security: Encryption function should be a pseudorandom 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
37
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 hostphase. What about X1, …, Xm from Host Phase? Well, except them... Problem: they are not well defined! Due to low communication
38
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.
39
Tools Pseudorandom function Fk : {0, 1}b {0,1}b
Pseudorandom permutation Ek:{0, 1}b {0,1}b Ek should be a strong pseudorandom 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 pseudorandom generator, permutation on large or small blocks. A collision intractable hash function S is used only once!
40
Tools Pseudorandom function Fk : {0, 1}b {0,1}b
Pseudorandom 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).
41
The NRFramework 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
42
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)
43
Properties of 1 and 2 NonColliding Encryption
AGood sequences different X's have different z's.
44
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
45
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
46
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
47
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
48
תודה רבה Thank You
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.