Analysis of 802.16e Multicast/Broadcast group privacy keying protocol

1. Analysis of 802.16e Multicast/Broadcast group privacy keying protocol Ju-Yi Kuo CS259 Final Project 3 / 16 / 2006

2. Protocol Overview • 802.16e defines a MAN that consists of fixed base stations (BS) and mobile station (MS) that can move at vehicular speed. • 802.16e includes an optional Multicast/Broadcast privacy keying spec for MBS. • Terminology: • MBS: Multicast/Broadcast service (optional in 802.16e) • GSA: group security association • GSAID: identification number for a GSA • MAK: MBS authorization key. A longer term secret shared by BS and all MS in a group. (default = 1 hour) • GTEK: group traffic encryption key (changes frequently) • GKEK: group key encryption key, for encrypting GTEK (changes less frequently than GTEK) • UL & DL: uplink to BS, downlink from BS.

3. MS 2 MS 3 MS 1 Protocol Overview (cont.) CID 1 BS GSAID B Group B Group A • A MS can subscribe to multiple groups • 2 kinds of communication • Unicast downlink and uplink • Multicast (downlink only) • CID: connection ID, identifying each pairwise unicast connection between MS and BS. Same value for both UL & DL • GSAID will identify the intended group of the multicast msg

4. Protocol Overview (cont.) • The protocol distributes GKEK & GTEK to members of a group. • There are 2 parts of the protocol: the key request/response phase, and the rekey/key update phase • The following are assumed before the protocol starts: • Each MS has been individually authenticated to BS. Each MS and the BS share a pairwise AK and a pairwise KEK (key encryption key). • The MS who intends to subscribe to a particular group has already received authorization from BS, and obtains the MAK which is shared by all authorized members of that group. • Group authorization is handled by other protocols and is outside the scope of this spec. • The way for a MS to leave a group is undefined. It should be handled by upper layer protocols and is outside the scope of this spec.

5. Protocol Overview (cont.) Key Req / Rsp phase BS • PN_U, PN_D: uplink and downlink packet number counter • MK_U, MK_D: uplink / downlink MAC Keys, derived from ( AK + BS & MS mac addresses + “Up” or “Down” ) • Key parameters include key lifetime (in seconds) & encryption suite. MS CID , GSAID , Nonce , PN_U , MACMK_U KeyReq (unicast) CID , GSAID , Nonce , {GTEK}GKEK , GTEK Params , {GKEK}KEK , GKEK Params , PN_D , MACMK_D KeyRsp (unicast)

6. Protocol Overview (cont.) Rekeying / Key Update phase BS • BS periodically rekey the group. If both keys need to be rekeyed, it first sends unicast GKEK update to each MS, and then multicast GTEK update to the whole group. It can also just rekey the GTEK thru the multicast KeyUpd. • CountGKEK, CountGTEK: key push counter for GKEK and GTEK. Increment by 1 for each generation of GKEK & GTEK’s • MK_MBS: MBS MAC Keys, derived from GKEK MS CID , GSAID , CountGKEK , {GKEK}KEK , GKEK Params , PN_D , MACMK_D KeyUpd GKEK (unicast) GSAID , CountGTEK , {GTEK}GKEK , GTEK Params , PN_D , MACMK_MBS KeyUpd GTEK (multicast)

7. The Security Goals • Secrecy of all KEK’s • Secrecy of GTEK and GKEK from MS’s outside the group • Secrecy of UL Mac Keys, DL Mac Keys, and MBS Mac Keys from MS’s outside the group • Membership Authentication • When MS is in operation mode or start mode, both MS and BS should agree on whether he is a member of the group or not. invariant "group membership consistency" forall gid: GSAID do forall msid: MSID do CHK_MEMBERSHIP & ( ms[msid].state[gid] = M_Operational | ms[msid].state[gid] = M_Start | ms[msid].state[gid] = M_RekeyInterWait ) -> bs.groupMembership[gid][msid] = ms[msid].inGroup[gid] end end;

8. The Security Goals (cont.) • Key Lifetime Integrity • The lifetime of a key cannot be prolonged by any message. • Key Parameter Integrity • Key parameters accepted cannot be different from what the BS requires. This prevents version rollback attacks. • Key Freshness • MS always accepts the new generation of keys that BS demands, never older generations that has been used before • Cross Group Security • Even if the intruder joins group A (but not group B), he is not able to use his Dolev-Yao capability to compromise the privacy of group B Security Goals Does Not Include: Compromised BS. BS is assumed to be honest. The intruder can impersonate the BS, but this is already covered by the secrecy of group key & MAC key & key parameter security goals above. Compromised MAK. Since MAK is long term secret and is never directly used to encrypt/decrypt, they are assumed to be secret.

9. The Modeling Details • Use murphi to model a slightly simplified version of protocol progressively. (key timeouts are not modeled here) • Assume Dolev-Yao intruder model as usual • The typical dimensions used in the Murphi model: • 1 base station, 2 mobile stations • 1 intruder • 2 groups • 2 generations of GKEK for each group • 2 generations of GTEK, per GKEK, per group • Each MS can join & leave a group 2 times max • MAC keys are modeled as nonces unique to each group, each MS, and msg type (Uni UL, Uni DL, MBS) • GKEK & GTEK are incrementing numbers, representing generations of keys

10. The Modeling Details (cont.) • Key Lifetimes are decrementing numbers • The intruder is modeled as 1 of the MS. A boolean constant defines whether he can join a group or not (maximum 1 group). The purpose of this design is to model cross group security. • The multicast message is modeled to be 1 message which contains a multiset of recipients. Only when all recipients have processed it and remove themselves from the multiset will the message be removed from the net. • Since it’s outside the scope, a MS leaving a group is modeled as an event that takes place instantly at a safe point. (not in the middle of rekeying) No message is passed. And when this happens, BS immediately sends KeyUpd message to rekey the whole group.

11. The Modeling Details (cont.) • Since it’s outside the scope, a MS leaving a group is modeled as an event that takes place instantly at a safe point. (not in the middle of rekeying) No message is passed. And when this happens, BS immediately enters rekey mode. This is reasonable because without knowing the details of the leaving, we can’t predict how it would behave. ruleset msid: MSID do ruleset gid: GSAID do rule "ms leaves a group" ms[msid].state[gid] = M_Operational & bs.state[gid] = B_Operational ==> begin ms[msid].state[gid] := M_Start; ms[msid].inGroup[gid] := false; bs.state[gid] := B_GKEKRekey; -- bs should be in rekey mode immediately bs.groupMembership[gid][msid] := false; end; end; end;

12. Analysis • Using the final murphi model, no violation was found. • Denial of Service analysis is done through spec inspection. No attack found. • During the progressive construction of the model, we found out that packet number plays an important role. Without PN, Murphi found the following 2 attacks: • KeyReq replay attack: • After MS leaves a group, the intruder can replay a recorded KeyReq message from MS. When BS receives it, it would accept MS into the group again without MS’s knowledge. If the group service is charged by the minute, then BS will start charging MS without MS’s permission.

13. Analysis (cont.) • KeyUpdGKEK replay attack • Before the current GKEK expires on a MS, the intruder can replay a previously recorded Key Update message. When the MS receives this it would accept it. Although the GKEK remains the same, the lifetime in the message would certainly be longer than the current lifetime. This could prolong the life of GKEK for a long time, and it could disturb MS’s operation to some degree. Also, if the key parameter is different in the replayed message, the MS would be fooled into accepting it and this could be a version rollback. • After adding PN, the 2 violations disappear

14. Analysis (cont.) • Also there is a DOS attack against BS if PN is not implemented • The intruder can replay previously recorded KeyReq messages. The BS would accept them since the MAC is correct, and then sends out KeyRsp messages. • The cost for intruder is storing the messages plus sending it over and over. The cost is small when amortized over many replays. • The cost for the BS is receiving msg, authenticating it, encrypting keys, MACing and sending. • The ratio of BS cost versus intruder cost increases over many replays.

15. Conclusions • The protocol seems to be secure on it’s own. • PN is 4 bytes. The spec says that before this counter wraps around, a new MAK should be negotiated. It is important to implement this, as PN is a critical security factor. • But what about when interoperating with other necessary protocols? • This is not a complete MBS protocol because the way to establish the MAK and to revoke a MS’s group membership are not precisely defined by the spec. • The details of revoking & rekey timing could be vulnerable. • Need to model them together in order to get a better picture about the security of the entire protocol suite. • Future work: cost based DOS analysis, analysis using protocol composition logic.