Multicast Key Management for IEEE 802.16n HR-Network
Document Number:
IEEE C802.16n-10/0012r1
Date Submitted:
2011-03-06
Source:
Joseph Chee Ming Teo, Jaya Shankar, Yeow Wai Leong, Hoang Anh Tuan,
Zheng Shoukang, Mar Choon Hock
E-mail: cmteo@i2r.a-star.edu.sg
Institute for Infocomm Research
1 Fusionopolis Way, #21-01, Connexis (South Tower)
Singapore 138632
*<http://standards.ieee.org/faqs/affiliationFAQ.html>
Re:
Call for contributions for 802.16n AWD
Base Contribution:
N/A
Purpose:
To be discussed and adopted by TG802.16n
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.
Copyright Policy:
The contributor is familiar with the IEEE-SA Copyright Policy <http://standards.ieee.org/IPR/copyrightpolicy.html>.
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 >.
Introduction

802.16n SRD specifies requirement for Enhancements to
Unicast and Multicast communication (Section 6.2.1)


HR-Network shall provide optimized MAC protocols for unicast and
multicast transmission to support applications of two-way communications
such as Push to Talk (PTT) service among a group of HR-MS.
Examples of applications to be used in PTT service include:






audio (e.g., speech, music)
video
still image
text (formatted and non-formatted)
file transfer
Use case scenario

Public Protection and Disaster Relief (PPDR)


Different Groups of Rescue teams (e.g. firemen and police officers) would
have to communicate with each other without/without backbone networks
Need for a common multicast key to encrypt/decrypt messages to prevent
eavesdroppers or impersonation of legitimate multicast group members.
Introduction

Multicast Key Management

Existing 802.16-2009 – Multicast & Broadcast Rekeying Algorithm
(MBRA)




Research papers highlighted that MBRA does not provide forward secrecy
and backward secrecy
Forward secrecy – leaving users still able to decrypt secure multicast
messages after leaving the group
Backward secrecy – joining users can decrypt secure multicast messages
sent before joining the group
The 802.16n SRD specifies

Section 6.1.4.2 Multicast key Management


HR-Network shall provide the security architecture that provides a
group of HR-MSs with authentication, authorization, encryption and
integrity protection.
HR-Network shall provide multicast key management for the group of
HR-MSs. The key shared within the group should be distributed
securely and efficiently. HR-Network should support the group
signaling procedure using multicast transmission for multicast key
management efficiently.
Introduction



Hence there is a need for enhanced multicast key
management compared to MBRA.
Multicast Key Management should address the forward and
backward secrecy issue.
Solution has to cover the various scenarios for secure
multicast communication without/without infrastructure
Use Case Scenarios

Initial Group Formation
Controller node can be either
HR-BS or an appointed HRMS (Denoted as HR-MSX if
HR-BS is not present)
Use Case Scenarios

Join Event
Currently not
addressed by
MBRA
Use Case Scenarios

Leave Event
Currently not
addressed by
MBRA
Details of Contribution

We proposed procedures for
 Initial Group Formation
 Join Event
 Leave Event
 Solution has to cover the various scenarios for
secure multicast communication without/without
infrastructure, i.e. solution has to be designed for



Infrastructureless – PKI based
Infrastructure – Pre-shared key based
The “controller” can be either HR-BS (if present) or
an appointed HR-MS (denoted HR-MSX) for PKI
approach.
Pre-shared key-based approach



Assumes that there is network infrastructure,
i.e. each multicast member (HR-MSi) shares a
unicast security key MSKi with the HR-BS.
Initial Group Formation Procedure used to
establish the Multicast key GTEK.
Join and Leave Procedures used to update
the GTEK to achieve backward and forward
secrecy.

Initial Group Formation Procedure – Pre-shared
key-based approach
Flow Diagram
HR-MSX/BS
HR-MSi
MulticastGrpInfo
Multicast_MSG_#1
Multicast_MSG_#2

Initial Group Formation Procedure –
Pre-shared key approach
Flow Chart
Initial Group Formation Procedure – Pre-shared key-based approach
Step 1: HR-BS sends the multicast group information message (MulticastGrpInfo message) to all potential
members of the multicast group comprising of HR-MSi for 1 ≤ i ≤ n, where MulticastGrpInfo =
MulticastGrpID|HR-BSAddr.
Step 2: Each HR-MSi for 1 ≤ i ≤ n first generates nonce NHR-MSi. Next, HR-MSi computes the MAC θHR-MSi
= MAC(MSKi|MulticastGrpID|THR-MSi|NHR-MSi|HR-BSAddr|HR-MSiAddr) and sends Multicast_MSG_#1
message to HR-BS, where Multicast_MSG_#1 = MulticastGrpID|THR-MSi|NHR-MSi|HR-BSAddr|HRMSiAddr|θHR-MSi.
Step 3: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSi for 1 ≤ i ≤ n. If
the verifications are correct, then HR-BS generates nonce NHR-BS, GTEK and computes θHR-MSi' =
MAC(MSKi|GTEK|NHR-BS|NHR-MSi|HR-BSAddr|HR-MSiAddr). HR-BS then encrypt and obtain ci =
EMSKi(GTEK, GTEK_lifetime, HR-MSiAddr, HR-BSAddr). Finally, HR-BS sends Multicast_MSG_#2
message to HR-MSi for 1 ≤ i ≤ n, where Multicast_MSG_#2 = MulticastGrpID|THR-BS|NHR-BS|HRMSiAddr|HR-BSAddr| NHR-MSi|ci|θHR-MSi'.
Step 4: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonces for freshness and
decrypts ci using MSKi and obtains GTEK and GTEK_lifetime. Next, each HR-MSi verifies θHR-MSi'. If the
verification is correct, then HR-MSi can commence secure multicast.
Join Procedure – Pre-shared key based approach

Flow Diagram
Join Procedure – Pre-shared key-based approach

Flow Chart
Join Procedure – Pre-shared key-based approach
Step 1: New mobile station HR-MSj first generates nonce NHR-MSj. Next, HR-MSj computes the MAC θHRMSj = MAC(MSKj|MulticastGrpID|THR-MSj|NHR-MSj|HR-BSAddr|HR-MSjAddr) and sends
Join_MG_MSG_#1 message to HR-BS, where Join_MG_MSG_#1 = MulticastGrpID| THR-MSj|NHR-MSj|HRBSAddr| HR-MSjAddr|θHR-MSj.
Step 2: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSj. If the
verifications are correct, then HR-BS generates nonce NHR-BS', GTEK' and computes θHR-BS =
MAC(GTEK'|NHR-BS'|HR-BSAddr|MulticastGrpID) and θHR-MSj' =MAC(MSKj|GTEK'|NHR-BS'|NHR-MSj|HRBSAddr|HR-MSjAddr). HR-BS then encrypt and obtain cj = EMSKj(GTEK', GTEK'_lifetime, HR-MSjAddr,
HR-BSAddr). HR-BS also encrypts using the existing GTEK and obtains c' = EGTEK(GTEK',
GTEK'_lifetime, HR-BSAddr, NHR-BS') Finally, HR-BS sends Multicast_Join_MSG_#2 message to HR-MSi
for 1 ≤ i ≤ n and Multicast_Join_MSG_#3 message to HR-MSj respectively, where Multicast_Join_MSG_#2
= MulticastGrpID|THR-BS'|NHR-BS'|HR-BSAddr| c'|θHR-BS and Multicast_Join_MSG_#3 = MulticastGrpID|THRBS'|NHR-BS'|HR-MSjAddr|HR-BSAddr|NHR-MSj|cj| θHR-MSj'.
Step 3a: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonce for freshness. If the
verifications are correct, then each HR-MSi decrypts c' and obtains the new GTEK', and GTEK'_lifetime.
Next, each HR-MSi verifies θHR-BS. If the verification is correct, then HR-MSi can commence secure
multicast.
Step 3b: HR-MSj first verifies the received timestamp and nonces for freshness. If the verifications are
correct, then HR-MSj uses MSKj to decrypt c_j and obtains GTEK' and GTEK'_lifetime. Next, HR-MSj
verifies θHR-MSj'. If the verification is correct, then HR-MSj can commence secure multicast.
Leave Procedure – Pre-shared key-based approach

Flow Diagram
Leave Procedure – Pre-shared key-based approach

Flow Chart
Leave Protocol – Pre-shared key-based approach
Step 1: HR-BS generates nonce NHR-BS', new group key GTEK' and computes θHR-MSi' =
MAC(MSKi|GTEK'|NHR-BS'|HR-BSAddr|HR-MSiAddr|MulticastGrpID) for 1 ≤ i != l ≤ n. HR-BS then uses
the shared key MSKi with the remaining HR-MSi for 1 ≤ i != L ≤ n to encrypt and obtain ci' =
EMSKi(GTEK',GTEK'_lifetime, HR-BSAddr, NHR-BS'). Finally, HR-BS sends Multicast_Leave_MSG_#1
messages to remaining HR-MSi for 1 ≤ i != L ≤ n, where Multicast_Leave_MSG_#1 = MulticastGrpID|THRBS'|NHR-BS'|HR-BSAddr|ci'|θHR-MSi'.
Step 2: Each remaining HR-MSi for 1 ≤ i != L ≤ n first verifies the received timestamp and nonce for
freshness. If the verifications are correct, then each remaining HR-MSi uses its shared key MSKi to decrypt
ci ' and obtains the new GTEK' and GTEK'_lifetime. Next, each remaining HR-MSi verifies θHR-MSi'. If the
verification is correct, then each remaining HR-MSi can commence secure multicast.
PKI-based approach



Uses the X.509 Certificates (defined in
Standards 802.16-2009)
Initial Group Formation Procedure used to
establish the unicast security key MSKi (with
each HR-MSi (multicast member) AND
Multicast key GTEK.
Join and Leave Procedures used to update
the GTEK to achieve backward and forward
secrecy. Also establish unicast security key
MSKj with new joining nodes.
Initial Group Formation Procedure – PKI-based approach

Flow Diagram
HR-MSX/BS
HR-MSi
MulticastGrpInfo
Multicast_MSG_#1
Multicast_MSG_#2
Initial Group Formation Procedure – PKI-based approach

Flow Chart
HR-MSX/BS sends the multicast group
information MulticastGrpInfo to all potential
members of the multicast group comprising
of HR-MSi for 1 <= i <= n
Each HR-MSi generates nonce, computes
the signature and sends
Multicast_MSG_#1 to HR-MSX/BS.
HR-MSX/BS verifies the received timestamps,
nonce, messages and MACs. If the verifications
are correct, HR-MSX/BS generates its nonce,
the GTEK and MSKi for 1 <= i <= n and
computes the MAC. HR-MSX/BS then encrypts
the secret keys using each HR-MSi’s public key,
computes the signatures for each message and
sends Multicast_MSG_#2 to each HR-MSi.
Each HR-MSi verifies the received
timestamp, nonces and signature. If the
verification is correct, each HR-MSi decrypts
and obtains MSKi, GTEK and their lifetimes.
Each HR-MSi then verifies the MAC and
commence secure multicast if the
verification is correct.
Initial Group Formation Procedure – PKI-based approach
Step 1: HR-MSX/BS sends the MulticastGrpInfo message to all potential members of the multicast group
comprising of HR-MSi for 1 ≤ i ≤ n, where MulticastGrpInfo = MulticastGrpID|HR-MSX/BSAddr|Cert(HRMSX/BS).
Step 2: Each HR-MSi for 1 ≤ i ≤ n first generates nonce NHR-MSi. Next, HR-MSi computes the signature σHRMSi = SIGN(MulticastGrpID|THR-MSi|NHR-MSi|HR-MSX/BSAddr|HR-MSiAddr) and sends
Multicast_MSG_#1 message to HR-MSX/BS, where Multicast_MSG_#1 = MulticastGrpID|THR-MSi|NHRMSi|HR-MSX/BSAddr|HR-MSiAddr |σHR-MSi|Cert(HR-MSi).
Step 3: HR-MSX/BS first verifies the received timestamps and nonces for freshness and the certificate
Cert(HR-MSi) and signature σHR-MSi for 1 ≤ i ≤ n. If the verifications are correct, then HR-MSX/BS
generates nonce NHR-MSX/BS, GTEK and MSKi for 1 ≤ i ≤ n and computes key confirmation/message
authentication code θHR-MSi = MAC(MSKi|GTEK|NHR-MSX/BS|NHR-MSi|HR-MSX/BSAddr|HR-MSiAddr). HRMSX/BS then uses HR-MSi's public key to encrypt and obtain ci = EHR-MSi_PK(MSKi, GTEK,
MSKi_lifetime, GTEK_lifetime, HR-MSiAddr, HR-MSX/BSAddr). Finally, HR-MSX/BS computes
signature σHR-MSi' = SIGN(MulticastGrpID|THR-MSX/BS|NHR-MSX/BS|HR-MSiAddr|HR-MSX/BSAddr|NHRMSi|ci|θHR-MSi) and sends Multicast_MSG_#2 message to HR-MSi for 1 ≤ i ≤ n, where Multicast_MSG_#2 =
MulticastGrpID|THR-MSX/BS|NHR-MSX/BS|HR-MSiAddr|HR-MSX/BSAddr|NHR-MSi|ci|θHR-MSi|σHR-MSi'.
Step 4: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonces for freshness and the
signature σHR-MSi'. If the verifications are correct, then each HR-MSi decrypts ci = EHR-MSi_PK(MSKi, GTEK,
MSKi_lifetime, GTEK_lifetime, HR-MSiAddr, HR-MSX/BSAddr) and obtains MSKi, GTEK,
MSKi_lifetime and GTEK_lifetime. Next, each HR-MSi verifies θHR-MSi. If the verification is correct, then
HR-MSi can commence secure multicast.
Join Procedure – PKI-based approach

Flow Diagram
Join Procedure – PKI-based approach

Flow Chart
Join Procedure – PKI-based approach
Step 1: New mobile station HR-MSj first generates nonce NHR-MSj. Next, HR-MSj computes the MAC θHRMSj = MAC(MSKj|MulticastGrpID|THR-MSj|NHR-MSj|HR-BSAddr|HR-MSjAddr) and sends
Join_MG_MSG_#1 message to HR-BS, where Join_MG_MSG_#1 = MulticastGrpID| THR-MSj|NHR-MSj|HRBSAddr| HR-MSjAddr|θHR-MSj.
Step 2: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSj. If the
verifications are correct, then HR-BS generates nonce NHR-BS', GTEK' and computes θHR-BS =
MAC(GTEK'|NHR-BS'|HR-BSAddr|MulticastGrpID) and θHR-MSj' =MAC(MSKj|GTEK'|NHR-BS'|NHR-MSj|HRBSAddr|HR-MSjAddr). HR-BS then encrypt and obtain cj = EMSKj(GTEK', GTEK'_lifetime, HR-MSjAddr,
HR-BSAddr). HR-BS also encrypts using the existing GTEK and obtains c' = EGTEK(GTEK',
GTEK'_lifetime, HR-BSAddr, NHR-BS') Finally, HR-BS sends Multicast_Join_MSG_#2 message to HR-MSi
for 1 ≤ i ≤ n and Multicast_Join_MSG_#3 message to HR-MSj respectively, where Multicast_Join_MSG_#2
= MulticastGrpID|THR-BS'|NHR-BS'|HR-BSAddr| c'|θHR-BS and Multicast_Join_MSG_#3 = MulticastGrpID|THRBS'|NHR-BS'|HR-MSjAddr|HR-BSAddr|NHR-MSj|cj| θHR-MSj'.
Step 3a: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonce for freshness. If the
verifications are correct, then each HR-MSi decrypts c' and obtains the new GTEK', and GTEK'_lifetime.
Next, each HR-MSi verifies θHR-BS. If the verification is correct, then HR-MSi can commence secure
multicast.
Step 3b: HR-MSj first verifies the received timestamp and nonces for freshness. If the verifications are
correct, then HR-MSj uses MSKj to decrypt c_j and obtains GTEK' and GTEK'_lifetime. Next, HR-MSj
verifies θHR-MSj'. If the verification is correct, then HR-MSj can commence secure multicast.
Leave Procedure – PKI-based approach

Flow Diagram
Leave Procedure – PKI-based approach

Flow Chart
Leave Procedure – PKI-based approach
Step 1: HR-MSX/BS generates nonce NHR-MSX/BS', new group key GTEK' and computes θHR-MSi' =
MAC(MSKi|GTEK'|NHR-MSX/BS'|HR-MSX/BSAddr|HR-MSiAddr|MulticastGrpID) for 1 ≤ i \!= L ≤ n. HRMSX/BS then uses the shared key MSKi with the remaining HR-MSi for 1 ≤ i != L ≤ n to encrypt and obtain
ci' = EMSKi(GTEK',GTEK'_lifetime, HR-MSX/BSAddr, NHR-MSX/BS'). Finally, HR-MSX/BS sends
Multicast_Leave_MSG_#1 messages to remaining HR-MSi for 1 ≤ i != L ≤ n, where
Multicast_Leave_MSG_#1 = MulticastGrpID|THR-MSX/BS'|NHR-MSX/BS'|HR-MSX/BSAddr|ci'|θHR-MSi'.
Step 2: Each remaining HR-MSi for 1 ≤ i != L ≤ n first verifies the received timestamp and nonce for
freshness. If the verifications are correct, then each remaining HR-MSi uses its shared key MSKi to decrypt
ci ' and obtains the new GTEK' and GTEK'_lifetime. Next, each remaining HR-MSi verifies θHR-MSi'. If the
verification is correct, then each remaining HR-MSi can commence secure multicast.
Key Derivation

GTEK Derivation




Used to encrypt data packets for multicast service and
shared amongst the HR-MSs in the multicast group
Randomly generated by HR-MSX/BS or from the
authentication server
Shall be encrypted using HR-MS’s public key , MSKi/MSKj
pre-shared key or existing GTEK in the Join protocol.
MSKi/MSKj Derivation





Key shared between HR-MSi/HR-MSj with Controller HRMSX/HR-BS.
Used as an encryption key and MAC key
Can be randomly generated by HR-MSX/BS in PKIapproach
Pre-established in the pre-shared key approach
Refreshed/rekeyed periodically to maintain key freshness.
Proposed text for IEEE802.16n AWD
[-------------------------------------------------Start of Text Proposal---------------------------------------------------]
Please refer to C80216n-11_0012r1.doc for proposed text.
[-------------------------------------------------End of Text Proposal---------------------------------------------------]
Conclusion and Misc

Proposed new Multicast Key Management protocols
for IEEE 802.16n networks





Initial Group Formation
Join Protocol
Leave Protocol
PKI-based approach
Pre-shared key based approach