IEEE C802.16m-08/892r2
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Secure and Robust Multicast and Broadcast Services in 802.16m
Date
Submitted
2008-09-18
Source(s)
Jaydip Sen
Tata Consultancy Services
Kolkata, INDIA
Nadeem Akhtar
CEWiT
Chennai, INDIA
Re:
Jaydip.Sen@tcs.com
nadeem@cewit.org.in
IEEE 802.16m-08/033, Call for Contributions and Comments on Project 802.16m System Description
Document (SDD) (2008-08-01)
Proposed 802.16m Security Enhancement
Abstract
The document proposes a mechanism for secure Multicast and Broadcast Services for 802.16m
Purpose
Request consideration of functionalities contained herein for the 802.16m SDD
Notice
Release
Patent
Policy
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.
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.
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>.
IEEE C802.16m-08/892r2
Secure and Robust Multicast and Broadcast Services in 802.16m
1. Introduction
The Multicast and Broadcast service enables a Base Station (BS) to distribute data simultaneously to multiple Mobile Stations (MSs).
The broadcast communication, can be secured using a common Group Traffic Encryption Key (GTEK) for traffic encryption and
decryption. Every group member must know this key. To share the GTEK between MS and BS two algorithms are used: (1) Key
Request/Reply mechanism (mandatory) and (2) Multi- and Broadcast Rekeying Algorithm (MBRA) (optional).
In the standard request/reply mechanism an MS itself has to manage the GTEK update. This means that an MS has to request a new
keying material if the current key expires. Such a key request triggers a unicast key response from the BS which includes a new key.
To ensure an uninterrupted communication an MS possesses two keys similar to the Traffic Encryption Key (TEK) management. An
optional alternative to distribute keying material is to use Multi- and Broadcast Rekeying Algorithms (MBRA). In this case, the keys
are managed by the BS. If a key expires, the BS broadcasts one Key Update Command message to all MSs. This saves a lot of
bandwidth as GTEKs are updated very frequently. To encrypt the broadcasted GTEK, a Group Key Management Key (GKEK) is
needed. This GKEK is updated not very frequently. It is also distributed by a Key Update Command message but in a unicast way
encrypted by the MS-related KEK. If a MS has not received a new key after a pre-defined time, it requests keying material following
the standard request/reply mechanism. This is also done if the authentication of a Key Update Command message fails.
2. Security Vulnerability in Multicast and Broadcast Service (MBS)
By encrypting the GTEK symmetrically with a shared key, every member in the group has the key and thus can decrypt t
he traffic. Also message authentication is based on the same shared key. This algorithm has a vulnerability as every group
member, in addition to having the ability to decrypt and verify the broadcast messages, can also encrypt and authenticate
messages as if they originate from the ‘real’ BS.
Another aspect which is much more problematic is the distribution of the Group Traffic Encryption Keys (GTEKs) when th
e optional Multi- and Broadcast Rekeying Algorithm (MBRA) is used. To transfer a Group Traffic Encryption Key (GTEK)
to all group members, it is broadcasted but encrypted with the Group Key Encryption Key (GKEK). Due to broadcasting,
the GKEK must also be a shared key and every group member knows it. Thus an adversary group member can use it to
IEEE C802.16m-08/046
generate valid encrypted and authenticated GTEK key update command messages and distribute its own GTEK.
Every group member would establish the adversary’s key as the valid next GTEK. Subsequently all traffic sent by the ‘rea
l’ BS can no longer be decrypted by any MS. From an MS’s point of view, only the traffic from the adversary is valid. T
o force MSs to establish the adversary’s key, there are several possibilities. If the implementation does not work properly, a
new GTEK update command will simply overwrite the previous GTEK. Therefore, in order to succeed, an adversary MS j
ust needs to send a GTEK update message after the BS has broadcasted a GTEK update message.
If the implementation follows the standard, the both the GTEK update commands sent by the ‘real’ BS and the adversary
MS will be accepted by other members in the group. Thus, the adversary MS will not succeed that easily. In this case, in
order to make sure that other groups members do accept the real BS’s GTEK update command, the adversary MS can se
nd a forged key update message partially modifying the message previously sent by the real BS. Such an update will fail
authentication and will result in rejection at the other group members. At this point, the adversary MS will send its own G
TEK update command message which will certainly be accepted.
In a unicast connection, this different keying material at the MS would be detected as the BS cannot decrypt data sent by
the MS. This will result in a TEK invalid message destined to the MS which subsequently refreshes its keying material. Si
nce the MBS is only unidirectional, the BS cannot detect that MS has different GTEKs.
3. Proposed Security Mechanism
The proposed security mechanism prevents distribution of forged key update command messages by an adversary in Multi- and
Broadcast Service.
For this purpose, broadcast key updates are avoided. The GTEKs are generated as part of hash chain.
The BS
first generates a random number which represents the initial key GTEK0. The other GTEKs are generated by applying a one way
function to the previous GTEKs. This hash chain enables verification of each GTEK by application of the same one way function to
the previous GTEK. To achieve this chained authentication, the last GTEK has to be distributed to each MS in a secure way as it is the
only key in the chain which cannot be authenticated by any verification mechanism. One possibility is to distribute GTEKn in the
GKEK update command message which is a unicast message and encrypted by an MS-related key. If an MS receives a new GTEK via
a broadcasted GTEK update command message, it can verify its integrity by applying the one way hash function. If the authentication
3
IEEE C802.16m-08/046
succeeds, the current GTEK can be overwritten and the received key is accepted as the valid key. If the authentication fails, the MS
discards the message and requests a new GTEK via the unicast Request/Reply mechanism.
GTEK0 = random ( )
GTEK1 = f (GTEK0)
GTEK2 = f(GTEK1)
..................................
GTEKn = f (GTEKn-1)
To apply this algorithm, the key GKEK update command message has to be capable of transporting GKEK and GTEK keys together.
The design of the key update command message already includes both keys. Therefore, only a little modification is necessary.
Additionally, the GTEK state machine at BS must generate the GTEK hash chain and store all the keys. The GTEK state machine at
the MS must add the functionality to authenticate GTEKs by computing the hash function and comparing it to the previously
generated key. The scheme has a reduced forward secrecy. This means a MS, joining the group can decrypt all broadcasted data since
the last chain generation. If the forward secrecy is crucial, the hash chain has to be regenerated each time a MS enters the group.
The proposed security mechanism has O (1) (i.e. constant) message overhead, low computing requirements both at the BS and the
MSs. Although, the period without forward secrecy can be long, this can also be reduced by key regeneration as and when an MS
enters the multicast group.
4
IEEE C802.16m-08/046
Figure 1: Encryption at BS and decryption at MSs by GTEK hash chain
4. Text Proposal
[---------------------------------------------------Start of Text Proposal-------------------------------------------------]
12 Security
[Insert the following subsection into Section 12]
12.x Secure Multicast and Broadcast Communication
To ensure a secure and efficient distribution of GTEK updates in a mulicast group, a scheme based on a
chain of hash function is used. At the beginning of the multicast communication, the GTEK is distributed in
a unicast manner alongwith the GKEK message. The subsequent GTEKs, computed based on the hash chain,
are broadcast to all the members in the same multicast group. The MSs can verify the validity of the GTEKs
5
IEEE C802.16m-08/046
by using the hash function. This prevents a malicious MS from communicating any false GTEK update
message to disrupt communication in the multicast group.
[---------------------------------------------------End of Text Proposal--------------------------------------------------]
6