on recycling encryption schemes or achieving resistance to cache attacks via low bandwidth...
TRANSCRIPT
On Recycling Encryption Schemes
or
Achieving Resistance to Cache Attacks via Low Bandwidth Encryption
Weizmann Institute of Science
Moni Naor
Crypto in the Clouds, August 2009, MIT
2
Adversarial ModelsSTANDARD MODEL: 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
Adversarial Models
Ek(m)
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
Lampson 1973Tenex Password with page faults
4
Adversarial ModelsAttacks - 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
Many tools developed in the foundations of cryptography are helpful for protecting against
side-channel attacks
Proof by a 2nd example...
and not only at implementation time
Incorporate side-channel attacks in the design of systems
And yesterdays talk
and workshop?
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 attacksPure software
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
CPU core60% (until recently)
Main memory7-9%
Why cache?
cacheAnnual speedincrease:
Typicallatency:
50-150ns0.3ns → timing gap
11
Address leakageThe 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 attackedThe “metadata” leaks information about memory
access patterns: Which addresses are being accessed.
12
Associative memory cacheDR
AM
cach
ememory block
(64 bytes)
cache line(64 bytes)
cache set
(4 cache lines)
13
S-box tables in memoryDR
AM
cach
e
S-boxtab
le
14
Detecting access to AES tablesDR
AM
cach
e
Atta
cker
mem
ory
S-boxtab
le
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
DRA
Mca
che
T0A
ttack
erm
emor
y 1. Make sure the tables are cached
2. Evict one cache set
3. Time an encryption. See if it’s slow
Measuring effect of cache on encryption
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 cacheDR
AM
cach
e
Attacker
memory
1. Completely evict tables from cache
S-boxtab
le
19
Measuring effect of encryption on cacheDR
AM
cach
e
Attacker
memory
1. Completely evict tables from cache
2. Trigger a single encryptionS-box
table
20
Measuring effect of encryption on cacheDR
AM
cach
e
Attacker
memory 1. Completely
evict tables from cache
2. Trigger a single encryption
3. Access attacker’s memory. See which cache sets are slow
S-boxtab
le
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!
Suggested by Goldreich 1987
Pippenger and Fischer 1979
24
Model
CPU
Main memory
Small private memory
qi
M[qi]
Secure zone CPU needs to simulate locations i1, i2, …Accesses addresses q1, q2…
25
Oblivious RAM RequirementsAny 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] O(log n) bits private memory 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 encryptedWant 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 Smart Card
Where should I put it....?
Quis custodiet ipsos custodes
29
Special purpose deviceAdvantages: 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
30
Special purpose deviceProblems: 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.
Host Crypto device
Plaintext
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 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
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 RKESInput 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
37
Definition Length Preserving RKESInput 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
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 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!
40
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 HH : {0, 1}nb {0,1}b :
Should be infeasible to come up with X Y such that H(X) = H(Y).
41
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
Ciphertext
1
2
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
Non Colliding Encryption A Good 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.
Same way for Inversion
Host
device
45
The Arbiter
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