Enhancing MMS Ranging Security in IEEE P802.15 Working Group
Explore the considerations for securing MMS ranging in the IEEE P802.15 Working Group project for Wireless Personal Area Networks. The document discusses security measures, interference mitigation, coexistence improvements, backward compatibility, and other advancements aimed at enhancing the overall functionality and security of wireless networks. Specific focus is placed on mechanisms for securing frames used in MMS ranging applications while ensuring reliability and interoperability in high-integrity ranging scenarios.
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
September 2023 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) doc.: < 15-23-0216-01-04ab > Submission Title: Secured frames for MMS ranging Date Submitted: 5 September, 2023 Source: Rojan Chitrakar, Lei Huang, Bin Qian, David Xun Yang (Huawei Technologies) Email: rojan.chitrakar@huawei.com Abstract: Considerations for security for MMS ranging. Purpose: Considerations for security for MMS ranging. Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Submission Slide 1 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > PAR Objective Proposed Solution (how addressed) Safeguards so that the high throughput data use cases will not cause significant disruption to low duty-cycle ranging use cases Interference mitigation techniques to support higher density and higher traffic use cases Other coexistence improvement Backward compatibility with enhanced ranging capable devices (ERDEVs) Improved link budget and/or reduced air-time Additional channels and operating frequencies Improvements to accuracy / precision / reliability and interoperability for high-integrity ranging Reduced complexity and power consumption Hybrid operation with narrowband signaling to assist UWB Mechanism to provide security for frames used for MMS ranging (NBA or UWB) Mechanism to provide security for frames used for MMS ranging (NBA or UWB) Enhanced native discovery and connection setup mechanisms Sensing capabilities to support presence detection and environment mapping Low-power low-latency streaming Higher data-rate streaming allowing at least 50 Mbit/s of throughput Support for peer-to-peer, peer-to-multi-peer, and station-to- infrastructure protocols Infrastructure synchronization mechanisms Submission Slide 2 Rojan Chitrakar, et al
September 2023 Background: Authenticated encryption with associated data (AEAD) Security Operation in 802.15.4-2020 AEAD encryption and authentication transformation (CCM* using AES-128) : 3 levels for Authentication and 3 levels for encryption are provided. The inputs are as follows: Key Nonce a data (AddAuthData: data to be authenticated) m data (PlaintextData: data to be encrypted) doc.: < 15-23-0216-01-04ab > The output is c data (Ciphertext + MIC) The Private Payload field of the original unsecured frame shall be replaced by the right-concatenation of that field and the c field if data confidentiality is not provided and shall be replaced by the c field otherwise Submission Slide 3 Rojan Chitrakar, et al
September 2023 Background: Authenticated encryption with associated data (AEAD) Security Operation in 802.15.4-2020 AEAD transformation and inverse transformation: The Nonce is constructed from the content of the MHR: doc.: < 15-23-0216-01-04ab > In TSCH mode, Absolute Slot Number (ASN) is used in Nonce instead of frame counter. Frame Counter is not present in the MHR. Submission Slide 4 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Discussion As explained earlier, 802.15.4-2020 already provides comprehensive AEAD security operation. We would like to reuse the existing AEAD operation for 802.15.4ab as much as possible for both NB and non-NB frames. Annex B mandates that within the scope of any encryption key, the nonce value shall be unique. Two formats of nonce are provided in 802.15.4-2020 : A key question is how to construct the variable field of the Nonce (Frame Counter or ASN), especially for compressed frames that do not carry a frame counter? 2 3 Octets: 1 0 or 3 1 variable Message Control RPA_hash CRC ID RPA_prand Message Content Submission Slide 5 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Revised proposal (compared to 23/216r0) Frames transmitted within Measurement Cycles (e.g., REPORT) may be secured. Nonce construction: The Source Address field is set as the extended address of the device originating the frame. The indices of the Block, Round, Slot in which a secured frame is transmitted or received is used as a frame counter to construct the nonce. Nonce Octets: 8 Bits: 0-7 8-23 24-39 Frame Counter (40 bits) Source Address Round Index Block Index Slot Index Nonce Uniqueness: In order to ensure the uniqueness of the nonce, the security Key should be updated every time the block structure is restarted (re-setup). The same security Key should not be used across multiple block structures. Submission Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Revised proposal Example (if an encrypted REPORT is transmitted in slot m, round 1 of block 1): Time offset Block 0 Block 1 Block 2 Block 3 Round 0 Round 1 Round n Round 0 Round 1 Round n Round 0 Round 1 Round n Round 0 Round 1 Round n ... ... ... ... ... Slot 0 Slot 1 Slot m ... Nonce Octets: 8 Bits: 0-7 8-23 24-39 Frame Counter (40 bits) Source Address Slot Index = m Round Index = 1 Block Index = 1 Submission Slide 7 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Block Structure synchronization To achieve block structure synchronization, initiator includes block and round indices in POLL messages. Poll 2 3 Octets: 1 3 1 variable Message Control RPA_hash CRC ID RPA_prand Message Content Octets: 0 or 2 0 or 2 BlockIndex RoundIndex Submission Slide 8 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Secured REPORT frame Secured REPORT frame can carry encrypted payload. Secured REPORT frame includes a Key ID field to indicate Key update. Encrypted REPORT CRC is replaced by the MIC 4/8/16 3 1 variable Octets: 1 Message Control Message Content MIC RPA_hash ID 0 or variable 0 or 4 Octets: 1 ID indicates a secured frame Encrypted Payload (RT or TAT) Unencrypted Payload (PT Data, PHY/MAC config etc.) PTDataLength Key ID of the key used to secure the frame (to indicate that key has been updated). 7 Bits: 0-6 Key ID Data Length Submission Slide 9 Rojan Chitrakar, et al
September 2023 doc.: < 15-23-0216-01-04ab > Summary We discussed enabling security for selected compressed frames (REPORT). We proposed: 1. The indices of the Block, Round, Slot in which a secured frame is transmitted or received is used as a frame counter to construct the nonce. 2. To achieve block structure synchronization, initiator includes block and round indices in POLL messages. 3. Secured frame includes a Key ID field to indicate Key update. Submission Slide 10 Rojan Chitrakar, et al
