Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBH] IRM Points at Tuesday's meeting

 

  Hi Graham,

 

  This might be faster than simply doing the hashing for every single association to find the particular IRMK but there's a tradeoff in memory and management of lookup tables, this XOR would have to be recomputed after every association, right?

 

  What I was suggesting in yesterday's meeting was something more AP-friendly. Imagine the AP has a secret symmetric key (this can be shared by all APs in an ESS). When the STA associates, the AP can encrypt an identifier for the STA and send it off. The encryption operation can include variable padding to foil traffic analysis and a small amount of salt which will make the encryption probabilistic. When the STA (re)attaches it provides the encrypted identity and it is decrypted with a single AEAD operation. The padding and salt are thrown away, the user is identified by the remaining identifier, and new padding and salt are added and the identifier is encrypted again and sent to the STA for the next (re)association. This just requires two symmetric operations—one decryption and one encryption—per connection (except for the first connection which just has a single encryption). These are very fast and do not require additional overhead.

 

  This scheme would have the following properties (stolen from 11-21/0541 and 11-21/0488 where this idea was stolen from):

 

  • A passive attacker cannot determine a protected identity
  • A passive attacker cannot connect protected identities across associations
  • Identifiers can be arbitrarily padded to foil passive traffic analysis;
  • Identities are secure under a reasonable birthday bound (which will depend on the specifics of the encryption)
  • An attacker cannot substitute identifiers to connect distinct associations
  • An AP needs to only manage a single symmetric secret, used to protect all identities used in the ESS
  • All APs in the ESS can share the same symmetric key (in an out-of-band fashion)
  • Identities are protected against disclosure by other STAs
  • The overhead is minimal—e.g. 16 octet tag + 8 or so octet salt + 1 octet pad length + padding = 25 octets plus padding
  • Uses symmetric cryptography for speed and DOS resistance
  • Each identifier is unique to the ESS it was obtained from, a given ESS will have no knowledge of the identifiers used in other ESSs

 

  We lost a fixed MAC address that the network used to identify STAs when STAs started randomizing MAC addresses. That is the root of all of the problems that caused this TG to be created. This scheme can provide STAs with a fixed identifier that will live across associations over an entire BSS, which is exactly what we had with a fixed STA MAC address.

 

  regards,

 

  Dan.

 

--

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

 

On 1/19/22, 9:17 AM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

 

Dan brought up a couple of good observations after my presentation on the IRM/ID scheme.

 

Dan was concerned that in the case of a stadium there could be 10’s of thousands of devices which would put a big burden on the AP/Network in calculating the hash and finding the key (IRMK).  This would be true but on reflection I now realize that this is not a Use Case that TGbh has considered and also I doubt if it would be.  In this case I suspect that the APs would not indicate support for IRM and hence the STAs would not use it.  The ID Query might be used, not sure.  Still it’s a good point and I do want to make sure the effort is kept a low as possible. 

The idea of the IRMK Check was to reduce the work by the AP.

 

The IRMK Check at the moment uses a random start bit.  Dan expressed that it was still a lot of work for an AP to go through all the IRMKs and perform the 16/8 bit EXOR at the point that the STA is associating.  There was a suggestion that a fixed offset could be used and on reflection I think this is a practical solution.  When the STA associates, it provides a new key (IRMK) and if we had a fixed offset, the AP could quickly calculate the 8 bit Check and store it with the key, i.e., it stores the 9 octet key and 1 octet check, 10 octets per STA.  Then when the STA indicates the Check, the AP has a simple job to find those keys that match the check (reducing the list by a factor of 256). 

As an aside to this, I did at one time consider using a CRC-8 as the check.  I am not an expert on this but I felt that that was more work – I may be wrong, so if anyone feels that would be better please let me know.

 

Thanks

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