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:


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)
2
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
3
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
4
“Outside of a few classified military programs, sidechannel 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
5
and not only at
implementation time
Thesis of this talk
Incorporate side-channel attacks
in the design of systems
And yesterdays talk
Many tools developed in the
andfoundations
workshop? of
cryptography are helpful for protecting against
side-channel attacks
Proof by a 2nd example...
6
Outline of the Talk

Cache Attacks

Address Obliviousness

Remotely-keyed Encryption Schemes (RKES)

Adapting RKES for obtaining Address
Oblivious Encryption
7
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
8
Cache attacks

Pure 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
9
Why cache?
Annual
speed
increase:
Typical
latency:
CPU core
cache
60%
(until recently)
0.3ns
Main memory
7-9%
50-150ns
→ timing gap
10
Address leakage
The cache is a shared resource:
 cache state affects, and is affected by, all
processes


Cached data is subject to memory protection


leading to crosstalk between processes.
Not attacked
The “metadata” leaks information about memory
access patterns:
Which addresses are being accessed.
11
Associative memory cache
cache
DRAM
memory block
(64 bytes)
cache line
(64 bytes)
12
cache
DRAM
S-box tables in memory
13
cache
DRAM
Detecting access to AES tables
14
What to Measure
Two approaches to exploit Inter-process crosstalk:

Measuring the effect of the cache on the
encryption


Need precise timing
Bernstein; Percival; Bonneau and
Mironov
Measuring the effect of the encryption on the
cache
15
Measuring effect of cache on encryption
1. Make sure
the tables
are cached
DRAM
2. Evict one
cache set
3. Time an
cache
encryption.
See if it’s
slow
16
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
17
Measuring effect of encryption on cache
1. Completely
cache
DRAM
evict tables
from cache
18
Measuring effect of encryption on cache
1. Completely
cache
DRAM
evict tables
from cache
2. Trigger a
single
encryption
19
Measuring effect of encryption on cache
1. Completely
evict tables
from cache
2. Trigger a
cache
DRAM
single
encryption
3. Access
attacker’s
memory. See
which cache
sets are slow
20
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

21
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
22
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
Pippenger and
Fischer 1979
Oblivious RAM
 The access pattern is independent of the data

Probability distribution!
Suggested by Goldreich 1987
23
Model
Secure zone
qi
CPU needs to simulate
locations i1, i2, …
Accesses addresses q1, q2…
CPU
Main memory
Small
private
memory
M[qi]
24
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

25
Oblivious RAM Constructions

Trivial: O(n) slowdown


Known: polylog slowdown [Goldreich-Ostrovsky 96]



O(log n) bits private memory
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
26
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
27
Who will guard the guards?
No cryptographic protocol is stronger than the mechanism
Quis custodiet ipsos custodes
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....?
28
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
High Bandwidth Channel
Crypto device
29
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
30
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.
31
Model: Communicating parties


Two parties: Host and Device.
To encrypt/decrypt (Host, Device) interact.
Plaintext
Host
Desirable: lower communication
than plaintext.
Crypto device
Ciphertext
32
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
No moderate physical pressure!

Challenge Phase Adversary A ceases control
of the internal communication.

Can still attack the pair (Host, Device) externally.
33
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
34
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.
35
Definition Length Preserving RKES
Input X = (X1, …, Xn)


Each xi, yi 2 {0,1}b :
Output Y = (Y1 …,Yn)
NonRKES security:
Encryption function should be a pseudorandom
permutation 
-1
 Even if adversary A can access  and 
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
36
Definition Length Preserving RKES
Input X = (x1, …, xn)



Idea: call it secure if A cannot distinguish a switch
to a random permutation after hostphase.
What about X1, …, Xm from Host Phase?


Each xi, yi 2 {0,1}b :
Output Y = (y1 …,yn)
Well, except them...
Problem: they are not well defined!

Due to low communication
37
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.
38
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



Ek should be a strong pseudorandom permutation
E and F may be implemented by ``common'' block ciphers.
If S is random, then GS(x1, …, xn) is pseudo random for
all (x1, …, xn) .
S is used only once!
Possible realizations: a pseudorandom generator,
permutation on large or small blocks.
A collision intractable hash function
39
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).

40
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
41
The Construction


1 and 2 change only the first block
1 (x1, …, xn) = (w, x2, …, xn)


2(y1, …, yn) = (z, y2, …, yn)



w is a function of x1 and hx =H(x2, …, xn)
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) = GFk
(w)(x2,
4
…, xn)
42
Properties of 1 and 2
NonColliding Encryption
 AGood sequences different X's have different
z's.
43
Evaluation

Evaluation of 1 by (Host, Device)

Host: compute hx = H(x2, …, xn)



Send (x1; hx).
device
Device: compute w based on its secret keys.
Evaluation of  by (Host, Device):

Device computes S = Fk4(w) and z = Ek3(w)



Host
Sends (S, z).
Host computes (y2, …, yn) = GS(x2, …, xn)
Evaluation of 2 by (Host, Device)


Same
Host: compute hy=H(y2, …, yn) and send it. way for
Device: compute y1 based on its secret keys. Inversion
44
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
45
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
46
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
47
‫תודה רבה‬
Thank You
48