Secure Multicast and Broadcast Communication in Broadband Wireless
23
Secure Multicast and Broadcast Communication in Broadband Wireless Networks Jaydip Sen Convergence Innovation Lab Tata Consultancy Services Ltd. Kolkata, INDIA
Transcript of Secure Multicast and Broadcast Communication in Broadband Wireless
Secure Multicast and Broadcast Secure Multicast and Broadcast
Communication in Broadband Wireless
Networks
Jaydip Sen
Convergence Innovation Lab
Tata Consultancy Services Ltd. Kolkata, INDIA
Agenda
• Network entry procedure for a mobile station in a broadband wireless network
• Current security framework in broadband wireless
• Security vulnerability in multicast and broadcast services (MBS)
• Proposed solutions
December 7, 2008
• Proposed solutions
• Comparative analysis of the proposed solutions
• Conclusion
Network Entry Procedure
• SS searches for DL map message of the BS which is broadcast periodically. This frame includes info about the initial ranging CID, which is associated with a timeslot where initial ranging process can be performed.
• Access to this common timeslot is defined on CSMA.
• SS increases its transmission power with each ranging request it sends on the initial ranging slot until it receives a response from BS. This response includes ranging adjustments and the basic and primary management CIDs which
December 7, 2008
ranging adjustments and the basic and primary management CIDs which reserve particular time intervals for the SS to send and receive management messages.
• After initial ranging is complete the basic capabilities for the connection are negotiated.
Current Security Framework in Broadband Wireless
• Authentication process follows. IEEE 802.16e provides simple RSA-authentication or EAP-based authentication.
• After authentication process, SS and BS set up a common authorization key (AK).
• A Key Encryption Key (KEK) is derived from the AK which is used to securely transfer further keys.
December 7, 2008
• A 3-way Traffic Encryption Key (TEK)-exchange for each data connection between BS and SS is executed for data traffic encryption.
• Each message is integrity-protected by means of a MAC digest and the transferred TEK is encrypted by KEK.
Current Security Framework in Broadband Wireless (contd..)
December 7, 2008
Current Security Framework in Broadband Wireless (contd..)
December 7, 2008
SS →BS: Cert(Manufacturer(SS)) SS →BS: Cert(SS) | Capabilities | SAIDBS →SS: RSA-Encrypt (Pub_Key (SS), AK) | Lifetime | SeqNo | SAIDList
Current Security Framework in Broadband Wireless (contd..)
December 7, 2008
Current Security Framework in Broadband Wireless (contd..)
December 7, 2008
Current Security Framework in Broadband Wireless (contd..)
• Traffic Encryption Key (TEK)
• TEK is generated by BS randomly
• TEK is encrypted with
– RSA (using SS’s public key)
– AES (using 128 bit KEK)
• Key exchange message is authenticated by HMAC- SHA 1
December 7, 2008
• Key exchange message is authenticated by HMAC- SHA 1
– Provides message integrity and AK confirmation
Current Security Framework in Broadband Wireless (contd..)
December 7, 2008
WiMAX Security Vulnerabilities
• Unauthenticated messages
• Unencrypted management communications
• Shared keys in multicast and broadcast service
December 7, 2008
Security Vulnerability in Multicast and Broadcast Service
• The multicast and broadcast service offers the possibility to distribute data to multiple SSs with one single message. This saves cost and bandwidth.
• Broadcast messages are encrypted with a shared key. Every member in the group has the key and can decrypt the traffic. Message authentication is also based on the same key.
• The scheme has the vulnerability that every group member can encrypt and authenticate messages as if they originate from the ‘real’ BS.
December 7, 2008
• Distribution of the Group Traffic Encryption Keys (GTEKs) is another problem when the optional Multicast and Broadcast Rekeying Algorithm (MBRA) is used. To transfer a GTEK to all group members, it is broadcast and encrypted with the Group Key Encryption Key (GKEK). Due to broadcasting, the GKEK must also be a shared key among all group members. An adversary group member can use it to generate valid encrypted and authenticated GTEK key update command messages and distribute his own GTEK.
• Every group member would take this as a valid next GTEK. Thus all communication from the ‘real’ BS can no longer be decrypted by the members of the group.
• The adversary forges some part of the BS’s GTEK update command message. Such a message would be detected as invalid at the SSs and would be discarded. At this stage, the adversary sends its GTEK update command message. This message gets accepted by all the members and the adversary successfully establishes his GTEK in the group.
Security Vulnerability in Multicast and Broadcast Service (contd..)
December 7, 2008
successfully establishes his GTEK in the group.
• In a unicast connection, these different keys at the SS would be detected as the BS cannot decrypt data sent by the SS. This results in a TEK invalid message destined to the SS which subsequently refreshes its key. Since the MBS is only unidirectional, the BS cannot detect that SS has different GTEKs.
Proposed Solutions: Shared Keys in MBS
• In MBS, the distribution of forged key update command messages by an adversary can be prevented.
• Solution proposed is to avoid broadcast key updates. GTEK update command message is sent to each SS in a unicast way like the GKEK update command message. The GTEK is encrypted with the SS-specific KEK which is only known to that SS.
• Compared with Request/Reply algorithm this will save 50% of the bandwidth as no request message is necessary. The BS sends the GTEK update command message upon expiry of the life-time of the current key.
December 7, 2008
no request message is necessary. The BS sends the GTEK update command message upon expiry of the life-time of the current key.
• For higher security, a public key cryptography based mechanism may be used. GTEK update command message is broadcast and encrypted with the shared key GKEK but is additionally signed by an asymmetric signature. SS receives a GTEK update command message, verifies the signature of BS and decrypts the GTEK with the shared GKEK.
Proposed Solutions: Shared Keys in MBS (contd..)
Key Update Command GKEK
KEK (GKEK)
Key Update Command GTEK
KEK (GTEK)
BSSS
Key Update Command GKEK
KEK (GKEK)
Key Update Command GTEK
secBS (GKEK (GTEK) )
SS BS
December 7, 2008
Send GTEK to each SS individually encrypted by KEK
secBS (GKEK (GTEK) )
Broadcast GTEK and sign the encrypted key by the private
key of BS
Proposed Solutions: Shared Keys in MBS (contd..)
• For higher security, another option is to generate GTEKs as part of a hash chain. BS first generates a random number which represents the initial key GTEK0. The subsequent GTEKs are generated by applying a one way hash function to the previous ones.
GTEK0 = random ()
GTEK1 = f(GTEK0)
GTEK2 = f(GTEK1)
……………
GTEKn = f(GTEKn-1)
December 7, 2008
GTEKn = f(GTEKn-1)
• Each GTEK can be verified by applying the hash function to the previous GTEK.
• For secure authentication, the last GTEK is to be distributed to each SS. This can be done by sending the GTEKn in the GKEK update command message which is a unicast message and encrypted by either the public key of the SS or a shared key between the BS and SS.
Proposed Solutions: Shared Keys in MBS (contd..)
• When a SS receives a new GTEK by a broadcast GTEK update command message it verifies the integrity by applying the one-way hash function. If the verification yields positive results, the current GTEK is accepted. Otherwise, the SS discards the message and requests a new GTEK via a unicast Request/Reply mechanism.
• For this purpose, the GKEK update command message must have the capability for transporting GKEK and GTEK together. A modification in the current key update command message is necessary here.
December 7, 2008
• The GTEK state machine at BS should modified to have the capability to generate the GTEK hash chain and store all the keys. The GTEK state machine at the SS must have the functionality to authenticate GTEK keys by computing the hash function.
Proposed Solutions: Shared Keys in MBS (contd..)
Save GTEKn
Check if F(GTEKn-1)== GTEKn
Send GTEKn
Generate and save all GTEK values
Send GTEKn-1
Key Update Command GKEK
KEK (GKEK, GTEKn)
Key Update Command GTEK
GKEK (GTEKn-1)
Use for decryptionUse for encryption
December 7, 2008
F(GTEKn-1)== GTEKn
Save GTEKn-1
Check if F(GTEKn-2)== GTEKn-1
Save GTEKn-2
Send GTEKn-1
Send GTEKn-2
Key Update Command GTEK
GKEK (GTEKn-2)
Use for decryption
Use for encryption
SS BS
Comparison of the proposed solutions
• Traffic overhead– Unicast distribution of the key needs one key update message for each SS and has a
high traffic overhead.
– Asymmetric signature or hash-chain mechanism for GTEK transfer require only one message for all SS in a group and thus have a low overhead.
• Computational overhead– In unicast the SSs just have to verify the HMAC and save the keys. BS generates the
new keys using random function. All these involve less computing overhead.
– Hash chain mechanism requires SSs to compute the hash function and compare the
December 7, 2008
– Hash chain mechanism requires SSs to compute the hash function and compare the result with the received key. BS also needs to perform the same function. Less computation overhead involved.
– Asymmetric signature requires more computational overhead. Simulation has shown that time required to verify an asymmetric signature is 20 times more than that for a HMAC. Also the overhead at BS for signature generation is about 900 times than that for a HMAC. However, BS has much more computing power and an asymmetric signature is created only once per GTEK update of all SSs.
Comparison of the proposed solutions (contd..)
• Forward secrecy
– None of these propositions provide forward secrecy. For each of them, there is a time-period in which previously sent data can be decrypted by a SS which joins the group.
– For unicast and the asymmetric signature, this period is one GTEK lifetime. A SS that joins the group can decrypt all the traffic that was encrypted with the currently used GTEK.
December 7, 2008
the currently used GTEK.
– For hash chain, this period lasts for the lifetime of one complete chain. As the keys are computed sequentially with a known one-way hash function, a SS upon joining a group can easily compute all previous GTEKs in the current hash chain.
Comparison of the proposed solutions (contd..)
LowHighLowComputing requirements in SS
O(1) O(1) O(n) Introduced traffic( n = group size)
Hash chain authentication
Asymmetric signature
Exclusive unicasting
December 7, 2008
LongShortShortPeriod without forward secrecy
LowHighLowComputing requirements in BS
Conclusions
• A security vulnerability has been identified in wireless broadband communication network.
• Due to this vulnerability a potential intruder can distribute false key update message among the members of a multicast (or broadcast) group.
• Due to this false key update, communications from the base station to all the members in the group will be disrupted.
• Three possible solutions have been proposed to plug this vulnerability- Explicit
December 7, 2008
• Three possible solutions have been proposed to plug this vulnerability- Explicit unicasting, Asymmetric signature and Hash-chain authentication.
• The relative advantages and disadvantages of these approaches have been discussed. If forward secrecy can be reduced by frequent key update, hash-chain authentication mechanism is the best mechanism among the three approaches.
Thank You
December 7, 2008
