| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Just want to make doubly sure the idea of IRMK and the IRMK Check and the security side is understood as this seems to be the main area of questions. The IRMK is 128 bits. The IRMK Check is 8 bits - an EXOR of 16 bits of the IRMK starting at a random point. Thus, 28 combinations of 16 bits will
satisfy the IRMK check. Hence, the number of calculations required to find the IRMK is reduced from 2128 to 2120, but no bits of the key are exposed. Hence, to break the key requires, on average, 2119 hash calculations. What does that mean?
It needs 6.64 x 1035 hash calculations HENCE, to find the key IN 1 MONTH requires 2.56 x 1020 hash calculations PER NANOSECOND
Is it worth it? Remember, the STA may well change its IRMK every month, maybe every week or sooner, AND need not use the same IRMK for any AP. Now, in the case of preventing a spoof attack by a STA that knows the network password, it is possible that the IRMK Check is used twice (only if the real STA
associated with an IRMK Check), reducing the hash calculations to 2111. NOW to find the key IN 1 MONTH still requires 1 x 1018 hash calculations PER NANOSECOND. Remember, the STA uses a different MAC address and IRM Hash every association and may change its key once associated.
In the IRM scheme, a counter can be described for every type of spoof attack.
Also remember that the IRMK does not reveal anything about the STA, it is an identifier.
The IRMK check, reduces the hash calculations required by the AP by a factor of 1/256. This is the main purpose of the Check. Hence, the correct key in 1000
keys can found with just 2 calculations (on average) The IRMK Check is a powerful tool in the IRM scheme.
Thanks Graham From: G Smith
With the IRMA idea the STA uses a key, IRMK, as its identifier. The IRMK can be different for every AP it associates to and it uses a different random MAC address
for each association. Hence tracking is virtually impossible. The STA sends a Hash that is calculated from the 48 bit address (IRMA) and the secret key (IRMK). The hash is sent in an element in the Association Request (IRM
element). The IRMK is proposed to be 128 bits. As some members pointed out, if an AP has many IRMKs stored then this could be a significant computational load if it needs
to carry out hash calculations for all of them (or on average half of them) in order to find the correct key. Hence, the idea of the IRM Check was added. This 8 bit field is an EXOR of 16 bits in the key. If included it does reduce the integrity of the
key by 8 bits, so any 3rd party who for some reason wants to brute force the IRMK used for this particular association, now needs to carry out (on average) 2119 hash calculations (6.6 x 1035). Remember the 3rd party
needs to do this for every STA that associates to see if the same IRMK comes up, solely to know if the same STA is re-associating. (it does not know who that STA is, as the IRMK is purely an identifier). Then, if the STA changes its IRMK, once associated,
then it’s impossible for a 3rd party to determine. Now the IRMK Check idea allows the AP to down-select the stored IRMKs. We can calculate this. 16 bits has 216 combinations, and the 8 bit EXOR of
the 16 bits has 28 combinations (of which only one is correct). Hence the down selection is 216/28 = 256. In other words if the AP has 1000 stored IRMKs, then with the IRM Check, it is reduced to 4.
Hence the AP need only check 2 IRMKs, on average, to confirm the hash, out of 1000. If storing less than 256 IRMKs the AP can on average find the correct key and confirm with just one hash calculation.
Hence, the IRMK Check idea is very effective and reduces the APs computations significantly. The STA includes the IRMK Check optionally, but it could use it for
every association if it wants. Also the AP can request the Check, once associated, if the STA did not include it.
The IRMA idea allows an AP to know the STA pre-association (ANQP) and before it associates. The STA can use different IRMKs and change them at will and it is
still identified. The STA expresses that it wants to the identified before association, so meets the “opt-in” criteria.
I hope this has made the actions of the IRM idea clearer and the computational load that it imposes. Thanks Graham From: Dick Roy [mailto:dickroy@xxxxxxxxxxxx]
Actually decomposition using Legendre polynomials worked a lot better than cisoids when we implemented it nearly 50 years ago! Can’t tell ya who “we” were however but it really worked! ;;^)))) RR From: HARRY BIMS [mailto:00000e81c4f2fedd-dmarc-request@xxxxxxxx]
A spectral analysis of STA transmissions can be used to narrow the search for a particular STA throughout the attack. Harry On Nov 5, 2021, at 6:32 AM, G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: 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 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 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 |