Enhancing Device Security in IEEE 802.11 Networks with ID Exchange Concept
"Explore the concept of secure device ID exchange in IEEE 802.11 networks, proposing encrypted unique identifiers to enhance security and privacy. The proposal extends existing protocols, allowing for encrypted ID exchange over secure or non-secure links. Learn about the background of Randomized and Changing MAC (RCM) and how it impacts device tracking. This proposal introduces the capability for APs to request IDs from STAs and vice versa, facilitating encrypted exchanges for enhanced security."
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. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
E N D
Presentation Transcript
Jan 2022 doc.: IEEE 802.11-22/0117r0 Secure Device ID Exchange concept Date: 2022-01-18 Authors: Name Luther Smith Affiliations Address CableLabs Phone +1-303-661-3055 email l.smith@cablelabs.com 838 Coal Creek Circle Louisville CO Submission Slide 1 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Abstract Proposal of enable the exchange an encrypted unique device identifier over secure or non-secure link This proposal is an extension to 11-21/1378 & 11- 21/1379r3 * Add additional field to MLME SAP primitives. * Modify MLME descriptions as defined in 11- 21/1379r3 Submission Slide 2 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Background Randomized and Changing MAC (RCM) has been introduced to increase user privacy and reduce the ability of device tracking MAC has been used by Wi-Fi technologies and services as the method to identify a device RCM impacts many services that made use of the MAC as the device identity Submission Slide 3 Luther Smith, CableLabs
Jan 2022 Allow an AP to request an ID from a STA and the STA to return the ID in an encrypted format This proposal expands the Client ID Query (11-21/1378 & 11-21/1379r3) proposal The exchange can happen over a non-secure or secure link The ID form is not defined but recommended to be unique to the device There is a requirement that a keypair rooted in the AP The keypair can be static or dynamically generated AP shares the public key with the STA for ID encryption, private key maintained by the AP and is used to decrypt the ID doc.: IEEE 802.11-22/0117r0 Submission Slide 4 Luther Smith, CableLabs
Jan 2022 Allows the STA to request information to share the STA ID in the encrypted form doc.: IEEE 802.11-22/0117r0 Unlike Client ID Query (11-21/1378 & 11-21/1379r3) proposal this would allow the STA to request a public key from the AP to enable the ID encryption. This is where the two proposal differ in flow. The STA send message to the AP which triggers the AP to start the request of STA ID This allows the STA to provide the ID pre-association Submission Slide 5 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Request Frame Format for AP (Modify from 11-21/1378) The Request frame allows an AP to query an associated STA for a unique identifier. Public key to be used to encrypt ID Category ID Query Action Octets: 1 1 Variable Submission Slide 6 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Response Frame Format (as defined in 11-21/1378) The Response Frame format allows the responding STA to indicate either that it will not provide an ID or that it will. The Response includes optional ID and TTL fields, if the STA decides to provide an ID. The Response includes a Length field to allow for variable sized ID, and extensibility for vendor specific information, etc. A Vendor Specific field is also included in the Response to allow vendor differentiation. Category ID Query Action Response Length ID TTL Vendor Specific (optional) (optional) (optional) Octets: 1 1 1 2 Variable 2 Variable Submission Slide 7 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Key Request Frame Format for STA The Key Request frame allows a STA request the AP to share public key for encrypting ID. This triggers the AP to start the ID Request flow. Category ID Query Action Octets: 1 1 Submission Slide 8 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Advertisement of Support for ID Query (as defined by 11-21/1378) An Extended Capability bit is proposed. The ID Query_Support bit set to 1 indicates that a STA can support an ID Query action frame. At a higher layer, a user may direct a STA to not share a permanent or semi-permanent identifier, so a STA may still decline to provide an ID even though it indicates support for the message. For example, such a decision might be based on the network being associated, and the level of trust in the networks provider(s). Submission Slide 9 Luther Smith, CableLabs
Jan 2022 doc.: IEEE 802.11-22/0117r0 Summary The device MAC has been used to identify a device, while MAC was not intended for this prepose, RCM has forced that the MAC cannot be used for device identification. There needs to be a secure way to share a device ID that eliminates that ability for 3rd parties to identify a device or trace a device beyond a BSS service area. By use of a keypair, the STA can use the public key to encrypt the ID and only the AP (holder of the private key) is able to decrypt the ID. The STA could still ignore the message or decline to provide a unique identifier. The AP could ignore the request from the STA to request the device ID The STA can provide the ID without need for solicited request. Submission Slide 10 Luther Smith, CableLabs
