IEEE802.16e Security support for Group Management in M2M environment Document Number: IEEE S802.16p-10/0109 Date Submitted: 2011-05-08 Source: Inuk Jung, Kiseon Ryu, JinSam Kwak Email: inuk.jung@lge.com LG Electronics Re: Call for contributions for the IEEE 802.16p Amendment working document Venue: IEEE Session #73 Base Contribution: IEEE 802.16p-10/0018r1 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: <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>. Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

Overview of 802.16e Multi-cast traffic Problem Statement In IEEE802.16e, there are several secure ways of providing multi-cast service to a group of devices. MTK based multi-cast traffic encryption MTK is generated based on MGTEK MGTEK is distributed in unicast manner, which is overhead expensive for M2M environments MBRA for MBS service MBRA is a multi-cast key update method Not applicable for devices in Idle mode. Overhead wise, the full GTEK is multi-cast for update purpose. Unnecessary key encryption phase MGTEK is already a key for multi-cast traffic, which is not used for encrypting multi-cast traffic but is used only to derive MTK. Unnecessary complexity. Currently, the type of multi-cast service is mainly considered to be multi-media services. Thus, contents critical information for controlling groups of all M2M devices within a cell is not supported. In other words, multi-cast services is provided by a independent multi-cast server. This may not always be the case for M2M networks, where BS controls M2M devices in groups in terms of MAC procedures (e.g., network entry, grouping, scheduling (e.g., for ranging), etc). Also, full security key information (i.e., GTEK) is distributed with each key update (i.e., 128bits), which can be reduced to under 10 bits.

Necessity of Multi-cast Security A cell-based (i.e., BS) multi-cast security method has several benefits, over security support depending on a network server in upper network layers Flexibility of security provision in network BS takes care of multi-cast security updates and key distribution provided by the server Alleviates the servers’ burden of managing all the M2M groups Overhead reduction Multi-cast key is updated in broadcast manner

Signaling Procedure for M2MGTEK derivation M2MGTEK derivation procedure MAK is generated by higher layer and distributed to BSs BS unicast it to each MS within a multi-cast group the MAK and the M2MGTEK_COUNT, which is initially set to 0 This unicast message is encrypted with each MSs TEK for secure transmission Each MS that received this message, locally derives the M2MGTEK After M2MGTEK derivation, each MS acknowledges its derivation by a response-ACK message. This response-ACK message includes the derived M2MGTEK, M2MGTEK_COUNT and its multi-cast ID The procedures above are performed for each MS that joins a multi-cast group

Objective Multi-cast security of IEEE802.16e may be partially reused MBRA provides procedure for multi-cast based key update MAK may be reused as the master key input for generating MGTEK for M2M New multi-cast security parameters to be defined M2M Multi-cast key Parameters for local derivation of multi-cast key at MS side Key update procedure The update procedure and key provisioning procedure can be reused with some modification to the existing MBRA method Considering Idle mode devices Indication of key distribution or update through AAI-PAG-ADV message Overhead enhancement Local key update through change count values

Key derivation function MTK is used for MBS data traffic encryption. MGTEK is not used for encryption, hence one of them is unnecessary. Instead of generating MTK, MGTEK is sufficient for MBS traffic encryption. MGTEK is already defined and randomly generated by BS. Therefore we need to define a new Group TEK for M2M devices, which shall be derived by a Key Derivation Function (KDF)  we may call it “M2MGTEK” The GTEK for M2M multi-cast service is derived as follows: M2MGTEK = Dot16KDF(MAK, M2MGTEK_COUNT, Multicast CID | “M2MGTEK”, 128) Here, the MAK is generated by network side, which is outside the scope of IEEE802.16 standard Here, the M2MGTEK_COUNT indicates the version of the currently used M2MGTEK, which the devices should apply to derive the M2MGTEK. The update of the M2MGTEK depends on the M2MGTEK_COUNT Here, Multi-cast ID is the M2M Group ID

Generated from higher layer Key Hierarchy Generated from higher layer Update seeds for GTEK

Signaling Procedure for M2MGTEK update method For Active state devices: Upon the expiration of M2MGTEK or MAK lifetime or exhaustion of PN space, the network or BS initiates the M2MGTEK update procedure BS increments the current M2MGTEK_COUNT by one. The BS multi-casts the multi-cast security update command, which includes the following parameters M2MGTEK_COUNT – which is the incremented version of the current M2MGTEK_COUNT Also the current M2MGTEK_COUNT may be included in periodically broadcasted messages, such as MOB_NBR-ADV PKM-RSP message with different PKM codes and attributes Etc…

Signaling Procedure for M2MGTEK update method For Idle state devices: The device group associated with the multi-cast ID will expect to receive a multi-cast traffic at the Multi-cast Security Update Time (MSUT). The BS will multi-cast a multi-cast security update message at the MSUT time, encrypted with the current M2MGTEK, which includes the following parameters M2MGTEK_COUNT – seed for updating the M2MGTEK, which is the incremented M2MGTEK_COUNT value of the current version Devices that received the multi-cast security update message will derive the new M2MGTEK via the M2MGTEK_COUNT value, MAK and multi-cast ID The appliance instance, or time, of the update M2MGTEK may be defined as a predefined time during capability negotiation. Otherwise, the BS shall explicitly indicate the time in the some broadcast message (e.g., MOB_NBR-ADV, MOB_PAG-ADV)

Signaling Procedure for M2MGTEK update method For Idle state devices (continued): Upon the expiration of M2MGTEK or MAK lifetime or exhaustion of PN space, the network or BS initiates the M2MGTEK update procedure BS increments the current M2MGTEK_COUNT by one. The BS sets the ‘Action Code’ in the MOB_PAG-ADV message to 0b11 and transmits it to the devices Action Code 0b11: Receiving multi-cast traffic Action Code 0b11 implies that multi-cast traffic is scheduled at the ‘N’th frame from the frame where MOB_PAG-ADV is received. The ‘N’th frame is informed by the ‘Multi-cast traffic start time (MTST)’, which is included in the MOB_PAG-ADV only when Action Code is set to 0b11 The multi-cast ID (MCID) shall also be included, indicating that only devices that are party of the multi-cast ID shall receive the scheduled multi-cast traffic Also within the MOB_PAG-ADV, if Action code is set to 0b11, the 1bit ‘Multi-cast security key update’ parameter is included, which indicate whether the purpose of the scheduled multi-cast traffic is for updating the M2MGTEK If it is set to ‘1’ (i.e., TRUE), then the M2MGTEK_COUNT and update_time is included Where the M2MGTEK_COUNT serves as the seed for updating the M2MGTEK at the MS side Where update_time implies the appliance of the updated M2MGTEK