Download Security of CCA Protocol in Online Transactions: Passive and Active Attacks and more Study notes Cryptography and System Security in PDF only on Docsity!
Lecture 7 - CCA security
Boaz Barak February 24, 2010
Reading BS Section 9.3, KL Section 3.7 (pages 103–104), Chapter 4 (al- though we follow a somewhat different order than both books).
The online shopping problem Let’s abstract the online shopping prob- lem as follows: Alice and Bob share a key k, and Alice also has a credit card number c which Bob can validate against a database. (For simplic- ity, assume that there is only one valid credit card, and so the validation is simply checking that the card equals c.) Consider the following protocol for an online transaction:
Protocol 1
Alice Bob (k, c) (k, c) y = Ek(c) −−−−−−→ Check Dk(y) = c Either: OK←−− or GT H←−−−
Security What does it mean for this protocol to be secure. A security defi- nition always has three components:
- The capabilities of the adversary: we’ll always model it as a polynomial- time algorithm.
- The attack model: in this case we’ll start with a passive attack - Eve just sits on the line and listens to polynomially many executions of Protocol 1 (all using the same key and credit card).
- The definition of a break / “win” of the adversary: We’ll make the fol- lowing definition: Assume that k ←R { 0 , 1 }n^ and c ←R [10^8 ]. We say
that the protocol is secure if for every poly-time Eve, poly-bounded and large enough n,
Pr[Eve guesses c ] ≤ 10 −^8 + (n)
We say that a protocol satisfying the above definition is a passively secure authentication protocol
Theorem 1 If (E, D) is CPA-secure then Protocol 1 is a passively secure authentication protocol.
Proof We’ll do the proof by reduction: assume that A can break the passive security of Protocol 1, we’ll build an adversary B that can break the CPA security of the encryption scheme. In an actual attack, A sees T repetitions of the following messages: Ek(c) −−−→ OK←−− (of course each occurrence of Ek(c) uses fresh randomness) Consider the following “mental experiment” we run the attack of A, but instead choose a junk message J ←R { 0 , 1 }n^ (e.g., J = 0n) and send an encryption of J instead of c. That is, A will see T repetitions of: Ek(J) −−−→ OK←−− Clearly in this case A gets no information on c and so will guess it suc- cessfully with probability at most 10−^8. Hence under our assumption A can distinguish between the two cases with advantage . Using the hybrid method it follows that there is an i ∈ [T ] such that A can dis- tinguish between the case that the first i messages are encryptions of c and the last T − i messages are encryption of J and the case that the first i + 1 messages are encryptions of c and the last T − i − 1 messages are encryptions of J. Specifically, if we let p be the probability that A guesses correctly in the first case then in the second case A guesses correctly with probability at least p + /T. We can now mount a CPA attack against the encryption scheme. B will do the following:
- Choose a number c ←R [10^8 ], J ←R { 0 , 1 }n.
- Ask for i encryptions of c.
decoding algorithm will only check for existence of a single 1 following the first i zeroes. Now suppose that the credit card number c is encoded in this form to a string ˆc, and then we use the PRF-based CPA-secure encryption we saw in class (Ek(x) = (r, fk(r) ⊕ x) ) to encrypt ˆc. The crucial observation is that if Eve gets a ciphertext Ek(x) = (r, y) even without knowing what is the plaintext, she can still flip the ith^ bit of y and that will change the ciphertext to the encryption of x with its ith^ bit flipped. This means that Eve to guess a particular digit of the card, Eve can try to flip the last location in the encoding of that digit, then one before last, and so on. If i is the first location where Eve got a “GTH” message then the digit was i − 1. Thus, after at most 88 executions Eve would be able to learn the entire credit card number.
On the importance of contrived counterexamples: Why is this mean- ingful? On a first encounter a natural reaction to such a counterexample is that this is cheating. This is an obviously contrived encryption scheme which no designer in his right mind would use in a login protocol. How can such an example teach us something about security? There are sev- eral answers to this concern (in some sense these are all different ways to state the same answer):
- Although this example is contrived, its only a simplified presenta- tion of attacks which worked for real-world protocols such as WEP, IPSEC, SSH etc.
- Such examples teach us what we need to assume about the under- lying components that we use. If there is a credit-card payment protocol that uses an encryption this example tells us that if the protocol is secure at all, its security is not based solely on the fact that the encryption scheme is CPA secure, but rather the protocol needs some additional property from the encryption scheme. This is important because even if the protocol is secure now, at some fu- ture date someone might decide to use a different encryption scheme for the protocol, and so it is crucial to explicitly state the security requirements from the encryption scheme used.
- The fact that this example does not immediately imply that protocol X is insecure does not mean that protocol X is secure. The onus
is always on the protocol designer to demonstrate that the protocol is secure. If the designer claims that his login protocol is secure, he should state under what conditions on the encryption scheme this will be the case.
Stronger notion of encryption: It turns out there is a stronger notion of encryption scheme, that suffices to imply security of Protocol 1 and in many other places. This notion might seem “crazy strong” but it turns out that:
- It is needed for many applications.
- There are pretty efficient constructions conjectured to satisfy it.
Chosen ciphertext attack The definition of chosen ciphertext attack is a variation of chosen plaintext attack but this time the attacker is given oracle access even to the decryption box!
- Adversary gets oracle access to x 7 → Ek(x) and y 7 → Dk(y).
- Adversary chooses x 0 , x 1.
- Sender chooses k ←R { 0 , 1 }n, i ←R { 0 , 1 } and sends y∗^ = Ek(xi) to the adversary.
- Adversary gets access to x 7 → Ek(x) and y 7 → Dk(y) with one restric- tion - it cannot ask the decryiption box the exact string y∗.
- Adversary comes up with a guess j. She wins if i = j.
(E, D) is CCA-secure if for every poly Adv, poly-bounded : N → [0, 1], and large enough n, Pr[Adv wins ] ≤ 1 /2 + (n).
Theorem 2 If (E, D) is CCA-secure then Protocol 1 is an actively secure authentication protocol.
Proof We modify the proof of Theorem 1 in the following way: first, we assume that Bob sends an OK message if the encryption is either of c or the junk message J. We can do that because the probability that Eve sends an encryption of the junk message J is at most 2 Tn. Then, we can simulate Eve - in Step 5 we do the following: for every generated encryption yi, feed yi to A and obtain the modified version y i′. Then, if y′ i = y∗^ then feed “OK” to A; otherwise, ask the decryption box to decrypt y i′ and answer OK iff it decrypts to either c or J.
An example of a non CCA secure encryption The basic CPA secure encryption we showed in class: given PRFs {fk}, encrypt x by choosing r ←R { 0 , 1 }n^ and outputting (r, fk(x) ⊕ r) is not CCA secure.
