Week 13, Comp [34]49, Nov 20 FMS attack extensions WEP authentication ... oops! Message modification Chop-chop attack ==================================================================== FMS attack: Collect all IV's , for 0<=3<8 and 0<=X<256 The web application gives you these tables for each separate N; if you're capturing live data then you will need to save the entries for each N. Review FMS Other "weak IVs": See FMS , last paragraph of ยง7.1 Note on notation: I'm using "_n" to suggest n is a subscript; eg S_n = nth version of the array S, while S[n] = nth component of final version of S S_n[n] = nth component of nth-stage version of S Note what we're doing (Example for second hidden byte, N=4) * collect lots of pairs where the IV is <4,-1,X> and the 1st output byte is Y. (note that X uniquely determines Y, though without Key[4] we don't know exactly how.) For each we're going to generate a guess, or a "vote", for the correct keybyte. We will be correct about 5% of the time. Furthermore, WRONG guesses will be randomly distributed. Here's how we generate the guess: * For each X, *compute* S_4, that is, the first 4 swaps done by KSA: rc4 r = new rc4(); r.ksa(4, key) r now represents S_4. It is LIKELY at this point that S[4] has not changed; that is, S_4[4] = 4 We've changed S_4[0] ... S_4[3] * The NEXT swap will exchange S_4[4] and S_4[j] . We KNOW j = j4 + S_4[4] + KEY[4]. We know j4 = r.the_j(), using the java object r above. This will mean that S_5[4] = S_4[j]. * It is now 5% likely that further changes in S will *not* affect S[0], S[1], or S[4]. These are the values that determine S[ S[0] + S[S[0]] ], = first keystream byte, Y So, if we "win" this 5% bet -- that is, we're LUCKY for this particular X -- we have S[ S[0] + S[S[0]] ] = Y = S[4] = S_5[4] = S_4[j] * It is LIKELY that S_4[j] = j. We don't have to assume that, though; we can use r.inverse() (remember r refers to S_4) to solve Y = S_4[j] ==> j = S_4.inverse(Y). * now we have S_4.inverse(Y) = j = j4 + S_4[4] + KEY[4] or KEY[4] = S_4.inverse(Y) - j4 - S_4[4] All three terms on the right are easily expressed in terms of r. If we go ahead and assume, as was stated was LIKELY just above, that S_4[j] = j, this just becomes KEY[4] = Y - j4 - S_4[4] But the inverse does improve our edge with the statistics. ============================================================================== The FMS weakness is an amazing example of a cryptographic flaw: * definitely nontrivial * very efficient; Key[i] values are determined WITHOUT major searching * as close as you get to ELEGANT in this field. Well, as close as you can get to ACCESSIBLE. ============================================================================== Some refinements from Beck & Tews, Practical Attacks against WEP and WPA 0. Basic FMS attack needs ~5,000,000 packets (for 128-bit key) 1. More general "useful IV" rule of FMS (working on Key[l]) S_l[1] < l S_l[1] + S_l[S_l[1]] = l S_l.inverse(Out) != 1, != S_l[1] Given this, we can make an educated guess as to Key[l]. I don't know how much this reduces the packet requirements. 2. KoreK attack The person writing as KoreK extended the FMS strategy. KoreK found 16 more rules between Key[0]..Key[l-1], the first TWO bytes of output: Out1 and Out2, and Key[l]. KoreK in general reduces the requirements to ~700,000 packets 3. PTW attack (Pyshkin, Tews, Weinmann) Klein[2005] showed that (l - Out[l-1]) = S[l] with probability 2/256. The Klein guesser based on this works with probability 1.37/256, **but you can use EVERY packet, not just those with "special" IV's** Also, PTW introduced a multibyte attack on the keys, working on several values (or Key[l]+Key[L+1]) at once. Packet requirement: down to ~35,000 packets (50% prob of success) Some of the multibyte attacks assume you can get SEVERAL keystream bytes, which you probably can if, say, you guess the entire IP header. 4. PTW revisit of KoreK: ~24000 packets ============================================================================== First response of the wi-fi world was to add programming to limit the use of "weak" IV's; eg those of the form . This simply made alternative "weak" IV's more eagerly sought for. The problem is really that the FULL class of weak IV's is simply too big. ============================================================================== ============================================================================== Now onto WEP authentication. The failure here *is* trivial. Oops. This is a WEP-key-based authentication protocol, used BEFORE WEP encryption takes over. 1. STA --> AP: request for authentication 2. AP --> STA: challenge text, randomly selected 3. STA --> AP: response: station encrypts challenge text 4. AP --> STA: yes/no (note that the AP also needs to authenticate itself to the STA, to prevent rogue-AP attacks, but there the STA doesn't have to do anything) How to break this We (the bad guy) capture two packets corresponding to stages 2 and 3 above. This gives us the challenge text and its encrypted version. We can then figure out the ENTIRE plaintext of the encrypted part; the challenge text we sniffed, the rest of the data fields are standard, and we can calculate the CRC. Now it's our turn to request authentication. The AP will send a different challenge text. We simply encrypt our response by XORing with the keystream found above, specifying the same IV and same key. The AP accepts it. The AP *should* notice that we're reusing a keystream, but they DO NOT. Note that this only gets us as far as authentication. ============================================================================== Message modification (BGW) The theory was that there's nothing a bad guy can do to modify the message **and preserve the CRC checksum**. But CRC isn't strong enough; achieving such message modification is in fact trivial! Problem: CRC(m1 xor m2) = CRC(m1) xor CRC(m2). This is trivial as "xor" translates to addition-as-polynomials, and CRC is just the remainder; it becomes: (m1 + m2) mod P = (m1 mod P) + (m2 mod P) Now, suppose we have encrypted message e = (m ^ CRC(m)) xor keystream Assume for the moment that we do not know m, but we DO know how to tweak a few bytes by XORing: m' = m xor delta. We want to generate e' = (m' ^ CRC(m'). The body is easy: m' xor keystream = (m xor keystream) xor delta But how do we fix the CRC? We note that CRC(m') = CRC(m) xor CRC(delta), so the encrypted CRC, CRC(m') xor keystream, is just (CRC(m) xor keystream) xor CRC(delta) In other words, e' = e xor (delta ^ CRC(delta)) ============== IP-address modification Goal: capture a packet, and modify the IP address (within the WEP-protected payload) to have the packet sent to our own IP address. It will arrive decrypted by the AP, and we will have another keystream piece. XORing to modify the IP address is trivial, assuming we know (or can guess, in a reasonable number of tries) the original IP address. What turns out to be nontrivial is updating the IP-header checksum. And our packet won't be routed if that isn't correct. We know what fudge factor to ADD (IPnew - IPold), but we don't know what to XOR (for the embedded IP header checksum) (The entire-packet CRC is handled as above.) Easiest attack: just tweak OTHER header fields until we get a packet with the SAME checksum. IP checksum is simple addition. =========================================================================== Chop-chop attack This attack gives us actual VALUES for trailing bytes. Each byte takes on average 256/2 probes to guess. We start with the message m = q^r, where r is one byte. As usual, the encrypted packet is (m ^ CRC(M)) xor keystream It turns out that if we chop out the byte r, and we know or guess the value of r, we can figure out how the CRC would have to change. Computing CRCdelta = CRCold xor CRCnew, we can then xor the CRC part of the packet with CRCdelta, and even though the packet is encrypted, we can create a new packet that has a valid CRC. When we chop out r and recompute the checksum, we are in effect making a guess at r. The AP will probably tell us whether or not a packet has a valid CRC. If the CRC is bad, there will be no response, but if it's good, and, say, we are NOT authenticated, there will be an error-not-authenticated response. Here's how to tweak the CRC. We will return to the polynomial interpretation; that is, the bits of a packet are the coefficients of a big polynomial. Let P be the CRC divisor; then the CRC is (m mod P). As a polynomial, we can express q^r as q*x^8 + r. We have CRCold = (q*x^8 + r) mod P = q*x^8 mod P + r mod P = q*x^8 mod P + r we want CRCnew = q mod P. From the above, and knowing r, we can determine q*x^8 mod P. The trick is to note that x^8 and P are, as polynomials, relatively prime (x is not a factor of P; it has a constant term). So we can solve for C in C*x^8 mod P = 1. Once we have C, then we can calculate q mod P as follows: q*x^8 mod P = k1 (known) C*q*x^8 mod P = C*k1 mod P = q* (C*x^8) mod P = q* 1 mod P = q mod P If we know, say, the last four bytes, and want the byte before that, the technique still works just fine (though if r is a multibyte string, r mod P is not automatically just r) =========================================================================== Newsham: 21-bit problem Key-generation algorithm in hardware throws entropy away! Newsham obviously did some work to figure out how the values were being generated. Linear congruential PRNG: X(n+1) = (a*X(n) + c) mod m Typically m = 2^32 (or 2^16). From three successive values, X2, X1, and X0 (and m), we can figure out a and c. (At least if X1-X0 is relatively prime to m; that is, is odd if m is a power of 2) X2 = aX1 + c mod m X1 = aX0 + c mod m X2-X1 = a(X1-X0) mod m Now do mod-m division of both sides by (X1-X0) (this is where we need this relatively prime to m) Moral: LCGs are TRIVIAL to "break". Who are you trying to fool: the universe, or your enemies? Einstein: God is subtle, but he is not malicious ============================================================================= ============================================================================= WPA: Two modes: PSK (Pre-shared Key, or "personal"), and authentication-server ("enterprise") mode First pass: WPA-1, or TKIP 802.11i + 802.1X (X is *not* a placeholder here!) 128-bit key 1. session key: hash of (base key, MAC addr, serial # of packet) Part of the header includes a 48-bit packet serial number, incremented for each packet 2. The base key is rebuilt each time the STA associates to an AP, using the secret key only for this purpose. 802.1X: "port-based authentication" EAP/RADIUS server acts as "authenticator" Extensible Authentication Protocol Remote Authentication Dial In User Service 3. Michael (MIC) 64-bit checksum that is NOT XOR-linear; that is, MIC(m1 xor m2) != MIC(m1) xor MIC(m2) in fact, no plausible replacement for the RHS xor is known. 4. Packets must be in sequence (stations keep seq counter, TSC; incremented on each packet; packets containing TSC field < counter are rejected) 5. 60-second rule MIC failure: good ICV, bad MIC 1 failure: send "MIC failure report frame" 2 in 60 seconds: shut down for 60 seconds and then renegotiate all keys Tews/Beck attack: * allows chopchop-style decrypting of short packets * may allow later injection of OTHER short packets (eg for ARP/DNS poisoning) Attacking ARP packets (where typically just ~2 bytes of payload are unknown) 1. Use standard chopchop to guess the bytes of the Michael checksum 2. Use special "patient" chopchop to get two bytes of payload Now we have a keystream. Can we use it? What about the TSC counter? It turns out that there are 8 "channels", for different Quality-of-Service levels, used by the network. Essentially all traffic goes on Channel 0, but any can be used. And each channel has a separate TSC. WHY did they do this? Must have made sense to someone. But, regardless, the cracked keystream can be replayed on any of the other channels, and it still goes to the same place. ================================================================================ ================================================================================ WPA-2: 128-bit AES (Advanced Encryption System, CCMP Counter mode with CBC-MAC Protocol CBC-MAC = Cipher Block Chaining Message Authentication Code