1. Security Support for Multi-cast Traffic in M2M communication Document Number: IEEE C802.16p-10/0032 Date Submitted: 2011-03-07 Source: Inuk Jung, Kiseon Ryu, JinSam Kwak Email: inuk.jung@lge.cominuk.jung@lge.com LG Electronics Re: Call for contributions for the IEEE 802.16p Amendment working document Venue: IEEE Session #72 Base Contribution: IEEE 802.16p-10/0018 Purpose: To be discussed and adopted by TGp. Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: and.http://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/guides/opman/sect6.html#6.3 Further information is located at and.http://standards.ieee.org/board/pat/pat-material.htmlhttp://standards.ieee.org/board/pat

2. Overview of Grouping in M2M Assumptions A number of devices are grouped by some criteria Devices share a common M2M Group ID (MGID) To join a group, a device first must be network authorized Implies retrieval of MSK/PMK and successful authentication of TEK/CMAC Problem Statement If all devices are applying their local security suites for group data transmission, much burden will be passed to the BS since it has to encode multicast data with security suites of each device. Furthermore, such data is not multicast but unicast. However, security appliance cannot be abstracted for multicast data transmission since they may convey group configuration information, which may be critical to the deployed system, especially for M2M environments Objective Like a Group ID, a common group security key can help the BS and devices to encode/decode multicast data efficiently. This requires 1. a new Key hierarchy for generating Group Key related security parameters 2. Group Key update procedure 3. Group Key version indication method

3. Enhanced Multi-cast Security compared to 16e Possible factors for enhancement of 16e Multi-cast security Unencrypted PKM message Complicated Key Hierarchy PUSH based key update for key management In general, the security of 16m is an enhancement to 16e Key management is done locally (i.e. using key count for local update generation: local key derivation) However, there is no security mechanism for Multi-cast transmission in 16m Hence, an enhancement to the Multi-cast security mechanism is required, which should be based on 16m security, with consideration of 16e’s Multi-cast security feature (i.e. simplifying key hierarchy, enhanced key management, secured key exchange procedure)

4. Group Key Generation by BS BS acquires (i.e. from M2M server) or locally generates Group Master Key (GMK) For cell specific Group Security management, the BS may locally generate the GMK For cell common Group Security management, the BS may request the GMK from the M2M server From the GMK, the BS derives the GTEK (Group TEK) by the following function: GTEK = Dot16KDF(GMK, MGID, GTEK_COUNT | “GTEK”, ‘N’) Here, GTEK_COUNT indicates the version of the currently used GTEK, which the devices should apply to derive the GTEK. The update of the GTEK depends on the GTEK_COUNT Here, MGID is the M2M Group ID the AMS and GMK is associated with GTEK_COUNT Indication methods of GTEK The 2 LSB of GTEK_COUNT is the EKS (Encryption Key Sequence), which serves as indication of current GTEK version

5. Group Key Hierarchy GMK derived by BS through local generation or request to M2M servers Update seeds for GTEK Acquired from M2M server or locally generated by BS

6. Group Key Acquisition by device Device’s Group Key Acquisition A device first performs network entry at BS Device performs security key exchange, which for now follows IEEE802.16m security key procedure. After device is authorized & authenticated it performs group join procedure If device is accepted to join a group, BS informs the device about the groups MGID and its related Group security keys. These parameters are delivered using specific encrypted MAC management message. The following parameters may be included, MGID (M2M Multi-cast Group ID) GMK GTEK_COUNT For any group related data transmission, the device will use the Group security keys. This will require further concepts such as Group SAID mapping For example, combination of device specific security with Group security application

7. Group Key Acquisition Signaling Procedure BS locally generates GMK or acquires from M2M server

8. Group Key Update based on GTEK_COUNT When does GTEK need an update? Exhaustion of PN space Expiry of GTEK/GMK lifetime Mismatch detection of EKS or GTEK_COUNT Where is the update initiated? GTEK update is initiated by BS ONLY How is the update performed? If GMK still valid, the GTEK_COUNT should be incremented to update the GTEK Hence, in case of an update, the BS multicasts the incremented GTEK_COUNT value to its group There are several methods of informing an update of GTEK 1. Update for connected (active), devices using MAC message 2. Update for Idle mode devices, using Paging Advertisement message 3. Implicit update via data payload, using MAC PDU‘s EKS value and GTEK update using locally incremented GTEK_COUNT 4. Implicit update via data payload, using MAC PDU‘s EKS value, with explicit request of GTEK_COUNT to BS Each device, updates their TEK values using the GTEK_COUNT Each device should respond with an ACK checking the correct security appliance by the newly generated CMAC value

9. Text Proposal (1) – Key Derivation Insert the following texts and figure in 16p amendment document : --------------------------- Text Start --------------------------- 16.2.5 AAI Security … 16.2.5.5 Security Support for Multi-cast Traffic Security for Multi-cast traffic provides encryption and integrity protection of such data information for secure group informing and management. A common security key is used by devices within a group. 16.2.5.5.1 Key Derivation The key hierarchy defines what keys are present in the system for Multi-cast traffic and how keys are generated. The BS may derive the Group Master Key (GMK) from the M2M authentication server or generate it locally. The group traffic encryption key (GTEK) is derived directly from the GMK.

10. Text Proposal (2) – Key Derivation 16.2.5.5.1.1 GTEK Derivation The GTEK is the transport encryption key used to encrypt Multi-cast data The GTEK (Group Traffic Encryption Key) is derived based on the GMK (Group Master Key). The GMK is provided by the ABS during the network entry through the AAI- REG-RSP message, which also includes GTEK_COUNT and MGID. The GTEK derivation is done: GTEKi = Dot16KDF (GMK, MGID, GTEK_COUNT | ”GTEK”, 128), Where: GMK is the Group Master Key. GTEK_COUNT is a counter used to derive different GTEKs for the same GMK, the value of the counter is changed every time a new GTEK need to be derived within the time the same GMK is valid. MGID is the identifier of the group, which the AMS and GMK is associated with

11. Text Proposal (3) – Key Hierarchy 16.2.5.5.2 Key Hierarchy Figure N outlines the process to calculate the GTEK based on a GMK provided by the ABS.

12. Text Proposal (4) – Key Usage/Update 16.2.5.5.3 Key Usage 16.2.5.5.3.1 GTEK Usage The GTEK is used for encrypting DL multi-cast data by the ABS, which is also used for decrypting such DL multi-cast data by the AMS. Each GTEK has its own PN counter size of 22bits. 16.2.5.5.3.1 GTEK Update The GTEK update is triggered whenever GTEK is running out the relevant PN space. 16.2.5.5.3.2 Key Update during Location Update The AMS shall include its current GTEK_COUNT in the AAI_RNG_REQ message during location update to the ABS. If ABS detects that the AMS has an old GTEK_COUNT, the ABS shall include the current GTEK_COUNT of the GMK in the AAI_RNG_RSP message and send it to the AMS. Otherwise, no GTEK update will be performed. 16.2.5.5.3.3 Key Update during Handover During handover, the serving ABS shall include the new GTEK information via AAI- HO-MCD message, if the MGID of the AMS changes. If the MGID does not change for AMS, the serving ABS shall indicate that no change of GTEK is required. --------------------------- Text End ---------------------------