Intrusion Resilience via the Bounded-Storage Model Stefan Dziembowski Warsaw University and CNR Pisa

Setup: K Kauthenticates with K installs a virus the user can impersonate the user! the bank

Question Can cryptography prevent such an attack?

Can we prevent this attack? If we have a trusted hardware then this attack is preventable. This hardware can be e.g.:  a token  a list of one-time passwords Note that the human-memorized passwords don’t help (because the virus can record the key-strokes).

Assume there is no trusted hardware (trusted hardware costs and is not easy to use) Can we have any security in this case? Looks quite hopeless... (If the adversary can take control over our machine, than he can do whatever he wants.)

Our goal We propose a cheap method that makes the task of the adversary significantly harder. Caution: our method does not guarantee super-high levels of security. However in many cases it may be worth using.

Our contribution Idea: Make the secret key K so large that the adversary cannot retrieve it. We consider  entity-authentication  session-key generation

We assume that  the secret key K is stored on a machine which can be infected by a virus  the virus can perform an arbitrary computation on K, but the output of this computation U is shorter than K:  she can retrieve U.  (this looks similar to the Bounded-Storage Model!) The model (1/3)

The model (2/3) As long as the machine is infected, the virus has a full controll over it. We want to have security in the periods when the virus is not controlling the machine: This is what we call: intrusion resilience. We assume that the virus cannot modify the data on the machine.

The model (3/3) What else can the adversary do? She can perform active attacks: eavesdrop, substitute and fabricate messages.

Plan 1. Introduction 2. Introduction to the Bounded- Storage Model 3. Entity Authentication 4. Session-Key Generation 5. Practicality?

The Bounded-Storage Model (BSM) can perform any computation on R, but the result U=h(R) has to be much smaller than R short initial key Y X = f(R,Y) randomizer R: knows: U=h(R) randomizer disappears X ?

BSM – previous results Several key-expansion functions f were proven secure [DR02, DM04b, Lu04, Vad04]. Of course their security depends on the bound on the memory of the adversary. We call a function s-secure if it is secure against an adversary that has memory of a size s.

The scheme of [DM02] XOR 1000 The derived key X

Entity authentication – the problem Alice knows the public key of the bank the bank the user can verify the authenticity of the bank the bank cannot verify the authenticity of the user How can the bank verify the authenticity of the user? We solve the following problem: C

Entity authentication – the solution random Y key K = R: X = f(R,Y) verifies The communication is done via the channel C.

Security of the entity authentication protocol (1/3) Clearly as long as the adversary is controlling Alice’s machine, she can impersonate her. But what happens when the adversary looses control on the user’s machine?

Security of the entity authentication protocol (2/3)

Security of the entity authentication protocol (3/3) What about the active attacks? Since the communication is done via the channel C, the only thing that the adversary can do is to “act as a wire”.

Session-key generation The entity authentication protocols without key generation are often not very useful. It is much more practical to have a session-key generation protocol.

The session-key generation Alice Bob long-term key K...

Intrusion-resilient session-key generation Clearly leaks to the adversary. compromised sessions non-compromised sessions compromised sessions – when adversary installed a virus on the machine of at least one of the users We want the keys generated in non-compromised sessions to remain secret! time

Intrusion resilience = backward + forward security

Forward-secure session-key generation (standard method) long term key: key K for a MAC ( Encr,Decr ) – a public key encryption scheme generates a random key (e,d) for the public key encryption e,MAC(K,e) generates a random key Z C = Encr(e,Z), MAC(K,C) decrypts Z from C Z erases d

Our protocol Outline:  We achieve forward security in a standard way.  Only the backward security is novel. Challenge: How to generate the key K (for authentication) in a backward-secure way?

A (slightly wrong) idea

Security

Security – proof attempt (1/2)

Security – a proof attempt (2/2)

How the adversary can influence the outcome of the protocol

Repairing the protocol How to repair the protocol? Our idea: add hashing

Other variants (1/2) Once we assumed the Random Oracle Model we can try to build f using the hash function Suppose f’(R,Y) just selects n bits from R (Y describes which bits) R:R: f’(R,Y):

Other variants (2/2) If we set f(R,Y) := H(f’(R,Y)) then the output of f(R,Y) is entirely uniform (unless we guessed f’(R,Y)). Therefore it is enough to show that the adversary cannot guess f’(R,Y) if she knows just h(R).

Improvements The Random Oracle Assumption was removed in Cash et al. [Cryptology ePrint Archive: Report 2005/409]. They also introduce the name Limited Communication Model.

Example The function f of [DM02] was proven secure when the memory of the adversary has a size of around 8% of the length of the randomizer. In our case the players need to store 2 randomizers, so the protocol is secure if the adversary cannot retrieve 4% of the key. Example: if |K| = 5 GB, then we can allow her to retrieve 200 MB. This can probably be improved significantly...

Practicality? The model has some obvious weaknesses (the intruder can impersonate the user, during the attack). Nevertheless it may find some applications as it is very cheap and very easy to use. Also note: the trusted server can generate the key pseudo-randomly and just store the seed. Example: remote login authentication at the university servers.