title | filename | chapternum |
---|---|---|
Chosen Ciphertext Security |
lec_06_CCA |
6 |
Let's start by reviewing what we have learned so far:
-
We can mathematically define security for encryption schemes. A natural definition is perfect secrecy: no matter what Eve does, she can't learn anything about the plaintext that she didn't know before. Unfortunately this requires the key to be as long as the message, thus placing a severe limitation on the usability of it.
-
To get around this, we need to consider computational considerations. A basic object is a pseudorandom generator and we considered the PRG Conjecture which stipulates the existence of an efficiently computable function
$G:{0,1}^n\rightarrow{0,1}^{n+1}$ such that$G(U_n)\approx U_{n+1}$ (where$U_m$ denotes the uniform distribution on${0,1}^m$ and$\approx$ denotes computational indistinguishability). -
We showed that the PRG conjecture implies a pseudorandom generator of any polynomial output length which in particular via the stream cipher construction implies a computationally secure encryption with plaintext arbitrarily larger than the key. (The only restriction is that the plaintext is of polynomial size which is needed anyway if we want to actually be able to read and write it.)
-
We then showed that the PRG conjecture actually implies a stronger object known as a pseudorandom function (PRF) function collection: this is a collection
${ f_s }$ of functions such that if we choose$s$ at random and fix it, and give an adversary a black box computing$i \mapsto f_s(i)$ then she can't tell the difference between this and a blackbox computing a random function. -
Pseudorandom functions turn out to be useful for identification protocols, message authentication codes and this strong notion of security of encryption known as chosen plaintext attack (CPA) security where we are allowed to encrypt many messages of Eve's choice and still require that the next message hides all information except for what Eve already knew before.
It may seem that we have finally nailed down the security definition for encryption. After all, what could be stronger than allowing Eve unfettered access to the encryption function? Clearly an encryption satisfying this property will hide the contents of the message in all practical circumstances. Or will it?
Please stop and play an ominous sound track at this point.
The WEP is perhaps one of the most inaccurately named protocols of all times. It was invented in 1999 for the purpose of securing Wi-Fi networks so that they would have virtually the same level of security as wired networks, but already early on several security flaws were pointed out. In particular in 2001, Fluhrer, Mantin, and Shamir showed how the RC4 flaws we mentioned in prior lecture can be used to completely break WEP in less than one minute. Yet, the protocol lingered on and for many years after was still the most widely used WiFi encryption protocol as many routers had it as the default option. In 2007 the WEP was blamed for a hack stealing 45 million credit card numbers from T.J. Maxx. In 2012 (after 11 years of attacks!) it was estimated that it is still used in about a quarter of encrypted wireless networks, and in 2014 it was still the default option on many Verizon home routers. (I don't know of more recent surveys.) Here we will talk about a different flaw of WEP that is in fact shared by many other protocols, including the first versions of the secure socket layer (SSL) protocol that is used to protect all encrypted web traffic.
To avoid superfluous details we will consider a highly abstract (and somewhat inaccurate) version of WEP that still demonstrates our main point. In this protocol Alice (the user) sends to Bob (the access point) an IP packet that she wants routed somewhere on the internet.
Thus we can think of the message Alice sends to Bob as a string
Now the security of the encryption means that an adversary seeing the ciphertext
So, the adversary doesn't need to decrypt the message- by spoofing the ciphertext she can ensure that Bob (who is an access point, and whose job is to decrypt and then deliver packets) simply delivers it unencrypted straight into her hands.
One issue is that Eve modifies
This is not an isolated example but in fact an instance of a general pattern of many breaks in practical protocols. Some examples of protocols broken through similar means include XML encryption, IPSec (see also here) as well as JavaServer Faces, Ruby on Rails, ASP.NET, and the Steam gaming client (see the Wikipedia page on Padding Oracle Attacks).
The point is that often our adversaries can be active and modify the communication between sender and receiver, which in effect gives them access not just to choose plaintexts of their choice to encrypt but even to have some impact on the ciphertexts that are decrypted. This motivates the following notion of security (see also CCAgamefig{.ref}):
An encryption scheme
- Mallory gets
$1^n$ where$n$ is the length of the key \ - For
$poly(n)$ rounds, Mallory gets access to the functions$m \mapsto E_k(m)$ and$c \mapsto D_k(c)$ . \ - Mallory chooses a pair of messages
${ m_0,m_1 }$ , a secret$b$ is chosen at random in${0,1}$ , and Mallory gets$c^* = E_k(m_b)$ . \ - Mallory now gets another
$poly(n)$ rounds of access to the functions$m \mapsto E_k(m)$ and$c \mapsto D_k(c)$ except that she is not allowed to query$c^*$ to her second oracle. \ - Mallory outputs
$b'$ and wins if$b'=b$ .
This might seems a rather strange definition so let's try to digest it slowly. Most people, once they understand what the definition says, don't like it that much. There are two natural objections to it:
- This definition seems to be too strong: There is no way we would let Mallory play with a decryption box - that basically amounts to letting her break the encryption scheme. Sure, she could have some impact on the ciphertexts that Bob decrypts and observe some resulting side effects, but there is a long way from that to giving her oracle access to the decryption algorithm.
The response to this is that it is very hard to model what is the "realistic" information Mallory might get about the ciphertexts she might cause Bob to decrypt. The goal of a security definition is not to capture exactly the attack scenarios that occur in real life but rather to be sufficiently conservative so that these real life attacks could be modeled in our game. Therefore, having a too strong definition is not a bad thing (as long as it can be achieved!). The WEP example shows that the definition does capture a practical issue in security and similar attacks on practical protocols have been shown time and again (see for example the discussion of "padding attacks" in Section 3.7.2 of the Katz Lindell book.)
-
This definition seems to be too weak: What justification do we have for not allowing Mallory to make the query $c^$ to the decryption box? After all she is an adversary so she could do whatever she wants. The answer is that the definition would be clearly impossible to achieve if Mallory could simply get the decryption of $c^$ and learn whether it was an encryption of
$m_0$ or$m_1$ . So this restriction is the absolutely minimal one we could make without causing the notion to be obviously impossible. Perhaps surprisingly, it turns out that once we make this minimal restriction, we can in fact construct CCA-secure encryptions.
What does CCA have to do with WEP? The CCA security game is somewhat strange, and it might not be immediately clear whether it has anything to do with the attack we described on the WEP protocol. However, it turns out that using a CCA secure encryption would have prevented that attack. The key is the following claim:
Suppose that
In particular ccaweplem{.ref} rules out the attack of transforming
We'll show that such if we had an adversary
The proof is simple and relies on the crucial fact that the CCA game allows
The proof above is rather sketchy. However it is not very difficult and proving ccaweplem{.ref} on your own is an excellent way to ensure familiarity with the definition of CCA security.
The definition of CCA seems extremely strong, so perhaps it is not surprising that it is useful, but can we actually construct it?
The WEP attack shows that the CPA secure encryption we saw before (i.e., $E_k(m)=(r,f_k(r)\oplus m)$) is not CCA secure.
We will see other examples of non CCA secure encryptions in the exercises.
So, how do we construct such a scheme?
The WEP attack actually already hints of the crux of CCA security. We want to ensure that Mallory is not able to modify the challenge ciphertext
To ensure confidentiality, you need integrity.
This is a lesson that has been time and again been shown and many protocols have been broken due to the mistaken belief that if we only care about secrecy, it is enough to use only encryption (and one that is only CPA secure) and there is no need for authentication. Matthew Green writes this more provocatively as
Nearly all of the symmetric encryption modes you learned about in school, textbooks, and Wikipedia are (potentially) insecure.1
exactly because these basic modes only ensure security for passive eavesdropping adversaries and do not ensure chosen ciphertext security which is the "gold standard" for online applications. (For symmetric encryption people often use the name "authenticated encryption" in practice rather than CCA security; those are not identical but are extremely related notions.)
All of this suggests that Message Authentication Codes might help us get CCA security. This turns out to be the case. But one needs to take some care exactly how to use MAC's to get CCA security. At this point, you might want to stop and think how you would do this...
You should stop here and try to think how you would implement a CCA secure encryption by combining MAC's with a CPA secure encryption.
\newpage
If you didn't stop before, then you should really stop and think now.
\newpage
OK, so now that you had a chance to think about this on your own, we will describe one way that works to achieve CCA security from MACs. We will explore other approaches that may or may not work in the exercises.
Let
- $E'{k_1,k_2}(m)$ is obtained by computing $c=E{k_1}(m)$ ,
$\sigma = S_{k_2}(c)$ and outputting$(c,\sigma)$ . \ - $D'{k_1,k_2}(c,\sigma)$ outputs nothing (e.g., an error message) if $V{k_2}(c,\sigma)\neq 1$, and otherwise outputs
$D_{k_1}(c)$ .
Suppose, for the sake of contradiction, that there exists an adversary
Case I: With probability at least
Case II: The event above happens with probability smaller than
We will derive a contradiction in either case. In the first case, we will use
Let's start with Case I: When this case holds, we will build an adversary
Indeed, because we are in Case I, with probability
Now for Case II: In this case, we will build an adversary
However, what does
To handle this issue
This proof is emblematic of a general principle for proving CCA security. The idea is to show that the decryption box is completely "useless" for the adversary, since the only way to get a non error response from it is to feed it with a ciphertext that was received from the encryption box.
The construction above works as a generic construction, but it is somewhat costly in the sense that we need to evaluate both the block cipher and the MAC. In particular, if messages have
A universal hash function collection is a family of functions
Universal hash functions have rather efficient constructions, and in particular if we relax the definition to allow almost universal hash functions (where we replace the
Our encryption scheme is defined as follow. The key is
-
Choose
$IV$ at random in$[2^n]$ . -
Let
$z_i = E(k,IV+i)$ for$i=1,\ldots,t+1$ . -
Let
$c_i = z_i \oplus m_i$ . -
Let
$c_{t+1} = h(c_1,\ldots,c_t) \oplus z_{t+1}$ . -
Output
$(IV,c_1,\ldots,c_{t+1})$ .
The communication overhead includes one additional output block plus the IV (whose transmission can often be avoided or reduced, depending on the settings; see the notion of "nonce based encryption").
This is fairly minimal. The additional computational cost on top of
In this course we typically focus on the simplest case where messages have a fixed size. But in fact, in real life we often need to chop long messages into blocks, or pad messages so that their length becomes an integral multiple of the block size. Moreover, there are several subtle ways to get this wrong, and these have been used in several practical attacks.
Chopping into blocks: A block cipher a-priori provides a way to encrypt a message of length
Padding: Oftentimes messages are not an integer multiple of the block size and hence need to be padded. The padding is typically a map that takes the last partial block of the message (i.e., a string
The classical "metaphor" for an encryption is a sealed envelope, but as we have seen in the WEP, this metaphor can lead you astray.
If you placed a message
Translating a proof of security in this algebra to a proof for real world adversaries is highly non trivial. However, to have even a fighting chance, the encryption scheme needs to be as strong as possible, and in particular it turns out that security notions such as CCA play a crucial role.
Footnotes
-
I also like the part where Green says about a block cipher mode that "if OCB was your kid, he'd play three sports and be on his way to Harvard." We will have an exercise about a simplified version of the GCM mode (which perhaps only plays a single sport and is on its way to ...). You can read about OCB in Exercise 9.14 in the Boneh-Shoup book; it uses the notion of a "tweakable block cipher" which simply means that given a single key $k$, you actually get a set ${ p_{k,1},\ldots,p_{k,t} }$ of permutations that are indistinguishable from $t$ independent random permutation (the set ${1,\ldots, t}$ is called the set of "tweaks" and we sometimes index it using strings instead of numbers). ↩
-
In $\epsilon$-almost universal hash functions we require that for every $y,y'\in {0,1}^{n}$, and $x\neq x' \in {0,1}^\ell$, the probability that $h(x)= h(x')$ is at most $\epsilon$. It can be easily shown that the analysis below extends to $\epsilon$ almost universal hash functions as long as $\epsilon$ is negligible, but we will leave verifying this to the reader. ↩
-
In practice the key $h$ is derived from the key $k$ by applying the PRP to some particular input. ↩