860 likes | 982 Views
Forward-Security in the Limited Communication Model. Stefan Dziembowski. Warsaw University and CNR Pisa. This talk. Brief introduction to the Limited Communication Model . The talk mostly is based on the following papers:
E N D
Forward-Security in the Limited Communication Model Stefan Dziembowski Warsaw University and CNR Pisa
This talk Brief introduction to the Limited Communication Model. The talk mostly is based on the following papers: [D06a] S. DziembowskiIntrusion-Resilience via the Bounded-Storage Model,TCC 2006 [D06b] S. Dziembowski On Forward-Secure Storage, accepted to CRYPTO 2006
Idea of the Limited Communication Model Main idea: Construct cryptographic protocols where the secrets are so large that cannot be efficiently stolen. (details follow)
Plan • Motivation and Introduction • Protocols for • session-key generation • entity authentication • secure storage • Connections to the other areas
Disclaimer New area, work in progress!!!
Setup: K installs a virus authenticates with K the user can impersonate the user! K 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.)
The contribution of [D06a] We propose a cheap method that makes the task of the adversary significantly harder Idea: Make the secret key Kso large that the adversary cannot retrieve it. We consider • entity-authentication • session-key generation
The model (1/3) We assume that • the secret keyK 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.
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 called: 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.
A tool: Bounded Storage Model It turns out that this is related to the Bounded Storage Model (BSM) [Maurer 1992] In the BSM the security of the protocols is based on the assumption that one can broadcast more bits than the adversary can store. The computing power of the adversary may be unlimited!
Alice Bob message M = Decr(K,C) message M Symmetric encryption Key generation algorithm secret key K secret key K M ? Eve ciphertext C = Encr(K,M)
Indistinguishability What does it mean that Eve has no information about M? To say: “She cannot guess M” is not enough... Consider the following game: A selects messages M0,M1 and sends them to the oracle selects a random bit b and a random key K, and sends C = E(K,Mb)to the adversary b?
One-time pad encryption Disdvantage:the key is as long as the message! [Shannon 1949]:this is optimal unless we limit the power of the adversary in some way.
K K message M Message Authentication Codes Observation: encryption does not guarantee integrity of a message (example: one-time pad) To ensure the integrity one has to use MACs (message authentication codes). Eve can modify the transmited messages M,MAC(K,M) verifies the MAC and accepts only M
Alice Bob message M = Decr(d,C) message M Public key encryption Key generation algorithm Bob’s public key e Bob’s secret key d M ? ciphertext C = Encr(e,M)
How to limit the power of the adversary • Classical cryptographylimit the adversary to the poly-timedisadvantage: we don’t know how to prove any security here • Information-theoretic cryptographyassume: • quantum communication, • bounded-storage, • noisy channels advantage: provable security!
randomizer R: 000110100111010010011010111001110111 111010011101010101010010010100111100 001001111111100010101001000101010010 001010010100101011010101001010010101 can perform any computation on R, but the result U=h(R) has to be much smaller than R X = f(R,Y) The Bounded-Storage Model (BSM) short initial keyY randomizer disappears knows: U=h(R) Eve shouldn’t be able to distinguish X from random X ?
Power of the adversary Note: The only resource that we bound is memory. The computing power is unlimited!
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-secureif it is secure against an adversary that has memory of a size s.
0 0 0 1 1 0 1 0 1 0 0 0 0 1 0 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 1 0 1 0 0 0 0 1 The derived key X 0 0 0 1 0 1 0 1 0 0 0 1 The scheme of [DM02] 0 1 0 1 0 1 0 1 0 0 1 1 0 1 0 0 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 0 0 0 1 0 1 0 0 XOR
How is BSM related to our model? Seems that the assumptions are oposite:
C the bank We solve the following problem: Alice knows the public key of the bank How can the bank verify the authenticity of the user? Entity authentication – the problem the user can verify the authenticity of the bank the bank cannot verify the authenticity of the user
key K =R: 000110100111010010011010111001110111 111010011101010101010010010100111100 001001111111100010101001000101010010 001010010100101011010101001010010101 random Y X = f(R,Y) Entity authentication – the solution 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 (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 long-term key K Bob Alice ...
Intrusion-resilient session-key generation compromised sessions– when adversary installed a virus on the machine of at least one of the users non-compromised sessions compromised sessions time Clearly leaks to the adversary. We want the keys generated in non-compromised sessions to remain secret!
generates a random key (e,d) for the public key encryption e,MAC(K,e) C = Encr(e,Z), MAC(K,C) generates a random key Z Forward-secure session-key generation (standard method) (Encr,Decr)– a public key encryption scheme long term key: key K for a MAC decrypts Z from C erases d Z
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?
0 0 0 1 1 0 1 0 1 0 0 0 0 1 0 1 0 0 0 1 0 1 1 0 How the adversary can influence the outcome of the protocol 0 1 0 1 0 1 0 1 0 0 1 1 0 1 0 0 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 0 1 0 1 0 0 1 1 0 1 0 1 0 0 1 0 0 0 1 0 1 0 0
Repairing the protocol How to repair the protocol? Our idea: add hashing
The Random Oracle Model We model the hash function as arandom oracle containing a truly random function. The oracle can be queried by the the honest users and by the adversary.
Finalizing the proof So the adversary has no information about Kaand Kb. • If Ka=Kb - we are done! • Otherwise Kaand Kb are independent.Alice and Bob will detect it when they use Kaand Kb in a MAC scheme.
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.
Independent Work Giovanni Di Crescenzo, Richard Lipton and Shabsi Walfish Perfectly Secure Password Protocols in the Bounded Retrieval Model, TCC 2006 Main difference: the adversary can retrieve only individual bits.
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...