Re: DOS attack on WPA 802.11?
At 12:03 11/11/02 -0500, Arnold G. Reinhold wrote: [...] >One of the tenets >of cryptography is that new security systems deserve to be beaten on >mercilessly without deference to their creator. I quite agree. >And I would argue >that the Michael countermeasure is no ordinary design tradeoff. It is >rather like a doctor prescribing a drug with severe side effects on >the theory that it is the only way to save the patient's life, >something that should be done only with the greatest caution: Here I disagree. The Michael countermeasures do not introduce any danger that does not already exist in the system. Therefore, removing the countermeasures has no benneficial effects. [...] >about it. All they have to do is write some code that sends a couple >of bad packets every minute or so to any network it finds. This >won't even be noticed by 802.11 nets that aren't using WPA, but those >that are will be severely disrupted. Guess what will happen? The >network administrators attacked will turn WPA off. As word spreads, >other net admins won't even bother turning it on. They are >overburdened anyway and installing WPA won't be a picnic. [...] >I would argue that the Michael countermeasure DOS attack breaks WPA >security as effectively as a cryptographic attack. It's simple, it's >practical, it's specific to WPA, and could even be spread by virus. >And if such an attack occurs, it will generate as much bad press as a >cryptographic attack. How will the WiFi Alliance respond? Issue a >press release pointing out that other DOS possibilities exist in >ordinary 802.11? And how much credibility will be left when 802.11i >is finally ready? As I mentioned before, there are generic DOS attacks against 802.11 that require very few transmissions. These can be used to mount the same attack against WEP, WPA, the future AES-based security protocols, or any other security protocol on top of 802.11. It is thus not specific to Michael or the Michael countermeasures. It is a very valid criticism of the system, just not of Michael. >o Second, the doctor should be certain of the diagnosis. >Is the patient's life really in danger? In this case that means >asking how easy it really is to break Michael. Normally, >cryptographers should be extremely conservative in assessing the >strength of an algorithm. But when the response to perceived >weakness is to add a different vulnerability, I would argue that the >test should be what is realistic, not the ultra conservative worst >case. The Intel article said the best known attack is a 29-bit >differential cryptanalysis. How practical is that? Does it require >vast amounts of chosen plain text? That is the currently best-known attack on Michael. It means that an attacker can forge a packet with probability around 2^-29. That is the probability of success for each attempted forgery. If you let him try 1000 packets per second, then we expect the first successful forgery within a week. I only spent a limited amount of time searching for the best possible attack. We have to assume that the attack will be improved somehow. Before you know it you are down to a timescale of hours or seconds. Currently we have a factor of 2^9 between the design strength of Michael and the best known attack. That is a _very_ small factor for a newly invented cryptographic function. We cut it as close as we dared, and much closer than I feel happy with. >If there is no practical Michael busting attack on the horizon, than >the objection to allowing users to turn the countermeasure off, >perhaps with a warning that doing so risks security, seems harder to >understand. Attacking Michael without countermeasures is practical right now. Giving the user the option to destroy security is not a good idea. The article you quoted points out that the vast majority of networks are misconfigured. The obvious lesson is _not_ to provide configuration options that result in insecure networks. If you want an insecure network that is not vulnerable to the countermeasures DOS attack, you can switch to WEP or switch of all security. This goes back to the TGi mantra: "We have enough efficient insecure protocols. We don't need another one." >o Third, the doctor should be certain that no other treatments are available. >The question of whether a significantly stronger MIC can be created >within the limited computational budget available is still an >interesting one. I hope more details about the algorithm and the >constraints, both in time and space for object code, will be >available very soon, if they are not already. If something markedly >better were developed in the next few months, perhaps the WiFi >Alliance could be persuaded to drop it in before release. At worst, >work in this area could be a useful backup in case AES-based >solutions prove too cumbersome to retrofit. I have some preliminary >ideas based on what I read in the Intel paper, but I will put them in >a sepa
Re: Possible fixes for 802.11 WPA message authentication
At 12:06 11/11/02 -0500, Arnold G. Reinhold wrote: [...] >1. Shuffle the order of the message words stirred into Michael. For [...] I can't go into details here due to NDA considerations, but this idea cannot be efficiently implemented on some of the existing hardware. >2. Refresh the Michael key frequently. This proposal rests on WPA's [...] This has no effect on the best attack we have so far. The attack is a differential attack, and changing the key doesn't change the probabilities. >3. Do MIC chaining. Xor (or add) the MIC output block from the >previous packet to K (or to the previous sub-key) to form the Michael >sub-key for the current packet. This costs very little and makes it >much more difficult to figure out K without breaking the WPA >encryption. Just like idea 2, this doesn't affect the best known attack as that attack never tries to recover the Michael key. Cheers! Niels == Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977 PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Workshop on HCI and Security at CHI2003
Since posting, I got a better web page: http://www.iit.nrc.ca/~patricka/CHI2003/HCISEC/index.html Adam On Mon, Nov 11, 2002 at 09:54:51AM -0500, Adam Shostack wrote: | I think that the intersection of usability and security is of | tremendous import, and wanted to share an under-advertised sort of | workshop announcement: | | http://www.acm.org/sigchi/ | | The conference home page is | | http://www.chi2003.org/ | | The workshop page is | | http://www.iit.nrc.ca/~patricka/CHI_2003/HCISEC/workshop.html | | I thought that the workshop info would be accessible from the | conference site, but that appears not to be the case (at least not | yet). | | Feel free to forward the URL to anyone else you think might be | interested. Since it's at CHI, I expect we'll get plenty of people | from that community, but we also really want attendees from the | security community as well. | | - Chris | | - | The Cryptography Mailing List | Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- "It is seldom that liberty of any kind is lost all at once." -Hume - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Possible fixes for 802.11 WPA message authentication
Here are some thoughts that occur to me for improving the security of
802.11 WPA message authentication (MIC), based on what I read in
Jesse Walker's paper
http://cedar.intel.com/media/pdf/security/80211_part2.pdf.
One approach is to second guess Niels Ferguson and try to find a
different combination of operations that will produce greater
security than his Michael algorithm. That is a worthy research idea
and might even be automated, since there are relatively few
possibilities given the tight computation time budget. My guess is
that Niels has done a good job and, in any case, revisiting the
Michael design not likely to produce anything that can be implemented
before WPA is introduced. So this doesn't seem the most productive
place to look right now.
A different approach might be to select an MIC algorithm that is much
stronger but breaks the bank on computing time for older access
points, yet still works on existing cards. One could then have two
variants, WPA and WPA-XS (extra strength). Sites that wanted the best
security would have to junk older access points. XS could also be
required for 802.11a, the new, faster standard for the 5 GHz band,
which will presumably require beefier access points anyway.
A third approach for the short term would be to leverage Michael,
i.e. use Michael as is and add stuff that makes the WPA MIC harder to
break. Then all the cryptoanalytical work done to date on Michael
remains valid. Here are several approaches I have come up with. For
this discussion call the Michael key produced under WPA as it exists
K. I am not proposing any change in the way K is generated or
distributed.
1. Shuffle the order of the message words stirred into Michael. For
example, divide the message payload into four blocks. Let L be the
length of the payload in words (after padding). Compute M = L/4 (a
shift). Then the blocks are [0 to M-1]. [M to 2M-1], [2M to 3M-1]
and [3M to L]. At the time a new K is created, compute a randomized
permutation of 4 elements and four randomized "order-determining"
bits, all derived securely from K. Then for each packet, compute the
Michael hash of the blocks in the order of the permutation, with the
additional wrinkle that each block is hashed in either ascending
order or descending order, based on the value of the corresponding
bit. Note that each word is hashed exactly once and the added
overhead is modest and outside the Michael inner loop.
A 4 element permutation has 4.5 bits of entropy, with the four
order-determining bits, that adds at total 8.5 bits to Michael's
strength. The same concept with 8 blocks would add 23 bits. The
source and destination addresses are also hashed. They can simply be
considered part of the payload, or they can be hashed separately,
before any of the blocks or at the end, again determined by K, to add
additional variability.
Since the MIC generated here is exactly the same as the original
Michael MIC of the permuted message, there is no reduction in Michael
security. This method breaks down for very short packets, however
computation time is presumably less of an issue for short packets, so
we should be able to come up with something in these cases. Perhaps
we could apply the permutation to data word bytes and use the order
determining bits to specify a shift.
2. Refresh the Michael key frequently. This proposal rests on WPA's
need to keep packet order in sync for the IV counter. I propose
generating a sequence of 64-bit sub-keys derived from K using a
reasonably secure algorithm and using them instead of K to key
Michael. Since each sub-key gets very little exposure, breaking
Michael become much more difficult.
2a. Here is one way to generate the sub-key sequence: Create an
instance of RC4 in software and initialize it using K as the RC4 key.
Then generate 8 cipher bytes each time a new sub-key is needed. One
could do this for every MIC that is generated. This would require
eight RC4 cypherbyte generations per packet. A 258-byte RC4 state
{i, j, S} will be required for each active K and the RC4 key setup
will need to be performed each time K is changed. For extra credit,
one can discard the first 256 cipherbytes, though I think that is
overkill here.
2b. If that is too much overhead, one could generate one cipherbyte
for each packet and change keys every time eight had been
accumulated. Each Michael key only gets used eight times. This
computation and storage load does not seem like a lot to me, but If
it is too much here is a yet another approach:
2c. This one makes me a bit nervous, but it is worth putting on the
table. A new RC4 key is generated for every packet fragment sent.
Borrow one bit from each such key. The bit number used might be
derived from K. Accumulate the bits in a series of 32 bit word, say 8
of them. When you have accumulated them, use them to compute a new
sub-key, either by adding them pair-wise, or, better, using Mich
Re: DOS attack on WPA 802.11?
I appreciate Niels Ferguson responding to my concerns in such detail. I don't want to give the impression that I object to WPA on the whole. That is why I said "major and welcome improvement" in my opening sentence. I am particularly mollified by Niels' statement that "most existing cards will be useable with 802.11i by putting a lot of the cryptographic processing onto the laptop." If AES based solutions are available in a year or two that do not require selling all our old hardware on eBay, then WPA is indeed good news. Still, I feel additional discussion is in order. One of the tenets of cryptography is that new security systems deserve to be beaten on mercilessly without deference to their creator. And I would argue that the Michael countermeasure is no ordinary design tradeoff. It is rather like a doctor prescribing a drug with severe side effects on the theory that it is the only way to save the patient's life, something that should be done only with the greatest caution: o First, the doctor should be sure that the side effects aren't as bad as the disease. There is a community of "wardrivers," people who look for 802.11b networks they can access. Even assuming most of them are ethical hacker types, who will good naturedly find something else to do when WPA starts to spread, there might be a few who are less sporting about it. All they have to do is write some code that sends a couple of bad packets every minute or so to any network it finds. This won't even be noticed by 802.11 nets that aren't using WPA, but those that are will be severely disrupted. Guess what will happen? The network administrators attacked will turn WPA off. As word spreads, other net admins won't even bother turning it on. They are overburdened anyway and installing WPA won't be a picnic. Here is a story from today's Security Wire Digest: At 2:00 AM -0600 11/11/02, [EMAIL PROTECTED] wrote: *STILL AN INSECURE WIRELESS WORLD By Michael Fitzgerald The results of the second World War Drive are in, and they don't look good for wireless security. Of the almost 25,000 wireless access points surveyed, only 35 percent used Service Set Identifier (SSID), a default security feature in the 802.11b protocol. Only 28 percent had Wired Equivalent Privacy (WEP) enabled. Of those using SSID, less than 4 percent also use WEP. The issue comes down to management information system (MIS) staffing, says Pete Shipley, an independent security consultant. "It's a key distribution problem," Shipley says. "When you're in the corporate environment with a large number of laptops deploying wireless, without encryption you pretty much hand out a wireless card and it works. With WEP, you have to configure the system." While not difficult, the effort requires time, and MIS staffs typically have more pressing issues than wireless security. Shipley thinks that as security becomes more important to companies, they will revisit their wireless security setup. ... http://www.worldwidewardrive.org I would argue that the Michael countermeasure DOS attack breaks WPA security as effectively as a cryptographic attack. It's simple, it's practical, it's specific to WPA, and could even be spread by virus. And if such an attack occurs, it will generate as much bad press as a cryptographic attack. How will the WiFi Alliance respond? Issue a press release pointing out that other DOS possibilities exist in ordinary 802.11? And how much credibility will be left when 802.11i is finally ready? o Second, the doctor should be certain of the diagnosis. Is the patient's life really in danger? In this case that means asking how easy it really is to break Michael. Normally, cryptographers should be extremely conservative in assessing the strength of an algorithm. But when the response to perceived weakness is to add a different vulnerability, I would argue that the test should be what is realistic, not the ultra conservative worst case. The Intel article said the best known attack is a 29-bit differential cryptanalysis. How practical is that? Does it require vast amounts of chosen plain text? If there is no practical Michael busting attack on the horizon, than the objection to allowing users to turn the countermeasure off, perhaps with a warning that doing so risks security, seems harder to understand. o Third, the doctor should be certain that no other treatments are available. The question of whether a significantly stronger MIC can be created within the limited computational budget available is still an interesting one. I hope more details about the algorithm and the constraints, both in time and space for object code, will be available very soon, if they are not already. If something markedly better were developed in the next few months, perhaps the WiFi Alliance could be persuaded to drop it in before release. At worst, work in this area could be a useful backup in case AES-based solutions prove too cumbers
Workshop on HCI and Security at CHI2003
I think that the intersection of usability and security is of tremendous import, and wanted to share an under-advertised sort of workshop announcement: http://www.acm.org/sigchi/ The conference home page is http://www.chi2003.org/ The workshop page is http://www.iit.nrc.ca/~patricka/CHI_2003/HCISEC/workshop.html I thought that the workshop info would be accessible from the conference site, but that appears not to be the case (at least not yet). Feel free to forward the URL to anyone else you think might be interested. Since it's at CHI, I expect we'll get plenty of people from that community, but we also really want attendees from the security community as well. - Chris - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Transparent drive encryption now in FreeBSD
FreeBSD's 5.0 release, due out in a couple of weeks, will offer much anticipated transparent mass storage encryption. Subscribers to this list so inclined are encouraged to review and test this new feature. URLs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/gbde/ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/ Thanks, --Lucky Green [Moderator's note: FYI, NetBSD also has drive encryption these days. --Perry] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
