The security of MBMS provides different challenges compared to the security of services delivered over point-to-point services. In addition to the normal threat of eavesdropping, there is also the threat that it may not be assumed that valid subscribers have any interest in maintaining the privacy and confidentiality of the communications, and they may therefore conspire to circumvent the security solution (for example one subscriber may publish the decryption keys enabling non-subscribers to view broadcast content). Countering this threat requires the decryption keys to be updated frequently in a manner that may not be predicted by subscribers while making efficient use of the radio network. The stage 1 requirements for MBMS are specified in TS 22.146.
The Technical Specification covers the security procedures of the Multimedia Broadcast/Multicast Service (MBMS) for 3GPP systems (UTRAN, GERAN and E-UTRAN). MBMS is a 3GPP system network bearer service over which many different applications could be carried. The actual method of protection may vary depending on the type of MBMS application.
The following documents contain provisions, which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
TS 23.107: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture".
TS 26.237: "IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service; Protocols".
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply.
For the definitions of MBMS User Service refer to TS 22.246.
HDR:
the general MIKEY HeaDeR.
IMPI:
In the context of current specification IMSI is used in the format of IMPI as specified in GBA, cf. TS 33.220.
KEMAC:
A payload included in the MIKEY message, which contains a set of encrypted sub-payloads and a MAC.
Key Group:
A group of MSKs that are identified by the same Key Group part of the MSK ID. Key Group part is used to group keys together in order to allow redundant MSKs to be deleted.
MBMS Request Key: This key is to authenticate the UE to the BM-SC when performing key requests etc.
MSK:
MBMS Service Key: The MBMS Service key that is securely transferred (using the key MUK) from the BM-SC towards the UE. The MSK is not used directly to protect the MBMS User Service data (see MTK).
MTK:
MBMS Traffic Key: A key that is obtained by the UICC or ME by calling a decryption function MGV-F with the MSK. The key MTK is used to decrypt the received MBMS data on the ME.
MUK:
MBMS User Key: The MBMS user individual key that is used by the BM-SC to protect the point to point transfer of MSK's to the UE.
Salt key:
a random or pseudo-random string used to protect against some off-line pre-computation attacks on the underlying security protocol.
SEQl:
Lower limit of the MTK ID sequence number interval: Last accepted MTK ID sequence number interval stored within MGV-S. The original value of SEQl is delivered in the key validity data field of MSK messages.
SEQp:
The MTK ID, which is received in a MIKEY packet.
SEQu:
Upper limit of the MTK ID sequence number interval, which is delivered in the key validity data field of MSK messages.
(S)RTP Session:
The (S)RTP and (S)RTCP traffic sent to a specific IP multicast address and port pair (one port each for (S)RTP and (S)RTCP) during the time period the session is specified to exist. An (S)RTP session is used to transport a single media type (e.g. audio, video, or text). An (S)RTP session may contain several different streams of (S)RTP packets using different SSRCs.
All data variables in this specification are presented with the most significant substring on the left hand side and the least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring. Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0, the next most significant is numbered 1, and so on through to the least significant.