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
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
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