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
LG Electronics
Re:
Email: inuk.jung@lge.com
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:
<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 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


Problem Statement



Implies retrieval of MSK/PMK and successful authentication of TEK/CMAC
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.
2.
3.
a new Key hierarchy for generating Group Key related security parameters
Group Key update procedure
Group Key version indication method
Enhanced Multi-cast Security compared to 16e

Possible factors for enhancement of 16e Multi-cast security




In general, the security of 16m is an enhancement to 16e



Unencrypted PKM message
Complicated Key Hierarchy
PUSH based key update for key management
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)
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
Group Key Hierarchy

GMK derived by BS through local generation or request to M2M servers
Acquired from M2M
server or locally
generated by BS
Update seeds for GTEK
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
Group Key Acquisition Signaling Procedure

BS locally generates GMK or acquires from M2M server
Group Key Update based on GTEK_COUNT

When does GTEK need an update?




Where is the update initiated?


Exhaustion of PN space
Expiry of GTEK/GMK lifetime
Mismatch detection of EKS or GTEK_COUNT
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.
2.
3.
4.

Update for connected (active), devices using MAC message
Update for Idle mode devices, using Paging Advertisement message
Implicit update via data payload, using MAC PDU‘s EKS value and GTEK update using locally
incremented GTEK_COUNT
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
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.
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 AAIREG-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
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.
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 AAIHO-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 ---------------------------