Mitigating Client Frame Tracking in IEEE 802.11 Networks
Unencrypted and predictable frame fields in IEEE 802.11 networks can lead to client frame tracking, compromising user privacy. The Client Frame Tracking Countermeasures (CFTC) proposal aims to prevent tracking across epoch boundaries by obfuscating critical fields like PN, SN, and AID. Each epoch, lasting around 10 minutes, employs randomized values generated from a Key Derivation Key (KDK). The transition between epochs involves retransmissions and potentially a mix of old and new frames to enhance privacy. By following guiding principles such as partitioning time into epochs and minimizing reliance on fixed AP-assigned values, CFTC provides a robust defense against client frame tracking.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
July 2023 doc.: IEEE 802.11-23/0873r02 Client Frame Tracking Countermeasures (CFTC) Date: 2023-07 Authors: Name Phil Hawkes Affiliations Qualcomm Address Australia Phone email phawkes@qti.qualcomm.com dho@qti.qualcomm.com Duncan Ho USA gcherian@qti.qualcomm.com George Cherian USA jouni@qca.qualcomm.com Jouni Malinen Finland Submission Slide 1 Phil Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 Summary Background Unencrypted predictable frame fields can enable client frame tracking = identifying a set of frames for which a single client (non-MLO non-AP STA or combination of a non-AP MLD) is transmitter or intended receiver can allow tracking presence or location of the person using that client, compromising privacy. This ppt: Client frame tracking countermeasures (CFTC) mitigate client frame tracking. Proposal Partition time into epochs ~ 10 min. Duration may be variable. Goal: prevent tracking associated clients across epoch boundaries (within each Epoch is acceptable). Epoch may be initiated by AP or client. CFTC applied after MPDU encryption in TX (before MPDU decryption in RX) Core CFTC obfuscates link-independent fields: PN, SN, AID. Per-link CFTC obfuscates per-link client identifiers: MAC Address Random values are generated from KDK for each epoch w/ minimal input from AP At epoch transition: Retransmission of old MPDU uses param from old epoch. A-MPDU Aggregation, TXOP contains either only old MPDUs or only new MPDUs Suggests either a hard transition, or soft transition duplicating parts of TX stacks (old + new) Submission Slide 2 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 Terminology AP: AP or the combination of an AP MLD and its Affiliated APs. Client: non-AP STA or the combination of a non-AP MLD and its Affiliated STAs. Client frame tracking: identifying a set of frames for which a single client is the transmitter or intended receiver can allow tracking presence or location of person using that client, compromising privacy. Client frame tracking countermeasures (CFTC) Mechanisms mitigating client frame tracking. Epoch: Time for which a set of obfuscation parameters applies. Submission Slide 3 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 Preview # 1 Guiding Principles Partition time into epochs Rationale Implications Prevent client frame tracking across epoch boundaries CFTC applied after encryption at TX (before decryption at RX) Replace trackable values with OTA values un-trackable across epoch boundaries Don t mix old & new parameters at epoch transition Where possible, generate per-epoch params from KDK w/ minimal AP input Epochs can be common across associated clients, or client-specific Keep same processing (MLD MAC, A1, A2, A3, PN, TID, SN) Prevent tracking predictable fields across epoch boundary 2 Prevent tracking predictable fields across epoch boundaries Per-epoch params controlling replacement/modification 3 Consider retransmissions, TXOP A-MPDU aggregation, Soft transition, short period with reTX of old & TX of new frames 4 Minimal reliance on AP assigning good random values Avoid conflicts in OTA AID & MAC Address (details in future) 5 Synch transition = better privacy AP can pre-prime clients, even multiple epochs in advance 6 Submission Slide 4 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 1. Epochs Partition time into epochs (~ 10 min?). Duration can vary CFTCGoals: CFTC prevents client frame tracking across epoch boundaries Re-randomize MAC address & other fields every epoch CFTC does not prevent client frame tracking within an epoch Submission Slide 5 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 2. CFTC below MPDU encryption Rationale: Minimal change Analysis Per-client TID, SN, PN are already assigned before CFTC, predictable, & TX in the clear Can track using SN & PN. Currently difficult to track using TID - as statically mapped to Access Classes Client per-link MAC Addresses (A1/A2) are static & in clear Per-client AID is static & in clear Can track using AID & MAC. Implication: Prevent tracking AID, MAC, SN & PN across epoch boundaries (MAC SAP) RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) MSDU Flow - Transmitting PS Defer Queuing(AP MLD Only) (null) MSDU Flow Receiving (null) Sequence Number Assignment Replay Detection Per PN (optional) Packet Number Assignment Block Ack Buffering and Reordering per SN MLD upper MAC sublayer: Common functions (null) MPDU Decryption MPDU Encryption Legend Duplicate Detection per SN (null) (11be) ETH function Block Ack Scoreboarding* New (11bi) CFTC functions: PN, SN Obfuscation & De-obfuscation (Implement somewhere in arrow range) Existing function using (11bi) CFTC-assigned MAC Address Existing function using (11bi) CFTC-assigned AID ETH (11be) TID-to-Link mapping ETH (11be) Link Merging Epoch detection, PN SN De-Obfuscn (null) Block Ack Scoreboarding* Address 1 Address Filtering MLD lower MAC sublayer: Per-link functions. (11be) ETH may have multiple links MPDU Header + CRC Creation MPDU Header + CRC Validation A-MPDU Aggregation A-MPDU De-aggregation (PHY SAP) *ETH (11be) allows Block ACK Scoreboarding split over MLD and Affiliated STA/AP PHY of Link Submission Slide 6 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 3. Replace trackable values with un-trackable OTA values (1/2) Goal: Over-the-air values cannot be correlated across Epoch boundaries Core (link-independent) fields: otaAID, otaPN, otaSN Still evaluating obfuscating TID. Per-Link fields: otaMAC (Address) Current proposal: UL & DL use identical values Expect negligible implementation impact if UL & DL use independent values Core fields otaAID, otaPN = PN + PN_Offset (mod 248), otaSN = SN + SN_Offset (mod 212), Analysis on XOR vs Addition in backup slides. Per-Link fields otaMAC, Random per-Epoch params: SN_Offset, PN_Offset, otaAID, Num Link x otaMAC Client and AP generate per-TIDSN_Offset, PN_Offset , otaMAC from KDK and epoch start time (TSF). otaAID is assigned & distributed by the AP. w/ otaAID changing randomly each Epoch w/ PN_Offset changing randomly each Epoch w/ per-TIDSN_Offset changing randomly each Epoch w/ otaMAC changing randomly each Epoch Submission Slide 7 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 4. Don t mix old and new at Epoch transitions (1/2) Suppose client has just transitioned from old Epoch to current Epoch In below scenarios, attacker determines old params & current params (for old & current Epoch) correspond to a single client = client frame tracking = !!! BAD !!!. Epoch Parameters = {SN_Offset, PN_Offset, otaAID, Num Link x otaMAC} 1. MPDU initial transmission (TX) & retransmissions (reTX) use mix of old & current params Fact: Initial transmission & retransmissions have identical encrypted payloads Detection: Attacker looks for retransmitted MPDUs by looking for MPDUs with identical encrypted payloads to previous transmissions while having differing values of PN, SN or otaMAC 2. MPDUs aggregated in an A-MPDU use mix of old & current params Fact: A-MPDU is always to or from a single client. Detection: Attacker looks for an A-MPDU with MPDUs using mix of old and new values for otaMAC 3. A-MPDU/MPDUs in a TXOP use mix of old & current params Fact: TXOP is always from a single client. Detection: Attacker looks for an TXOP with A-MPDU and/or MPDUs using mix of old and new values for otaMAC Note: additional concerns if Block ack reveals internal SN values (MAC SAP) RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) MSDU Flow - Transmitting PS Defer Queuing(AP MLD Only) (null) MSDU Flow Receiving Sequence Number Assignment (null) Replay Detection Per PN (optional) Packet Number Assignment Block Ack Buffering and Reordering per SN (null) MPDU Decryption MPDU Encryption Duplicate Detection per SN (null) Block Ack Scoreboarding PN, SN Obfuscation TID-to-Link mapping Link Merging PN, SN De-obfuscation (null) Block Ack Scoreboarding Address 1 Address Filtering MPDU Header + CRC Validation MPDU Header + CRC Creation A-MPDU De-aggregation A-MPDU Aggregation (PHY SAP) PHY of Link Submission Slide 8 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 4. Don t mix old and new at Epoch transitions (2/2) Requirements solving issues on previous slide (Primarily a retransmission problem) Retransmitted MPDUs use param (SN/PN Offsets, MAC, AID) from same epoch as original transmission. Then A-MPDU Aggregation & TXOP process old MPDUs separately from new MPDUs Block Ack carries obfuscated otaSN (not internal SN) TGbi Straw Poll indicatd support fo Soft Transition Concurrent new & old MPDUs. Additional state/stack for some functions to retransmit old MPDUs Client has 2 concurrent otaAID, halves max # clients an AP can support Submission Slide 9 Philip Hawkes, Qualcomm
May 2023 doc.: IEEE 802.11-23/0873r02 Conceptual Stack Diagrams for Soft Transition (MAC SAP) (MAC SAP) RX/TX MSDU Rate Limiting RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) A-MSDU Aggregation (TX) / De-aggregation (RX) PS Defer Queuing(AP MLD Only) PS Defer Queuing(AP MLD Only) (null) (null) Sequence Number Assignment (SN) (null) Sequence Number Assignment (SN) (null) Packet Number Assignment (SN,PN) (null) MSDU Flow Transmitting (STA) Packet Number Assignment (SN,PN) (null) MSDU Flow Transmitting (AP) MSDU Flow Receiving (STA) MSDU Flow Receiving (AP) Block Ack Buffering and Reordering per SN (SN,PN) Block Ack Buffering and Reordering per SN (SN,PN) (null) (null) MPDU Decryption (SN,PN) MPDU Encryption (SN,PN) MPDU Decryption (SN,PN) MPDU Encryption (SN,PN) Duplicate Detection per SN (SN,PN) Duplicate Detection per SN (SN,PN) (null) (null) Block Ack Scoreboarding (SN,PN) Block Ack Scoreboarding (SN,PN) TID-to-Link mapping (SN,PN) Link Merging (SN,PN) TID-to-Link mapping (SN,PN) Link Merging (SN,PN) Legend PN, SN De-obfuscation: otaPN = PN + PN_Offset, otaSN = SN + SN_Offset PN, SN De-obfuscation (per A1): PN = otaPN - PN_Offset/PN_Offset*, SN = otaSN - SN_Offset/SN_Offset* PN, SN De-obfuscation: otaPN = PN + PN_Offset, otaSN = SN + SN_Offset PN, SN De-obfuscation (per A2): PN = otaPN - PN_Offset/PN_Offset*, SN = otaSN - SN_Offset/PN_Offset* Existing function (11be) ETH Function MPDU Header +CRC Creation: otaSN, otaPN; A1 = otaMAC, A2 per Affiliated AP) BA Scoreboarding (otaSN, otaSN*) MPDU Header +CRC Creation: otaSN, otaPN; A1 per Affiliated AP, A2 = otaMAC) BA Scoreboarding (otaSN, otaSN*) New (11bi) Function A2 Address Filtering (A2) A2 Address Filtering (A2 = otaMAC, otaMAC*) 11bi field ('*' indicates using old 11bi params) A1 Address Filtering (A1 = otaMAC, otaMAC*) A1 Address Filtering (A1 = per Aff AP) MPDU Header + CRC Validation Block Ack & ReTx (otaSN) ReTx* (otaSN*) MPDU Header + CRC Validation Block Ack & ReTx (otaSN) ReTx* (otaSN*) 11bi obfuscation parameter A-MPDU Aggregation A-MPDU Aggr* A-MPDU De-aggregation A-MPDU Aggregation A-MPDU Aggr* A-MPDU De-aggregation Duplicate of existing function to handle retransmissions using old 11bi params TXOP TXOP* TXOP TXOP TXOP* TXOP (PHY SAP) (PHY SAP) PHY of Link PHY of Link Downlink (AP = TX-er, STA = RX-er) Uplink (STA = TX-er, AP = RX-er) Submission Slide 10 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 5. Generate per-epoch params from KDK: minimize AP input Preference is to avoid relying on AP to generate good random values Overview only here - details in future contribution AP & client generate CFTC params from KDK, epoch start TSF & minimal additional AP input Some privacy params have no additional AP input PN_Offset[47:0] generated from KDK, epoch start TSF SN_Offset[11:0] generated from KDK, epoch start TSF, direction bit (UL/DL), 4-bit TID Some privacy params have minimal additional AP input otaMAC[47:0] generated from KDK, epoch start TSF, 4-bit Link ID Expected number of collisions per epoch is less than 2-20. Unlikely to happen for a given AP, but always guaranteed to be happening somewhere due to number of AP! Still need a way to avoid collisions when they do occur Some privacy params completely determined by AP AID: For efficiency reasons, AP needs to keep AID within a small set while avoiding collisions. Needs to be coordinated by AP and communicated to client. Submission Slide 11 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 6. CFTC Epochs (Common across clients) (1/2) AP coordinates synchronizes all associated clients to transition together AP selects common epoch start TSF, per-client AID & other params (details in future) AP unicasts to clients - AP can pre-prime clients, even multiple Epochs in advance AP & clients generates other CFTC params from KDK & epoch start TSF Advantages Synchronizing epochs across all associated clients provides more privacy If a single client changes CFTC parameters, then attacker easily tracks that client across epoch boundary This is less of an advantage when an attacker makes only infrequent observations of the BSS Using TSF means no real-time signaling is needed at time of change (can pre-prime clients). Disadvantage: Client can t control how often CFTC parameters change. Individual control must be balanced against advantage of not standing out in the crowd Submission Slide 12 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 6. CFTC Epochs (Client Specific) (1/2) NEW Slide A client can initiate an AP transition at a client-specific epoch start time TSF AP or client can select epoch start TSF AP selects AID & other params (details in future) AP & Client derive other CFTC params from KDK, epoch start time (details in future) Advantages Client can control how often CFTC parameters change Using TSF means no real-time signaling is needed at time of change (client is pre-primed) Disadvantages Attacker easily tracks client across client-specific epoch boundary Submission Slide 13 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 Review # 1 Guiding Principles Partition time into epochs Rationale Implications Prevent client frame tracking across epoch boundaries CFTC applied after encryption at TX (before decryption at RX) Replace trackable values with OTA values un-trackable across epoch boundaries Don t mix old & new parameters at epoch transition Where possible, generate per-epoch params from KDK w/ minimal AP input Epochs can be common across associated clients, or client-specific Keep same processing (MLD MAC, A1, A2, A3, PN, TID, SN) Prevent tracking predictable fields across epoch boundary 2 Prevent tracking predictable fields across epoch boundaries Per-epoch params controlling replacement/modification 3 Consider retransmissions, TXOP A-MPDU aggregation, Soft transition, short period with reTX of old & TX of new frames 4 Minimal reliance on AP assigning good random values Avoid conflicts in OTA AID & MAC Address (details in future) 5 Synch transition = better privacy AP can pre-prime clients, even multiple epochs in advance 6 Submission Slide 14 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 BACKUP SLIDES Submission Slide 15 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 Rough calculation of expected number of collisions Model: AP with 212 clients with 4 links each Expected number of collisions per epoch ~ (# pairs of otaMAC addresses in BSS) x 1/(# available MAC addresses) # pairs of otaMAC addresses in BSS ~ (# otaMAC addresses in BSS)2/2 # otaMAC addresses in BSS = #clients x # links per client 212 x 4 = 214 # pairs of otaMAC addresses in BSS (214)2/2=227 # available MAC addresses = 248 Expected number of collisions per epoch 227 x 1/248 = 227-48 = 2-21 Submission Slide 16 Philip Hawkes, Qualcomm
July 2023 doc.: IEEE 802.11-23/0873r02 3. Replace trackable values with un-trackable OTA values (2/2) Why Addition instead of XOR for SN/PN? Security XOR: otaSN[i] = SN[i] R for a secret value R reveals at least part of SN[i]. Exercise: Take an incrementing sequence for SN[i] starting at a random value e.g. 5 {5,6,7 etc.}, Compute otaSN[i] = SN[i] R a random value R to each value in SN[i] Now look at sequence [i] = otaSN[i] otaSN[i+1]. [i] has form of zero or more 0 bits followed by one or more1 bits in the LSbs, e.g. [i] 0..01111. If [i] is 1 in j LSbs, then SN[i] is 1 in (j-1) LSbs 1. e.g. [i] 0..01111 SN[i] =?...?111. Addition: otaSN[i] = SN[i] + R (mod 212) for a secret value R does not reveal SN. otaSN is still an incrementing sequence, but you can t recover SN Same applies for PN Block Ack If using otaSN[i] = SN[i] R then otaSN[i] is not an incrementing sequence. Receiver would need to recover SN[i] prior to performing Block Ack If using otaSN[i] = SN[i] + R (mod 212) then otaSN[i] is an incrementing sequence: Block Ack can use otaSN[i]without recovering SN[i] (faster). Submission Slide 17 Philip Hawkes, Qualcomm
