FORM -2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL
Specification
(See Section 10 and rule 13)


SECURITY IN WIRELESS METROPOLITAN AREA NETWORKS (WMANs)
*■■■ TATA CONSULTANCY SERVICES LTD.,
an Indian Company of Nirmal Building, 9th floor, Nariman Point, Mumbai 400 021
Maharashtra, India


Field of the invention:
This invention relates to security in Wireless Metropolitan Area Networks (WMANs).
In particular, this invention envisages a novel way of securing communications in a WMAN based on IEEE 802.16e WiMAX standard.
Still particularly, this invention relates to design of a security mechanism for Multicast and Broadcast (MBS) communications in a WMAN based on IEEE 802.16e WiMAX standard.
Background of the Invention:
IEEE 802.16e standard for WMAN has a service for multicast and broadcast communications. This enables a Base Station (BS) to distribute data simultaneously to multiple Mobile Stations (MS) to reduce communication overhead. Broadcast messages in IEEE 802.16e standard are encrypted with a shared key between the MSs and the BS. Every member (MS) in a multicast group has the shared key and can decrypt traffic from the BS. Message authentication is also done using the same shared key. However, this mechanism has a vulnerability since every member of a multicast group 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. This vulnerability is serious because a malicious MS in a multicast group can disrupt communications from the BS to every MS of the
2

group by exploiting this security loophole. The present invention is an attempt to develop a defense mechanism to plug this vulnerability.
Summary of the invention:
In accordance with this invention there is provided an apparatus and method for securing multicast and broadcast communications in a wireless metropolitan area network based on WiMAX standard.
The Group Traffic Encryption Keys (GTEKs) are generated as part of a hash chain. The one-way property of the hash function is utilized to ensure security of the key generation and distribution process. The sender authentication is also done with a very low computational overhead.
The invention has O(l) (i.e. constant) overhead irrespective of the size of the multicast group. Moreover, it has low computing requirements both at the BS and the MSs. Although, the period without forward secrecy can be a bit long, this can also be reduced by key generation as and when an MS enters the multicast group.
Thus the present invention prevents distribution of forged key update command messages by an adversary in Multi-and Broadcast Service (MBS) and avoids the use of broadcast key updates.
Brief description of the accompanying drawings:
Figure 1 shows key generation by successive application of hash function
j

Figure 2 shows encryption at BS and decryption at MSs by GTEK hash chain
Detailed description of the invention:
The mechanism of multicast and broadcast communication in 802.1le standard in the prior art is known.
The current IEEE 802.16e standard has a service for Multicast and Broadcast communication. This enables a BS to distribute data simultaneously to multiple MSs. To secure the broadcast communication, IEEE 802.16e uses a common Group Traffic Encryption Key (GTEK) for traffic encryption and decryption. Every member of a multicast group must know this key. To share the GTEK between MSs and BS, two algorithms are used: (1) Key request/reply mechanism (this is mandatory) and (2) Multi-and Broadcast Rekeying Algorithm (MBRA) (this is 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 uninterrupted communication, an MS possesses two keys as is done in Traffic Encryption Key (TEK) management. An optional alternative to distribute keying material is to use MBRA. In this case, the keys are managed by the BS. If a key expires, the BS broadcasts one Key Update Command (KUC) message to all MSs. This saves a lot of bandwidth as GTEKs are updated very frequently. To encrypt the broadcast GTEK, a Group Key Encryption Key
4

(GKEK) is needed. The GKEK is updated not very frequently. It is distributed via a KUC message in a unicast manner encrypting every message by the MS-specific Key Encryption Key (KEK). If an MS has not received a new key within a pre-defined time, it requests keying material following the standard request/reply mechanism. This is also done if the authentication of a KUC message fails.
Broadcasted messages in IEEE 802.16e standard are encrypted symmetrically with a shared key. Every member of a multicast group has the key and thus can decrypt the traffic from the BS. Also message authentication is based on the same shared key. However, 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 more problematic is the distribution of the GTEKs when the optional MBRA is used. To transfer a GTEK to all group members, it is broadcasted but encrypted with the GKEK. Due to broadcasting, the GKEK must also be a shared key and every group members knows it. Thus an adversary group member can use it to generate valid encrypted and authenticated GTEK key update command messages and distribute its own GTEK. Every member would establish the adversary's key as the valid next GTEK. Subsequently, all traffic sent by the 'real' BS can no longer be decrypted by the MS. From an MS'-s point of view, only the traffic from the adversary is valid. To 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
5

GTEK. Therefore, in order to succeed, an adversary MS just needs to send a GTEK update command message after the BS has broadcasted a GTEK update message. If the implementation follows the standard, 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 group members do accept the 'real' BS's GTEK update command, the adversary MS can send 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 MSs in the group. At this point, the adversary MS will send its own GTEK update command message which will certainly be accepted.
In 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. Since the MBS is only unidirectional, the BS cannot detect that MS has different GTEKs.
The current invention prevents distribution of forged key update command messages by an adversary in MBS. For this purpose, broadcast key updates are avoided. The GTEKs are generated as part of i\ 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. Figure 1 of the accompanying drawings depicts this process. To achieve this chained
6

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-specific key. This is depicted in Figure 2 of the accompanying drawings. When 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 succeeds, the current GTEK is overwritten and the received key is accepted as the next valid key. If the authentication fails, the MS discards the message and requests a new GTEK via the unicast request/reply mechanism.
In accordance with the present invention, the 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 the keys. Therefore, only a little modification is rjecessary in the existing standard. Additionally, the GTEK state machine at BS must generate the 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. 'fhe scheme has a reduced forward secrecy. Therefore, even though an MS, on joining a multicast group, can decrypt all broadcasted data since the last chain generation, the amount of data it can decrypt is less due to frequent updation of the key. However, if the forward secrecy is crucial, the hash chain has to be generated each time an MS enters the group.
7

The invention has constant (0(1)) message overhead and low computing requirements both as the BS and the MSs. Although, the period without forward secrecy may be long, this can be reduced by key regeneration as and when a new MS enters a multicast group.
Although the invention has been described in terms of particular embodiments and applications, one of ordinary skill in the art, in light of this teaching, can generate additional embodiments and modifications without departing from the spirit of or exceeding the scope of the chained invention. Accordingly, it is to be understood that the drawings and descriptions herein are offered by way of example to facilitate comprehension of the invention and should not be construed to limit the scope thereof.