Security of a multimedia stream

A method including receiving encrypted multimedia information of a multimedia broadcast multicast service streaming session, wherein the multimedia information is encrypted using an encryption key. An indication allowing to switch the receiving of the encrypted multimedia information to a peer-to-peer streaming session is received and receiving of the encrypted multimedia information from the multimedia broadcast multicast service streaming session to the peer-to-peer streaming session is switched. Encrypted multimedia information of the peer-to-peer streaming session is received.

TECHNICAL FIELD

The present invention generally relates to security of the multimedia broadcast/multicast service (MBMS). The invention relates particularly, though not exclusively, to the key management for streaming and multicast to allow and enable content rendering and peer-to-peer content distribution of the multimedia broadcast/multicast service (MBMS).

BACKGROUND ART

Mobile broadcast solutions have been standardized by different organizations, such as the 3rd generation partnership project (3GPP) multimedia broadcast/multicast service (MBMS). 3GPP multimedia broadcast/multicast service (MBMS) enables resource-efficient delivery of multimedia content to the mobile users. A multimedia broadcast/multicast service (MBMS) client can receive content via download delivery, streaming delivery, a combination of streaming delivery and download delivery, and/or other delivery methods.

Multimedia broadcast/multicast service (MBMS) is a 3GPP Release 6 (Rel-6) feature, which may be deployed by network operators where it is cost efficient to have the broadcast/multicast distribution of content. When multimedia broadcast/multicast service (MBMS) subscribers move to other areas, where there is no multimedia broadcast/multicast service (MBMS) coverage, the network operator may distribute the multimedia broadcast/multicast service (MBMS) content in a unicast mode.

In the multimedia broadcast/multicast service (MBMS), there are two different modes of operation: Multicast mode, which comprises the following main phases of subscription: subscription, service announcement, joining, session start, MBMS notification, data transfer, session stop and leaving. Subscription establishes a relationship between the user and the service provider to allow the user to receive the related multimedia broadcast/multicast service (MBMS). The service announcement subsequently informs users about the available multimedia broadcast/multicast service (MBMS) user services. On joining, a subscriber indicates to the network that he or she desires to receive multicast mode data of a particular multimedia broadcast/multicast service (MBMS) bearer service. Next, the session start triggers for bearer resource establishment for multimedia broadcast/multicast service (MBMS) data transfer and after that the MBMS notification informs the user of available multimedia broadcast/multicast service (MBMS) multicast data transfer, which then occurs in the data transfer phase. Finally, when no more data has been sent for a set period, the session stops and the bearer resources are released. The subscriber may leave or deactivate the multimedia broadcast/multicast service (MBMS) multicast service when no more multicast mode service is desired. The user, the service provider or both may be charged for the multicast mode service. In the broadcast mode, in comparison to the multicast mode, the operation is otherwise similar but the joining and leaving are not needed. Correspondingly, the broadcast service is likely to be charged from the service provider only.

Multimedia broadcast/multicast service (MBMS) introduces the concept of a point-to-multipoint service into a 3GPP system. A requirement of a multimedia broadcast/multicast service (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 multimedia broadcast/multicast service (MBMS) user service. This means that multimedia broadcast/multicast service (MBMS) security is specified to protect multimedia broadcast/multicast service (MBMS) user services, and it is independent on whether multicast or broadcast mode is used.

With the explosive growth of media content consumption, the number of media servers to provide streaming services is required to be increased almost linearly with the number of users. In addition, centralized streaming media servers require considerable demands towards the bandwidth of the backbone IP network. So it is required to deploy more and more edge servers close to user equipments (UE) to guarantee service quality with the increasing number of users.

Peer-to-peer (P2P) technology can be used between edge servers and user equipments (UE) to relieve the above problem. Not only the edge servers handle the requests from its locally served user equipments (UE), but also they can handle the requests transferred from the neighboring edge servers. Similarly, if the user equipment's (UE) capabilities permit, the user equipment (UE) can offer spare uplink bandwidth and storage space while obtaining data, and uploads data to other requested destinations. Content is transmitted in a segmented manner, and most of the traffic can be spread across the edge of the network, which helps reduce the storage and bandwidth demands of centralized servers. Therefore, the system capability is improved along with the increasing number of edge servers and user equipments (UE).

SUMMARY

According to a first example aspect of the invention there is provided a method comprising:receiving an encrypted multimedia data of multimedia broadcast multicast service streaming session, wherein the multimedia data is encrypted using an encryption key;receiving an indication allowing to switch the receiving of the encrypted multimedia data to a peer-to-peer streaming session;switching receiving the encrypted multimedia data from multimedia broadcast multicast service streaming session to the peer-to-peer streaming session; andreceiving an encrypted multimedia data of the peer-to-peer streaming session.

In an example embodiment, the method comprises receiving a protected service key and the encryption key, wherein the encryption key is protected by the service key before switching of the receiving of the encrypted multimedia information from multimedia broadcast multicast service streaming session to the peer-to-peer streaming session.

In an example embodiment, the method comprises decrypting the multimedia information using the encryption key.

In an example embodiment, the method comprises generating a user key, unprotecting the protected service key using the user key, unprotecting the protected encryption key using the unprotected service key and decrypting the multimedia information using the encryption key.

In an example embodiment, the user key is derived from a ciphering key and an integrity key.

In an example embodiment, the switching of the receiving of the encrypted multimedia information from multimedia broadcast multicast service streaming session to the peer-to-peer streaming session is triggered in response to at least one of the following criteria:losing the broadcast multicast service streaming session;load balancing by mobile network operator.

In an example embodiment, the multimedia information comprises real-time streaming data or file download data.

In an example embodiment, the method comprises determining a lifetime of a time period for the encryption key during which time period the encryption key is valid for data decryption.

In an example embodiment, the method comprises extending the lifetime of the encryption key for the peer-to-peer streaming session.

In an example embodiment, the method comprises switching back from the peer-to-peer streaming session to the multimedia broadcast multicast service streaming session.

According to a second example aspect of the invention there is provided an apparatus comprising:at least one processor;at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:receive encrypted multimedia information of a multimedia broadcast multicast service streaming session, wherein the multimedia information is encrypted using an encryption key;receive an indication allowing to switch the receiving of the encrypted multimedia information to a peer-to-peer streaming session;switch receiving of the encrypted multimedia information from the multimedia broadcast multicast service streaming session to the peer-to-peer streaming session; andreceive encrypted multimedia information of the peer-to-peer streaming session.

In an example embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform:receive a service key and the encryption key, wherein the encryption key is protected by the service key before switching of the receiving of the encrypted multimedia information from multimedia broadcast multicast service streaming session to the peer-to-peer streaming session.

In an example embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform:decrypt the multimedia information using the encryption key.

In an example embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to further perform:derive encryption key from the protected encryption key by the service key.

According to a third example aspect of the invention there is provided a computer program embodied on a computer readable medium comprising computer executable program code which, when executed by at least one processor of an apparatus, causes the apparatus to perform:receive encrypted multimedia information of a multimedia broadcast multicast service streaming session, wherein the multimedia information is encrypted using an encryption key;receive an indication allowing to switch the receiving of the encrypted multimedia information to a peer-to-peer streaming session;switch receiving of the encrypted multimedia information from the multimedia broadcast multicast service streaming session to the peer-to-peer streaming session; andreceive encrypted multimedia information of the peer-to-peer streaming session.

Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.

Different non-binding example aspects and embodiments of the present invention have been illustrated in the foregoing. The above embodiments are used merely to explain selected aspects or steps that may be utilized in implementations of the present invention. Some embodiments may be presented only with reference to certain example aspects of the invention. It should be appreciated that corresponding embodiments may apply to other example aspects as well.

DETAILED DESCRIPTION

In the following description, like numbers denote like elements.

FIG. 1shows some details of the system architecture100. A typical 3GPP radio access system UTRAN (umts terrestrial radio access network) for implementing the multimedia broadcast/multicast service (MBMS) has a basic architecture as is illustrated inFIG. 1.FIG. 1depicts a plurality of user equipment (UE)11, within a predetermined service area12such as a cell, a plurality of radio network controllers (RNC)13, a plurality of base stations (Node B)24, a core network21, two serving GPRS support nodes (SGSN)14, two gateway GPRS support nodes (GGSN)15, a broadcast-multicast service centre (BM-SC)16, an operation and maintenance (O&M) workstation or server18, a charging gateway (CG)19, a generic bootstrapping server function (BSF)22and a content provider or multicast broadcast source20. As can be seen inFIG. 1, one user equipment (UE)11ais located outside the service area12without connection to the radio network controller13. However, such user equipment (UE)11amay be connected to other user equipment (UE)11over peer-to-peer (P2P) connection. Peer-to-peer (P2P) connections may also be established between user equipments (UE)11that are connected to the radio network controller (RNC)13.

The user equipments (UE)11may move in and out of a network service area offering good service coverage. When the user equipment (UE)11moves to the edge of the network service area12, the moving out may be prepared by the user equipment (UE)11and network. When moving out of the service area12, the user equipment (UE)11may provide service information to other user equipments (UE)11and request service information from other user equipments (UE)11.

On delivering multimedia broadcast/multicast service (MBMS) transmissions to numerous user equipments (UE)11, only one packet data protocol (PDP) context is established as a prerequisite for a packet data transmission connection17between a gateway GPRS support nodes (GGSN)15and user equipment (UE)11via a serving GPRS support node (SGSN)14. A single, common context suffices for transmission of data within a core network thanks to the point-to-multipoint approach.

A generic bootstrapping server function (BSF)22and the user equipment (UE)11shall mutually authenticate using the authentication and key agreement (AKA) protocol, and agree on session keys that are afterwards applied between user equipment (UE)11and a network application function (NAF). The network application function (NAF) is a functional module located in the broadcast-multicast service centre (BM-SC)16. Alternatively, if a legacy smart card is involved, transport layer security (TLS) and legacy authentication is used. Generic bootstrapping architecture (GBA) may also utilize other authentication mechanism, like hypertext transfer protocol (HTTP) digest or session initiation protocol (SIP) digest. Main functions of the network application function (NAF) module are service/user management (e.g., service subscription and unsubscription) and service key management (e.g., service key generation and delivery). The bootstrapping server function (BSF)22shall restrict the applicability of the key material to a specific network application function (NAF) by using a key derivation procedure. The key derivation procedure may be used with multiple network application functions (NAF) during the lifetime of the key material. The lifetime of the key material is set according to the local policy of the bootstrapping server function (BSF)22. The bootstrapping server function (BSF)22is allowed to fetch any required authentication information, security information and subscriber profile information from a home subscriber system (HSS)23. In legacy networks the bootstrapping server function (BSF)22may interact with the home location register (HLR) instead of the home subscriber system (HSS)23.

FIG. 2ashows different phases210to280of the multimedia broadcast/multicast service (MBMS) multicast provision. The phases subscription210, joining220and leaving280may be performed individually per user. The other phases may be performed for a service and thus for all users interested in the related service. The sequence of phases may repeat, depending for example on the need to transfer data. In addition, subscription210, joining230, leaving280, service announcement220as well as multimedia broadcast/multicast service (MBMS) notification250may run in parallel to other phases or in different order. For example, service subscription210may be done anytime before or after service announcement220.

Subscription210establishes a relationship between a user and a service provider, which allows the user to receive the related multimedia broadcast/multicast service (MBMS). Service subscription210is the agreement of the user to receive service(s) offered by the operator. Subscription information is recorded in the broadcast-multicast service centre (BM-SC)16, which may act as a network application function (NAF) in generic bootstrapping architecture (GBA).

Subscription information and other broadcast-multicast service centre (BM-SC)16functionality may be on separate entities. Service announcement220may allow users to request or be informed about the range of multimedia broadcast/multicast service (MBMS) user services available. This includes operator specific multimedia broadcast/multicast service (MBMS) user services as well as services from content providers outside of the operator network. Service announcement220is used to distribute to users information about the service, parameters required for service activation (e.g. IP multicast address(es)) and possibly other service related parameters (e.g. service start time).

Joining230(i.e. multimedia broadcast/multicast service (MBMS) multicast activation by the user) is the process by which a subscriber joins (becomes a member of) a multicast group, i.e. the user indicates to the network that he/she wants to receive multicast mode data of a specific multimedia broadcast/multicast service (MBMS) bearer service. A multimedia broadcast/multicast service (MBMS) user service may also be carried by more than one multimedia broadcast/multicast service (MBMS) bearer service. In that case, the multimedia broadcast/multicast service (MBMS) user service part in the user equipment (UE)11initiates the relevant multimedia broadcast/multicast service (MBMS) bearer services to receive the service. Session start240is the point at which the broadcast-multicast service centre (BM-SC)16is ready to send data. Session start240occurs independently of activation of the service by the user. Certain user may activate the service before or after session start240. Session start240is the trigger for bearer resource establishment for multimedia broadcast/multicast service (MBMS) data transfer. If a multimedia broadcast/multicast service (MBMS) user service is carried by more than one multimedia broadcast/multicast service (MBMS) bearer service, a session start message240is sent for each multimedia broadcast/multicast service (MBMS) bearer service. In that case, the user equipment (UE)11may need to initiate the reception of multiple relevant multimedia broadcast/multicast service (MBMS) bearer services to receive the multimedia broadcast/multicast service (MBMS) user service.

MBMS notification250informs the user equipments (UE)11about forthcoming (and potentially about ongoing) multimedia broadcast/multicast service (MBMS) multicast data transfer. Data transfer260is a phase when multimedia broadcast/multicast service (MBMS) data is transferred to the user equipment (UE)11. Session stop270is the point at which the broadcast-multicast service centre (BM-SC)16determines that there will be no more data to send for some period of time. This period is long enough to justify removal of bearer resources associated with the session. At session stop270, the bearer resources are released. Leaving280(i.e. multimedia broadcast/multicast service (MBMS) multicast deactivation by the user) is the process by which a subscriber leaves (stops being a member of) a multicast group, i.e. the user no longer wants to receive multicast mode data of a specific multimedia broadcast/multicast service (MBMS) bearer service.

FIG. 2bshows different phases215to255of the multimedia broadcast/multicast service (MBMS) broadcast provision. The sequence of phases215to255may repeat, e.g. depending on the need to transfer data. It is also possible that the service announcement215and MBMS notification235phase may run in parallel with other phases, in order to inform user equipments (UE)11, which have not yet received the related service. Service announcement215informs user equipments (UE)11about forthcoming multimedia broadcast/multicast service (MBMS) user services. The multimedia broadcast/multicast service (MBMS) user service part in the user equipment (UE)11initiates reception of the multimedia broadcast/multicast service (MBMS) bearer service to receive a multimedia broadcast/multicast service (MBMS) user service. In case one multimedia broadcast/multicast service (MBMS) user service is carried by more than one multimedia broadcast/multicast service (MBMS) bearer service, the user equipment (UE)11may need to initiate the reception of multiple relevant multimedia broadcast/multicast service (MBMS) bearer services to receive the multimedia broadcast/multicast service (MBMS) user service. Session start225is the point at which the broadcast-multicast service centre (BM-SC)16is ready to send data. Session start225is the trigger for bearer resource establishment for multimedia broadcast/multicast service (MBMS) data transfer. If a multimedia broadcast/multicast service (MBMS) user service is carried by more than one multimedia broadcast/multicast service (MBMS) bearer service, a session start225message is sent for each multimedia broadcast/multicast service (MBMS) bearer service. In that case, the user equipment (UE)11may need to initiate the reception of multiple relevant multimedia broadcast/multicast service (MBMS) bearer services to receive the multimedia broadcast/multicast service (MBMS) user service.

MBMS notification235informs the user equipments (UE)11about forthcoming (and potentially about ongoing) multimedia broadcast/multicast service (MBMS) broadcast data transfer. Data transfer245is the phase when multimedia broadcast/multicast service (MBMS) data is transferred to the user equipments (UE)11. Session stop255is the point at which the multimedia broadcast/multicast service (MBMS) user service determines that there will be no more data to send for some period of time. This period is long enough to justify removal of bearer resources associated with the service. At session stop255, the bearer resources are released. Session update (not shown) may be used to update specific parameters of an ongoing multimedia broadcast/multicast service (MBMS) broadcast session.

When compared to point-to-point communications, multicast service security faces some specific challenges. In the multimedia broadcast/multicast service (MBMS) context, ciphering has a different purpose, as multimedia broadcast/multicast service (MBMS) subscribers have no real interest in broadcast or multicast privacy. However, encryption is a key feature for operators and content providers, as it is the only way to prevent unauthorized customers from receiving the data for free.

Multimedia broadcast/multicast service (MBMS) security mechanisms like ciphering need to be designed in a way, which is suitable for point-to-multipoint communications. In addition, those mechanisms shall prevent any bypass attempts from subscribers, by exchanging keys or passwords, for example. This is the reason why multimedia broadcast/multicast service (MBMS) security mechanisms are quite specific, involving complex key structures and frequent key updates.

FIG. 3illustrates key structure of the multimedia broadcast/multicast service (MBMS) security. As opposed to most point-to-point communications, the multimedia broadcast/multicast service (MBMS) security is not applied on a specific part of the transmission path (like the radio segment) but is rather performed end-to-end, between the broadcast-multicast service centre (BM-SC)16and the user equipments (UE)11. The basis of the multimedia broadcast/multicast service (MBMS) security is that the multicast data are protected by a symmetric traffic key (MTK)330which is a secret key shared by both the sender (the broadcast-multicast service centre (BM-SC)16) and the receivers (the multimedia broadcast/multicast service (MBMS) subscribers or user equipments (UE)11). At first, each terminal builds its own unique secret user key (MUK)310, derived from ciphering key (CK)312and integrity key (IK)314. Ciphering key (CK)312and integrity key (IK)314may be stored in the terminal's universal subscriber identity module (USIM). Those references of ciphering key (CK)312and integrity key (IK)314are also stored within the home subscriber system (HSS)23so that the network can also build its own reference of the user key (MUK)310. User key (MUK)310may also be generated based on sres and Kc instead of ciphering key (CK)312and integrity key (IK)314. Sres is a 32-bit signed response generated by mobile station and a mobile services switching center. Kc is a 64-bit ciphering key used as a session Key for encryption of the over-the-air channel. Kc is generated by the mobile station from the random challenge presented by the global system for mobile communications (GSM) network and the Ki from the subscriber identity module (SIM) utilizing an A8 algorithm.

The user key (MUK)310is further used by the user equipment (UE)11to retrieve the service key (MSK)320provided by the broadcast-multicast service centre (BM-SC)16during the authorization process. Service key (MSK)320and traffic key (MTK)330are the actual keys to secure multimedia broadcast/multicast service (MBMS) data. Both keys are generated by the broadcast-multicast service centre (BM-SC)16. Each traffic key (MTK)330corresponds to a unique data flow340(either a streaming flow or file download flow) and is used to cipher the data block for this flow. The set of traffic keys (MTK)330is transmitted to the authorized subscribers11by the broadcast-multicast service centre (BM-SC)16in a secured way, protected by the service key (MSK)320. As a way of enhancing security, it is then possible for the broadcast-multicast service centre (BM-SC)16to define two different sets of service key (MSK)320(and associated traffic key) and update the traffic key (MTK)330during a service or a session by indicating to the authorized receivers11the new service key (MSK)320to use. Service key (MSK)320and traffic key (MTK)330are usually updated in a subscribers user equipment (UE)11using unsolicited push procedures from the broadcast-multicast service centre (BM-SC)16. The protocol used to perform this update is multimedia internet keying (MIKEY), which is a key distribution protocol.

If a service employs the multimedia broadcast/multicast service (MBMS) security, this is indicated in the service announcement215,220. User equipment (UE)11that desires to receive such a service may first use the generic bootstrapping architecture (GBA) to establish a shared secret with the mobile network for application specific purposes. This secret is then passed by the mobile network to the broadcast-multicast service centre (BM-SC)16. At this point the shared secret is used by both the user equipment (UE)11and the broadcast-multicast service centre (BM-SC)16to derive two user equipment (UE)11specific keys, the multimedia broadcast/multicast service (MBMS) request key (MRK)350and the multimedia broadcast/multicast service (MBMS) user key (MUK)310. The user equipment (UE)11then initiates the user service registration procedure with the broadcast-multicast service centre (BM-SC)16, during which the two parties authenticate360each other by using the request key (MRK)350. If the user equipment (UE)11has subscribed to the service, it is registered by the broadcast-multicast service centre (BM-SC)16as a key recipient. The user equipment (UE)11then performs the service key (MSK)320request procedure, asking the broadcast-multicast service centre (BM-SC)16for the key of a specific multimedia broadcast/multicast service (MBMS) service. The broadcast-multicast service centre (BM-SC)16sends the multimedia broadcast/multicast service (MBMS) Service Key (MSK) to the user equipment (UE)11with the service key (MSK)320delivery procedure, using the user (MUK)310to protect it. The broadcast-multicast service centre (BM-SC)16may periodically send a new service key (MSK)320to the user equipment (UE)11to invalidate older keys.

Challenging situations may exist for the user equipment (UE)11relating to the key distribution. One such situation may occur when the user equipment (UE)11moves out of the full-covered network coverage of the multimedia broadcast/multicast service (MBMS). User may have started a multimedia broadcast/multicast service (MBMS) session when connected to network providing the multimedia broadcast/multicast service (MBMS) and during the session moving to an area, where the multimedia broadcast/multicast service (MBMS) is not served. Other possibility is that the multimedia broadcast/multicast service (MBMS) is disconnected over a mobile network for some reason and the user cannot re-connect over the mobile network. Typical situation may be when the user is sitting in a train. Critical aspect is how the key management is working when the user is watching a streamed video and getting out of the range of a good coverage area.

In accordance with an example embodiment of the invention, a handover of content distribution services between a mobile network (mobile network operator infrastructure) and a device network may be established. In order to ensure the security aspects of the multimedia broadcast/multicast service (MBMS), the cryptographic key handling needs to be created for the handover procedure. Devices of the device network may comprise for example mobile phones, personal digital assistants (PDA), laptop computers or such. The security mode concept for the handover from service covered area to not covered area may be controlled by the mobile network. The concept enables the mobile apparatus to switch between a remote and a connected security mode. The security mode concept may support both directions of handover, from the mobile network to the device network and vice versa.

In accordance with an example embodiment of the invention, the long-lived user key (MUK)310and the request key (MRK)350may not be touched due they are dependent on the generic bootstrapping architecture (GBA) and are user specific.

The short-lived traffic key (MTK)330is used to always decrypt the actual streaming data340. When the user equipment (UE)11moves from mobile network's server covered mode to device network's peer-to-peer (P2P) mode, some problems may arise. Such problems include that the data chunks may not arrive in the right order or the data may arrive later (and the traffic key (MTK)330is no longer valid), for example. In the worst case, even the service key (MSK)320might no longer be valid (and received traffic key (MTK)330may no longer be decrypted). Additionally, the extension to the key management model should be compatible with the existing model and network operators, who do not wish to deploy the peer-to-peer (P2P) content distribution. The content protected with the traffic key (MTK)330should be exchangeable between users described to the same service.

FIG. 4shows the network elements involved in the multimedia broadcast/multicast service (MBMS) from a security perspective. Nearly all the security functionality for the multimedia broadcast/multicast service (MBMS), except for the normal network bearer security, resides in either the broadcast-multicast service centre (BM-SC)16or the user equipment (UE)11. Generic bootstrapping server function (BSF)22is a part of generic bootstrapping architecture (GBA). The user equipment (UE)11and the broadcast-multicast service centre (BM-SC)16use generic bootstrapping architecture (GBA) to establish shared keys that are used to protect the point-to-point communication410between the user equipment (UE)11and the broadcast-multicast service centre (BM-SC)16.

The broadcast-multicast service centre (BM-SC)16is a source for the multimedia broadcast/multicast service (MBMS) data. It could also be responsible for scheduling data and receiving data from third parties for transmission. The broadcast-multicast service centre (BM-SC)16is responsible for establishing shared secrets with the user equipment (UE)11using generic bootstrapping architecture (GBA), authenticating the user equipment (UE)11with hypertext transfer protocol (HTTP) digest authentication mechanism, registering and de-registering user equipments (UE)11for the multimedia broadcast/multicast service (MBMS) user services, generating and distributing the keys necessary for the multimedia broadcast/multicast service (MBMS) security to the user equipments (UE)11with multimedia internet keying (MIKEY) protocol and for applying the appropriate protection to data that is transmitted as part of a the multimedia broadcast/multicast service (MBMS) user service. The broadcast-multicast service centre (BM-SC)16also provides the multimedia broadcast/multicast service (MBMS) bearer authorization for the user equipments (UE)11attempting to establish the multimedia broadcast/multicast service (MBMS) bearer.

The broadcast-multicast service centre (BM-SC)16also verifies whether a user is authorized to register and receive keys for the multimedia broadcast/multicast service (MBMS) user service. For the multimedia broadcast/multicast service (MBMS) multicast mode this authorization is done with the help of membership function420in the broadcast-multicast service centre (BM-SC)16. For the multimedia broadcast/multicast service (MBMS) broadcast mode this authorization is done without the help of membership function420because the membership function420is only defined in the context of the multimedia broadcast/multicast service (MBMS) multicast mode.

The user equipment (UE)11is responsible for establishing shared secrets with the broadcast-multicast service centre (BM-SC)16using generic bootstrapping architecture (GBA), registering to and de-registering from the multimedia broadcast/multicast service (MBMS) user services, requesting and receiving keys for the multimedia broadcast/multicast service (MBMS) user service from the broadcast-multicast service centre (BM-SC)16and also using those keys to decrypt the multimedia broadcast/multicast service (MBMS) data that is received.

Key management function450includes two sub-functions: Key request function460and key distribution function470. The key request function460is responsible for retrieving generic bootstrapping architecture (GBA) keys (for example session key Ks derived from ciphering key (CK) and integrity key (IK)) from the bootstrapping function (BSF), deriving user key (MUK) and request key (MRK) from generic bootstrapping architecture (GBA) keys and performing multimedia broadcast/multicast service (MBMS) user service registration, deregistration and service key (MSK) request procedures and related user authentication using request key (MRK). Furthermore, key request function460is responsible for providing user key (MUK) to key distribution function and performing authorization check. Key distribution function470is responsible for retrieving user key (MUK) from key request function460, generating and distributing service keys (MSK) and traffic keys (MTK) to the user equipment (UE)11and providing traffic key (MTK) to session and transmission function480.

Session and transmission function480is responsible for session and transmission functions. A content provider20may provide data for the session and transmission function480. The session and transmission function480may perform protection of data with traffic key (MTK) including encryption and/or integrity protection. The encrypted data435may be sent to user equipment (UE)11for decryption.

The user equipment (UE)11may include a secure generation and validation storage (MGV-S)490. The generation and validation storage (MGV-S)490may be realized in the user equipment (UE)11or in the universal integrated circuit card (UICC). The generation and validation storage (MGV-S)490is implemented in a protected execution environment to prevent leakage of security sensitive information such as multimedia broadcast/multicast service (MBMS) keys. The generation and validation storage (MGV-S)490stores the multimedia broadcast/multicast service (MBMS) keys and the generation and validation storage (MGV-S)490performs the functions that should not be exposed to unprotected parts of the user equipment (UE)11.

Hypertext transfer protocol (HTTP) digest authentication and key agreement (AKA) procedure415may be run between user equipment (UE)11and a bootstrapping function (22). As a result, shared secret session keys Ks are generated to both ends. Shared secret session key Ks may be generated by concatenating ciphering key (CK)312and integrity key (IK)314as referred inFIG. 3. Furthermore, shared secret session key Ks may be used for deriving a key Ks_xx_NAF. Derived key Ks_xx_NAF may be used as a user key (MUK) in both the generation and validation storage (MGV-S)490of the user equipment (UE)11and the key management function450of the broadcast-multicast service centre (BM-SC)16.

The user equipment (UE)11may initiate the user service registration procedure with the broadcast-multicast service centre (BM-SC)16, during which the two parties authenticate each other by using the request key (MRK) and hypertext transfer protocol (HTTP) digest authentication425. If the user equipment (UE)11has subscribed to the service, the user equipment (UE)11is registered by the broadcast-multicast service centre (BM-SC)16as a key recipient. The user equipment (UE)11then performs the service key (MSK) request procedure, asking the broadcast-multicast service centre (BM-SC)16for the key of a specific multimedia broadcast/multicast service (MBMS) service. The broadcast-multicast service centre (BM-SC)16sends the multimedia broadcast/multicast service (MBMS) Service Key (MSK) to the user equipment (UE)11with the service key (MSK) delivery procedure430, using the user (MUK) to protect it. The set of traffic keys (MTK) is transmitted to the authorized user equipment (UE)11by the broadcast-multicast service centre (BM-SC)16in a secured way440, protected by the service key (MSK).

In accordance with an example embodiment of the invention, the key lifetime of the traffic key (MTK)330may be extended. On the other hand, the content of a data flow340might be consumed much later then the actual initial encryption and hence the key might need to be valid a long time. For off-coverage mode, the network operator might be willing to relax the key management system. However, when the user equipment (UE)11is in a densely populated area, the operator is much more likely to desire a strong security model. In addition, operators may wish that some users are allowed to go into peer-to-peer (P2P) security mode, for example users that have yearlong high level service contracts. Roaming may also be an option for not allowing the user equipment (UE)11to switch peer-to-peer (P2P) mode.

In accordance with an example embodiment of the invention, no changes are intended to the service key (MSK)320key management hence no changes to the smart card or the interface to the smart card are intended. The changes may only affect the traffic key (MTK)330and usage, storage and deletion of it. The changes may also affect directly traffic key (MTK)330related data (like key identifier and sequence number). The traffic key (MTK)330may be handled in the user equipment (UE)11only, not in the universal integrated circuit card (UICC).

In accordance with an example embodiment of the invention, there are some factors allowing user equipment (UE)11to switch into peer-to-peer (P2P) security mode. First, the user equipment (UE)11is connected to a border server of the streaming network (network indication may be given of that fact). Second, the user equipment (UE)11receives an indication from the network application function (NAF) that the user equipment (UE)11is allowed to switch to peer-to-peer (P2P) security mode. Third, mobile network signal strength of the user equipment (UE)11goes down. The first two factors may be the same, in the sense, that only border servers may send the indication.

When the signal strength goes down and the network has allowed the switching, the user equipment (UE)11may switch to peer-to-peer (P2P) security mode. However, lifetime of the traffic key (MTK)330is quite short and when the signal strength of the user equipment (UE)11goes down, the allowed window of traffic keys (MTK)330and their lifetime need to be extended. In addition, the allowed window for sequence numbers needs to be extended.

In accordance with an example embodiment of the invention, a replay counter is extended for the multimedia internet keying (MIKEY) message430,440arriving at the user equipment (UE)11. Extension payload is examined for the received multimedia internet keying (MIKEY) message430,440, and if the extension payload indicates a traffic key (MTK) delivery message440protected with service key (MSK)320, the service key (MSK) identifier is extracted from the extension payload. After that the timestamp payload is checked, and the message430,440is discarded if the counter in the timestamp payload is smaller or equal to the stored replay counter associated with the given service key (MSK)320. The stored replay counter value is retrieved from a generation and validation storage (MGV-S) of the user equipment (UE)11. When extending the replay counter, the payload may be used for a longer period of time for peer-to-peer (P2P) security mode. If the traffic key (MTK) identifier extracted from the extension payload is less than or equal to the current traffic key (MTK) identifier, the message shall be discarded. Allowing the extracted traffic key (MTK) identifier to be higher than the current traffic key (MTK) identifier also improves the peer-to-peer (P2P) security mode. The multimedia internet keying (MIKEY) message430,440is next transported to a generation and validation function (MGV-F) for further processing. The generation and validation function (MGV-F) replies with success or failure.

In accordance with an example embodiment of the invention, when the generation and validation function (MGV-F) receives the multimedia internet keying (MIKEY) message430,440, the generation and validation function (MGV-F) first determines the type of message by reading the extension payload. If the extension payload indicates a traffic key (MTK) delivery440then the generation and validation function (MGV-F) retrieves the service key (MSK)320with the identifier given by the extension payload.

The service specific data, service key (MSK)320, a random number and sequence numbers SEQI and SEQu, have been stored within a secure storage in the generation and validation storage (MGV-S). Sequence number SEQI corresponds to last accepted traffic key (MTK) identifier interval stored within the generation and validation storage (MGV-S). The original value of SEQI is delivered in the key validity data field of service key (MSK) messages430. Sequence number SEQu corresponds to upper limit of the traffic key (MTK) identifier sequence number interval, which is delivered in the key validity data field of service key (MSK) messages430. Service key (MSK)320, SEQI and SEQu are transferred to the generation and validation storage (MGV-S) with the execution of the service key (MSK) update procedures. The initial values of SEQI and SEQu may be determined by the service provider.

The generation and validation function (MGV-F) may compare the received traffic key (MTK) identifier from the multimedia internet keying (MIKEY) message430,440with the stored sequence numbers SEQI and SEQu. If the received traffic key (MTK) identifier is equal to or lower than SEQI or the received traffic key (MTK) identifier is greater than SEQu, then the generation and validation function (MGV-F) shall indicate a failure to the user equipment (UE)11. However, if the peer-to-peer (P2P) security mode is used, a failure to the user equipment (UE)11is not indicated in case the received traffic key (MTK) identifier is greater than SEQu.

The user equipment (UE)11may store the two most recent traffic keys (MTK)330used per multimedia broadcast/multicast service (MBMS) streaming or download session. In particular, if the generation and validation function (MGV-F) receives a traffic key (MTK)330and already stores two other traffic keys (MTK)330for that multimedia broadcast/multicast service (MBMS) streaming or download session, then the user equipment (UE)11shall keep the newer and delete the older of the two stored traffic keys (MTK)330before storing the received traffic key (MTK)330. Any traffic key (MTK)330stored in association with a particular multimedia broadcast/multicast service (MBMS) streaming or download session should be deleted at the end of that session. For peer-to-peer (P2P) security mode, the user equipment (UE)11may keep the two stored traffic keys (MTK)330to improve the decryption of older service session. Also the keeping the traffic keys (MTK)330in association with a particular broadcast/multicast service (MBMS) streaming or download session after the end of the session may be carried out for similar purposes.

In accordance with an example embodiment of the invention, the generic bootstrapping architecture user security settings (GUSS) stored in the home subscriber server (HSS)23contains a field, which indicate, that the peer-to-peer (P2P) security mode is allowed for certain user and certain network application function (NAF). The network application function (NAF) is configured to request generic bootstrapping architecture user security settings (GUSS). A border server network application function (NAF) extracts the security settings information and sends the information along with the streamed data to the user equipment (UE)11. For example, the border server network application function (NAF) may attach an indication after the traffic key (MTK)330and encrypt all with service key (MSK)320. Legacy terminal not supporting peer-to-peer (P2P) security mode may just ignore the indication and remain in the normal security mode.

When the mobile network signal strength goes down, the user equipment (UE)11may then collect streaming data from other devices. Since the traffic key (MTK)330is the same for all users subscribed to the service, the user equipment (UE)11is able to decrypt the data.

If the signal strength goes up again, the user equipment (UE)11may no longer need the data from other devices and the security mode can be set from the peer-to-peer (P2P) to normal again.

If the network application function (NAF) does not support peer-to-peer (P2P) security mode, then the network application function (NAF) may just ignore the generic bootstrapping architecture user security settings (GUSS) field. This feature may provide backward compatibility and compatibility with city-nodes (not border nodes).

In accordance with an example embodiment of the invention, the user equipment (UE)11may request old traffic keys (MTK)330from the border server network application function (NAF) in peer-to-peer (P2P) security mode.

Peer-to-peer (P2P) security mode may generate an addition of device features may allow streaming services in areas, where for return-of-investment reasons streaming service would not be possible.

FIG. 5presents an example block diagram of an apparatus500in which various embodiments of the invention may be applied. This may be a user equipment (UE), user device or apparatus, such as a mobile terminal or other communication device.

The general structure of the apparatus500comprises a communication interface module550, a processor510coupled to the communication interface module550, and a memory520coupled to the processor510. The apparatus further comprises software530stored in the memory520and operable to be loaded into and executed in the processor510. The software530may comprise one or more software modules and can be in the form of a computer program product. The apparatus500further comprises a user interface controller560coupled to the processor510.

The communication interface module550implements at least part of the user data radio discussed in connection with various embodiments of the invention. The communication interface module550may be, e.g., a radio interface module, such as a WLAN, Bluetooth, GSM/GPRS, CDMA, WCDMA, or LTE (Long Term Evolution) radio module. The communication interface module550may be integrated into the apparatus500or into an adapter, card or the like that may be inserted into a suitable slot or port of the apparatus500. The communication interface module550may support one radio interface technology or a plurality of technologies.FIG. 5shows one communication interface module550, but the apparatus500may comprise a plurality of communication interface modules550.

The processor510may be, e.g., a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a graphics processing unit, or the like.FIG. 5shows one processor510, but the apparatus500may comprise a plurality of processors.

The memory520may be for example a non-volatile or a volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), a random-access memory (RAM), a flash memory, a data disk, an optical storage, a magnetic storage, a smart card, or the like. The apparatus500may comprise a plurality of memories.

The memory520may be constructed as a part of the apparatus500or it may be inserted into a slot, port, or the like of the apparatus500by a user. The memory520may serve the sole purpose of storing data, or it may be constructed as a part of an apparatus serving other purposes, such as processing data.

A universal integrated circuit card (UICC)570may be included as a smart card used in the apparatus500. The universal integrated circuit card (UICC)570ensures the integrity and security of certain personal data. The universal integrated circuit card (UICC)570may contain its unique serial number, internationally unique number of the mobile user (IMSI), security authentication and ciphering information, temporary information related to the local network, a list of the services the user has access to and passwords (PIN for usual use and PUK for unlocking). The universal integrated circuit card (UICC)570may further comprise several applications, making it possible for the same smart card to give access to different networks, and also provide storage of a phone book and other applications. The system may utilize a embedded security module for the key storage and processing.

The user interface controller560may comprise circuitry for receiving input from a user of the apparatus500, e.g., via a keyboard, graphical user interface shown on the display of the apparatus500, speech recognition circuitry, or an accessory device, such as a headset, and for providing output to the user via, e.g., a graphical user interface or a loudspeaker.

A skilled person appreciates that in addition to the elements shown inFIG. 5, the apparatus500may comprise other elements, such as microphones, displays, as well as additional circuitry such as input/output (I/O) circuitry, memory chips, application-specific integrated circuits (ASIC), processing circuitry for specific purposes such as source coding/decoding circuitry, channel coding/decoding circuitry, ciphering/deciphering circuitry, and the like. Additionally, the apparatus500may comprise a disposable or rechargeable battery (not shown) for powering the apparatus500when external power if external power supply is not available.

FIG. 6shows a flow diagram showing peer-to-peer streaming session operations in an apparatus in accordance with an example embodiment of the invention. In step600, the method is started. In step610, encrypted multimedia information of a multimedia broadcast multicast service streaming session is received, wherein the multimedia information is encrypted using an encryption key. In step620, an indication allowing to switch the receiving of the encrypted multimedia information to a peer-to-peer streaming session is received. In step630, receiving of the encrypted multimedia information from the multimedia broadcast multicast service streaming session to the peer-to-peer streaming session is switched. In step640, encrypted multimedia information of the peer-to-peer streaming session is received. The method ends in step650.

The deployment of expensive streaming services in sparsely populated areas may not be efficient for a network operator. However, such areas should also be covered by the service infrastructure. An embodiment of the invention presents a method to extend the existing network technology to enable and support direct user equipment (UE) interaction to provide media services in such areas.

A similar technology has been adopted by the Open Mobile Alliance (OMA) in their OMA Broadcast (OMA BOAST) specifications. Their security model and key hierarchy are analogous to the multimedia broadcast/multicast service (MBMS) security architecture. Thus, the embodiments of the invention also apply to the Open Mobile Alliance (OMA) environment.

Various embodiments have been presented. It should be appreciated that in this document, words comprise, include and contain are each used as open-ended expressions with no intended exclusivity.

The foregoing description has provided by way of non-limiting examples of particular implementations and embodiments of the invention a full and informative description of the best mode presently contemplated by the inventors for carrying out the invention. It is however clear to a person skilled in the art that the invention is not restricted to details of the embodiments presented above, but that it can be implemented in other embodiments using equivalent means or in different combinations of embodiments without deviating from the characteristics of the invention.

Furthermore, some of the features of the above-disclosed embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description shall be considered as merely illustrative of the principles of the present invention, and not in limitation thereof. Hence, the scope of the invention is only restricted by the appended patent claims.