MBMS introduces the concept of a point-to-multipoint service into a 3GPP system. A requirement of a MBMS User Service is to be able to securely transmit data to a given set of users. In order to achieve this, there needs to be a method of authentication, key distribution and data protection for a MBMS User Service.
Figure above gives an overview of the network elements involved in MBMS from a security perspective. Nearly all the security functionality for MBMS, except for the normal network bearer security, resides in either the BM-SC or the UE. The BSF is a part of GBA. The UE and the BM-SC use GBA to establish shared keys that are used to protect the point-to-point communication between the UE and the BM-SC.
The BM-SC is a source for MBMS data. It could also be responsible for scheduling data and receiving data from third parties (this is beyond the scope of the standardisation work) for transmission. The BM-SC is responsible for establishing shared secrets with the UE using GBA, authenticating the UE with HTTP digest authentication mechanism, registering and de-registering UEs for MBMS User Services, generating and distributing the keys necessary for MBMS security to the UEs with MIKEY protocol and for applying the appropriate protection to data that is transmitted as part of a MBMS User Service. The BM-SC also provides the MBMS bearer authorisation for UEs attempting to establish MBMS bearer.
Prior to the introduction of MBMS, all UMTS security procedures were performed separately between each UE and the network. After mutual authentication, a shared secret was established between the UE and the network; this secret was then used to ensure the confidentiality and integrity of transmitted data by encrypting and digitally signing them, respectively. With MBMS, however, the same data may be delivered to many UEs over PtM bearers, therefore, confidentiality and integrity have to be achieved on a one to many basis. This means that the data source must share the same secret with many UEs. To prevent a UE from using this secret after leaving a service, the shared secret must be periodically updated.
Fortunately, the UMTS security architecture provides support for application level security by allowing a UE and an application server to establish a shared secret for use by any protocol they desire. For MBMS, the BM-SC is the entity responsible for generating and distributing shared keys to the UEs participating in a service . Since the BM-SC is also responsible for content distribution, it can use the appropriate keys to encrypt and/or digitally sign the content before transmission. As a result, integrity and confidentiality are achieved end-to-end between the BM-SC and the UEs, transparently to the UMTS network.
If a service employs MBMS security, this is indicated in its service announcement. As shown in Figure above, a UE that desires to receive such a service must first use the Generic Bootstrapping Architecture (GBA)  to establish a shared secret with the UMTS network for application specific purposes; this secret is then passed by the network to the BM-SC. At this point (first dashed line) the shared secret is used by both the UE and the BM-SC to derive two UE specific keys, the MBMS Request Key (MRK) and the MBMS User Key (MUK). The UE then initiates the User Service Registration procedure with the BM-SC, during which the two parties authenticate each other by using the MRK. If the UE has subscribed to the service, it is registered by the BM-SC as a key recipient. The UE then performs the MSK Request procedure, asking the BM-SC for the key of a specific MBMS service. The BM-SC sends this MBMS Service Key (MSK) to the UE with the MSK Delivery procedure, using the MUK to protect it (second dashed line). The BM-SC may periodically send a new MSK to the UE so as to invalidate older keys.
The actual content is protected by a service specific MBMS Traffic Key (MTK). This key is distributed as a part of the content itself, using the MSK to protect it; therefore, the MTK is transmitted over either a PtP or a PtM bearer to all UEs, unlike previous keys that were sent over PtP bearers to individual UEs. The MTK may also be periodically refreshed so as to invalidate older keys. Note that while the MRK and MUK are UE specific, the MSK and MTK are service specific and common to all UEs receiving a service; after the MSK is separately received by each UE protected by a MUK, it is used to recover the MTK received by all UEs. Each UE then uses the common MTK to decrypt the protected content.