PKMv2 supports strong protection from theft of multicast and broadcast service by encrypting MBS defined in the IEEE 802.16e amendment.
MBS requires a MBS GSA. It is the set of security information that multiple BS and one or more of its client SSs share but not bound to any MS authorization state to support secure and access-controlled MBS content reception across the IEEE 802.16 network. Each MBS capable of MS may establish a MBS SA during the MS initialization process. MBS GSAs shall be provisioned within the BS. A MBS GSA's shared information includes the cryptographic suite employed within the GSA and key material information such as MAKs and MGTEKs. The exact content of the Marin General Services Authority (MGSA) is dependent on the MGSA's cryptographic suite. As like any other unicast SAs, MBS GSA is also identified using 16-bit SAIDs. Each MS shall establish one or more MBS GSA with its serving BS. Using the PKMv2 protocol, an MS receives or establishes an MBS GSA's keying material. The BS and MBS content server must ensure that each client MS only has access to the MGSAs it is authorized to access. An SA's keying material (e.g., MAK and MGTEK) has a limited lifetime. When the MBS content server or BS delivers MBS SA keying material to an MS, it also provides the MS with that material's remaining lifetime. It is the responsibility of the MS to request new keying material from the MBS server or BS before the set of keying material that the MS currently holds expires at the MBS server or BS.
When the Multicast Broadcast Rekeying Algorithm (MBRA) is supported, the MBRA is used to refresh traffic keying material efficiently not for the unicast service, but for the multicast or the broadcast service.
Note that an SS may get the traffic keying material before an SS is served with the specific multicast service or the broadcast service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection. The GTEK is the TEK for multicast or broadcast service. Once an SS shares the traffic keying material with a BS, the SS does not need to request new traffic keying material. A BS updates and distributes the traffic keying material periodically by sending two key update command messages.
A BS manages the M&B (Multicast & Broadcast) TEK grace time for the respective GSA-ID in itself. The GSA-ID is the SA-ID for multicast or broadcast service. This M&B TEK grace time is defined only for the multicast service or the broadcast service. This parameter means time interval (in seconds), before the estimated expiration of an old distributed GTEK. In addition, the M&B TEK grace time is longer than the TEK grace time managed in an SS.
A BS distributes updated traffic keying material by sending two key update command messages before old distributed GTEK is expired. The usage type of these messages is distinguished according to the key push modes included in the key update command message. The purpose of the key update command message for the GKEK update mode is to distribute the GKEK. The key update command message for the GKEK update mode is carried on the primary management connection. A BS intermittently transmits the key update command message for the GKEK update mode to each SS to reduce the BS's load in refreshing traffic key material. The GKEK is needed to encrypt the new GTEK. The GKEK may be randomly generated in a BS or an ASA server.
A BS transmits the PKMv2 group key update command message for the GTEK update mode carried on the broadcast connection after the M&B TEK grace time starts. The aim of the key update command message for the GTEK update mode is to distribute new GTEK and the other traffic keying material to all SSs served with the specific multicast service or the broadcast service. This GTEK is encrypted with already transmitted GKEK.
An SS shall be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS shall check whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then an SS shall request a new set of traffic keying material a configurable amount of time, the TEK grace time, before the SS's latest GTEK is scheduled to expire.
If an SS receives two valid key update command messages and shares new valid GKEK and GTEK with a BS, then that SS does not need to request a new set of traffic keying material.
If an SS does not receive at least one of the two key update command messages, then that SS sends the key request message to get a new traffic keying material. A BS responds to the key request message with the key reply message. In other words, if an SS does not get valid new GKEK or GTEK, then the GTEK request exchange procedure initiated by an SS is executed.
An SS tries to get the GTEK before an SS is served with the specific service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection.
A BS must be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. That is, when GKEK has been changed a BS manages the M&B TEK grace time for the respective GSA-ID in itself. Through operation of its M&B TEK grace time, a BS shall push a new set of traffic keying material. This M&B TEK grace time is defined only for the multicast service or the broadcast service in a BS. This parameter means time interval (in seconds) before the estimated expiration of an old distributed GTEK. That is, the M&B TEK grace time is longer than the TEK grace time managed in an SS.
A BS distributes updated GTEK by using two key update command messages when the GKEK has been changed, or by using one (the second) key update command message otherwise, around the M&B TEK grace time, before the already distributed GTEK expires. Those messages are distinguished according to a parameter included in that message, "key push modes." A BS transmits the first key update command message to each SS served with the specific service before the M&B TEK grace time. The first key update command message is carried on the primary management connection. A BS intermittently transmits the first key update command message to each SS to reduce the BS's load for key refreshment. The purpose of the first key update command message is to distribute the GKEK. This GKEK is needed to encrypt the updated GTEK. The GKEK is also encrypted with the SS's KEK. The GKEK may be randomly generated in a BS or an ASA server.
A BS transmits the PKMv2 group key update command message carried on the broadcast connection after the M&B TEK grace time. The aim of the second key update command message is to distribute the GTEK to the specific service group. This GTEK is encrypted with transmitted GKEK before the M&B TEK grace time.
An SS must also be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS checks whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then the SS requests a new set of traffic keying material for the TEK grace time before the SS's latest GTEK is scheduled to expire.
 |
No comments:
Post a Comment