| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Graham, Thanks for the follow up. Glad to know that you agree that the security strength of the key is weaker once you announce the so called check field. I would not easily say that 8 bit strength reduction is acceptable. 256 time reduction for the attacker is certainly a big help. It could mean 256 days vs 1 day or 256 computers vs 1 computer to achieve the same thing. If you add more bits to the key, then you add more computation on AP side to check through the list, which makes the computation problem on AP side even worse. I will just stick to my original comments to the proposal two meetings ago. The check field proposal is trading off the security strength of the key for the heavy computation that is required for your mechanism. Reducing the
strength of the key intentionally is always a questionable attempt. Best, Po-Kai From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> HI Po-kai, Yes I agree. But, as I said, the attacker has to break the key twice in order to find if the STA happens to be one that was there before, as the TA and the hash change every time. Also attacker does not know who this is.
Remember also that, at the moment, we know it is the same STA as it uses the same MAC Address each time it associates to the AP. Hence, in this IRM scheme, it requires 2 goes at a “120 bit” key, over 2 associations, solely to know it is a returning STA.
Then, if the STA changes the key, once associated, it is impossible for the attacker as if it finds a key, it is different, so it has no idea which STA it is. Maybe, after the discussions , the STA always changes key once associated, (maybe based on a time
period) then no attack is possible. Of course it is also easy to add another octet, or more, to the key, if it is felt that 120 bits (done at least twice over two associations) is not enough.
The IRM Check could be simplified by just displaying 8 bits, but I hesitated to declare real bits. As you say, it would make no difference to the computation, but if a STA declared different 8 bits each time
it associated, and did not change its key, it would slowly expose the key. The main point was that some members seemed to baulk at the idea of an AP doing a hash calculation for a list of keys. This idea of a “hint” cuts that work considerably as the AP can down select its list quickly. The IRM scheme is very flexible and it does have several things going for it: it is “opt-in”, the address changes every time, it can indicate that it is “known” or “new”, it is very secure, it does not declare
any real identity (that is left to upper layer) and it works for pre-association. I welcome constructive criticism and ideas.
Thanks Graham From: Huang, Po-kai [mailto:po-kai.huang@xxxxxxxxx]
Hi Graham, I can explain more why I say “8” bit revealed. Say your key has two bits as a simple example. To brutal force, attacker has to try 4 options. If you provide the xor in clear, say 0, it reveals that two bits are the same, so attacker now only needs to try 2 options, this effectively reduces the strength by 1 bit.
Now, you provide 8 xor value, each effectively reduces the strength by one bit, so you reduce the strength by 8 bits.
Attacker now does not need to try 128 bits. They can just try 120 bits. This reduces the attack time by 2^8=256. You are trading off the security strength of your key for the heavy computation that is required for your mechanism. Best, Po-Kai From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
IRM Check field. There seems to be some confusion over the IRM Check field. It was stated that it exposed 8 or 16 bits of the key. The IRM Check field is the EX-OR of 8 bits of the key, with the next 8 bits. For every bit there are 2 combinations 1 can be 10 or 01 0 can be 11 or 00 Hence for each of the bits there are 2 possibilities. Hence for the 8 bits there are
2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 = 256 possible combinations, i.e. 28 Hence, 256 possibilities for the 16 bits that make up the check.
Then there are still 112 more bits to go through. Spoofing and such The idea was asked that a spoof could simply copy the random MAC address and the Hash into an Association request. True, no different than copying a MAC address. But even if the AP “recognized” the STA, the spoof STA still has to associate
to do anything, and, as was pointed out, the association (4 way handshake) has nothing to do with the IRMK.
The scheme could easily be that the “Change” option becomes the norm, and as such its IRMK would be unknown and copying the old MAC and Hash would not work. Anyhow, good questions. Graham To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 |