Analysis of 802.16e Multicast/Broadcast

acceptableseashoreΑσφάλεια

5 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

77 εμφανίσεις

Analysis of 802.16e Multicast/Broadcast
group privacy keying protocol

Ju
-
Yi Kuo

CS259 Final Project

3 / 16 / 2006

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.

Protocol Overview (cont.)

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

MS 1

MS 2

MS 3

BS

CID 1

Group A

Group B

GSAID B

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.

MS

BS

CID , GSAID , Nonce , PN_U , MAC
MK_U

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.

CID , GSAID , Nonce , {GTEK}
GKEK
, GTEK
Params , {GKEK}
KEK

, GKEK Params , PN_D ,
MAC
MK_D

Protocol Overview (cont.)

Key Req / Rsp phase

KeyReq (unicast)

KeyRsp (unicast)

MS

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

GSAID , CountGTEK , {GTEK}
GKEK
, GTEK
Params , PN_D , MAC
MK_MBS

Protocol Overview (cont.)

Rekeying / Key Update phase

KeyUpd GKEK (unicast)

KeyUpd GTEK (multicast)

CID , GSAID , CountGKEK , {GKEK}
KEK

,
GKEK Params , PN_D , MAC
MK_D

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;

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.

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

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.

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;

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:

1.

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.


Analysis (cont.)

After adding PN, the 2 violations disappear

2.

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.

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.

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.