WO2009024071A1

WO2009024071A1 - System, method and device for realizing iptv media content security

Info

Publication number: WO2009024071A1
Application number: PCT/CN2008/072015
Authority: WO
Inventors: Zhaojun Peng; Zhanjun Zhang; Jincheng Li; Jun Yan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-08-17
Filing date: 2008-08-15
Publication date: 2009-02-26
Also published as: CN101369886A

Abstract

An embodiment of the invention provides a system, method and device for realizing IPTV media content security protection, relating to communications field, aiming at realizing IPTV media content protection. Therein the system comprises: a user equipment (UE) , a service control function entity(SCF), an IMS core network(IMS Core), a media function entity(MF), and a key managing function entity(KMF), wherein the media function entity for providing a key for the user equipment; said service control function entity for providing service control of IPTV service; said media function entity for sending encrypted media content to the user equipment; said user equipment for receiving the media content from the media function entity, and using the key received to gain the decrypted media content. The embodiment of the invention is applied to IPTV.

Description

System, method and device for realizing IPTV media content security

The present invention relates to the field of communications technologies, and in particular, to a system, method, and device for implementing IPTV media content security.

Background technique

IMS Core (also known as Core IMS), which is superimposed on the packet domain network, and is composed of functional entities such as Call Control Function (CSCF) and User Profile Serving Function (UPSF). The network system that makes up. CSCF can be divided into three logical entities: service CSCF (S_CSCF), proxy CSCF (P-CSCF) and query CSCF (I-CSCF).

The IPTV service based on the IMS network is a new service that has developed rapidly in recent years. The service transmits multimedia on the Internet Protocol (IP) network, including media content such as video, audio and data. The service essentially provides the IPTV service under the IMS network architecture, and fully utilizes the existing session control and charging mechanisms in the IMS network to provide TV services for the user equipment (UE, User Equipment). Typical examples of IPTV media streaming services are Linear Television (LTV) services (also called Broadcast Service BC, Broadcast Service) and Content on Demand (CoD). The LTV service is a service for transmitting media content to the UE in a multicast manner, and the CoD service is a unicast service.

FIG. 1 is a schematic diagram of a service function architecture of an IMS service based on an IMS network, which is proposed by a TI SPAN standards organization, where:

The IPTV Media Function Entity (MF, IPTV Media Function) is responsible for delivering the media content to the UE. The IPTV Media Function can be decomposed into a Media Function Function (MCF) and a Media Delivery Function (MDF) from a functional perspective. The MDF is usually a media distribution server that sends media streams to the UE under the control of the MCF.

IPTV Service Control Functions (SCF) are used to process Provides IPTV service control from the IPTV service request sent by the UE.

a User Profile Serving Function (UPSF) for storing the subscription information of the UE;

Service Selection Function (SSF), which is used to provide UEs with service menu information that can be browsed and selected;

Transport Functions for transmitting media content delivered by the MF in the IPTV to the UE. 2 is a schematic diagram of a service function architecture 2 of an IMS service based on an IMS network, which is proposed by the International Telecommunication Union (ITU-T) standards organization, including a UE, an IPTV application service function entity (applicat ions), and a service user. Service user profile function, IMS Core, Content delivery function, and Transport Stratum, where:

a content delivery function, configured to provide a media content distribution service for the UE, the function of the entity being similar to the function of the MF in FIG. 1;

The IPTV application service function entity (applications) is configured to process an IPTV service request sent from the UE, and provide service control of the IPTV, and the function of the entity is similar to the SCF in FIG. 1;

The service user profile function is used to store the service subscription information of the UE, and the function of the entity is similar to the UPSF in FIG. 1;

Transport Stratum, used to transmit media content distributed to the UE. The entity's functionality is similar to Transport Functions.

For the sake of brevity, the description in the embodiment of the present invention is only described by the definition of the entity described in FIG. 1, and similar functional entities corresponding to FIG. 2 are also applicable unless otherwise specified.

The system shown in FIG. 1 and FIG. 2 can transmit media content in an IPTV service, in particular, when the IPTV service is an LTV service, the media stream can be transmitted in a multicast manner, and when the IPTV service is a CoD service, the medium can be transmitted in a unicast manner. flow. However, when the media stream is transmitted in the multicast mode or the unicast mode, the transmitted media stream is not protected, so the security of the LTV service or the CoD service cannot be guaranteed. Currently, in the prior art, a conditional access (CA) method is a method for protecting media content security used in traditional broadcast television. In the system, by scrambling the media content at the content source, the UE performs descrambling when playing the media content, thereby implementing secure transmission of the media content. The media content, security information, and other information in the system are encapsulated into a transport stream (TS, Transport Stream) and sent to the UE. In the CA, the keys in the security information are hierarchically protected: The media content is scrambled and protected using the Control Word (CW, Control Word), and the CW is powered by the Service Key (SK, Service Key). After the secret processing is sent to the UE in an Entitlement Control Message (ECM), the SK sends the message to the UE through an Entitlement Management Message (EMM), and the SK needs to be encrypted by the user's personal key before being transmitted. The process of transmitting the media content is as shown in FIG. 3. After receiving the UE, the UE decrypts the SK by using the user's personal distribution key stored in the UE, decrypts the CT with the SK, and then descrambles the media content with the CT.

For the existing CA system, the media encryption technology applied to the traditional broadcast television system uses the scrambling and descrambling technology. The key is in the TS package format and cannot be directly applied to the current IPTV system. Therefore, how to implement media content security protection for LTV services in an IMS network is still an urgent problem to be solved.

Summary of the invention

In a first aspect, an embodiment of the present invention provides a system for implementing media security protection, which can implement protection of IPTV media content.

A system for implementing IPTV media security, comprising: a user equipment UE, a service control function entity SCF, an IMS core network IMSCore, a media function entity MF, and a key management function entity KMF, wherein

The key management function entity is configured to provide a key to the user equipment;

The service control function entity is configured to provide service control for an IPTV service;

The media function entity, configured to send the encrypted media to the user equipment;

The user equipment is configured to receive the encrypted media sent by the media function entity, and use the received key to obtain the unencrypted media. In a second aspect, an embodiment of the present invention provides a method for implementing media security protection, which can implement protection of IPTV media content.

A method for implementing I PT V media security includes the following steps:

The user equipment UE obtains a key corresponding to the media service security from the key management function KMF; the user equipment UE receives the encrypted medium sent by the media function entity MF;

The user equipment UE obtains the decrypted media using the key.

In a third aspect, the embodiment of the present invention further provides a key management function entity, including: a key distribution unit and a key information service function unit;

a key information service function unit, configured to provide a key for media service security to the key distribution unit;

And a key distribution unit, configured to send the key related to the media service security to the user equipment. It can be seen from the foregoing solution that the system, the method and the device provided by the embodiments of the present invention introduce a key management function entity for key management into an existing IMS network-based IPTV service system, so that the UE can The encrypted IPTV media content transmitted by the system is decrypted and viewed by the key, and other UEs without the key cannot decrypt the IPTV media content transmitted by the system.

Therefore, the system, method, and device provided by the embodiments of the present invention can implement protection of IPTV media content.

In addition, an embodiment of the present invention further provides a content encryption entity, including:

a key generation unit, configured to generate a media protection key;

And a key transceiver unit, configured to send the media protection key to the key management function entity. The embodiment of the invention further provides a content encryption entity, including:

a key generation unit, configured to generate a media protection key;

a message sending unit, configured to send a key request message to the key management function entity, requesting a key encryption key;

a key transceiving unit, configured to receive a key encryption key sent by the key management function entity; and an encryption operation unit, configured to add the media protection key by using the key encryption key Secret.

In the above technical solution, the content encryption entity encrypts the media content by using the media protection key, so that the security of the media content is ensured.

DRAWINGS

1 is a schematic diagram of a service function architecture of an IPTV service based on an IMS network in the prior art; FIG. 2 is a schematic diagram of a service function architecture 2 of an IMS service based on an IMS network in the prior art; FIG. 3 is a schematic diagram of a prior art transmitting a media content in a CA. Schematic diagram

4 is a schematic diagram of a system for implementing IPTV media content security in an IMS system according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of an example of a system 1 for implementing IPTV media content security in an IMS system according to an embodiment of the present disclosure;

FIG. 6 is a flowchart of Embodiment 1 for implementing media content security according to an embodiment of the present invention;

FIG. 7 is a flowchart of Embodiment 2 of implementing media content security according to an embodiment of the present invention;

FIG. 8 is a flowchart of Embodiment 3 of implementing media content security according to an embodiment of the present invention;

FIG. 9 is a flowchart of Embodiment 4 of implementing media content security according to an embodiment of the present invention; FIG. 11 is a flowchart of Embodiment 6 for implementing media content security according to an embodiment of the present invention; FIG. 13 is a flowchart for implementing media content security according to an embodiment of the present invention; Eight flow chart;

FIG. 16 is a flowchart of Embodiment 11 of implementing media content security according to an embodiment of the present invention; FIG. 17 is a schematic diagram of a second system for implementing IPTV media content security in an IMS system according to an embodiment of the present invention;

FIG. 18 is a flowchart of Embodiment 12 of implementing media content security according to an embodiment of the present invention; FIG. 19 is a schematic diagram of securing IPTV media content in an IMS system according to an embodiment of the present invention; Three schematic diagrams of the system;

20 is a flowchart of Embodiment 13 of implementing media content security according to the present invention;

FIG. 21 is a schematic structural diagram of a KMF according to an embodiment of the present invention;

FIG. 22 is a schematic diagram of a system for transmitting a key between MF and KMF according to an embodiment of the present invention; FIG. 23 is a diagram of an information system transmitted between a KMF and a CEF through a direct interface according to an embodiment of the present invention; Flow chart of content security embodiment 14;

Figure 25 is a flow chart of the fifteenth embodiment of the media content security of the present invention;

26 is a flow chart of a sixteenth embodiment of the media content security of the present invention;

Figure 27 is a flow chart of the seventh embodiment of the media content security of the present invention;

28 is a system diagram of media content security CEF and MF delivery information of the present invention;

29 to FIG. 32 are schematic diagrams showing Embodiments 1 through 4 of a content encryption entity according to an embodiment of the present invention.

detailed description

In order to make the objects, technical solutions and advantages of the present invention more comprehensible, the embodiments of the present invention are further described in detail with reference to the accompanying drawings.

In order to ensure the security of the IPTV media content, the embodiment of the present invention needs to secure the media content, and transmits a key used for security protection of the media content to the UE, and the UE receives the received key pair. The securely protected media content is securely verified or decrypted. Therefore, the embodiment of the present invention re-architects a network for implementing an IPTV service based on an IMS network, and a key management function entity (KMF, Key Manage Funct ion) is introduced in the network. Among them, KMF is used to send media security related keys. KMF is a logic function module. When it is implemented, it can exist as an independent functional entity. It can also be an internal logic function unit of SCF. It can also be an internal logic function unit of MF or other functional entities.

In addition, in the network architecture, a content encryption function entity (CEF, Content Encryption Function) can also be introduced, which is used for encrypting content and the like. CEF is a logical function module. When implemented, it can exist as an independent functional entity. It can also be MF or other functions. The internal logical functional unit of the entity.

In the IPTV service, in order to secure the media content, it is necessary to use various keys for protection. The following describes the functions of various possible keys. "/" means "or".

A media protection key (TEK, Traffic Encryption Key), or a content encryption key, is used to directly protect the confidentiality or integrity of media streams or content.

A service protection key (SEK, Serv ice Encryption Key), which is used to protect one or more multicast services, or one or more multicast service channel keys, can be used to protect the secure transmission of the TEK at the media level ( Confidentiality and/or integrity protection) can also be used to protect business-related security information, such as encryption algorithms or key validity periods, and to protect the security of a program protection key (PEK) for a media stream content. protection.

Program Encryption Key (PEK), a key that can be protected against media content in one or more channels, can be used to protect the secure transmission of TEK at the media level, and can also be used to protect business related Security information, such as encryption algorithms or key validity periods.

The service group key (SGK, Serv ice Group Key) is used to protect the security transmission of the TEK at the media level. The UEs of the same LTV service are grouped, and each group is assigned a group key SGK, and the TEK media stream encrypted by the SGK is sent to the UEs in the group. At the same time, all UEs receiving the same media content can receive the same protected media stream, and each group can perform SGK update asynchronously. The SGKs of each group are updated separately. The UEs that join the group cannot receive the previously sent media streams, and the UEs that leave the group cannot receive the media streams sent later, which can reduce the scope of the TEK update. In addition, different levels of UEs may have different receiving media stream rights. In this case, the UEs may be grouped according to the rights of different levels of UEs, and each group corresponds to an SGK to protect the secure delivery of the TEK.

In the embodiment of the present invention, the general SEK, PEK or SGK is used for the protection of the TEK. For the convenience of the following description, it is generally referred to as a service key SEK or a Key Encryption Key (KEK). TEK is hereinafter referred to as a media protection key. Service User Key (SUK), which is a user-related key. It can be used to protect SEK or PEK or SGK. SUK can be a key set by the network side and the UE, or it can be used. The key generated by the GBA (Generic Bootstrapping Architecture) method can also be a user key derived from the shared key generated by the GBA method.

The Service Registration Key (SRK) is used to authenticate the user of the IPTV service. For example, the HTTP digest authentication method can be used to authenticate the user. The SRK may be a key set by the network side and the UE in advance, or may be a key generated by using the GBA method, or may be a user key derived from a shared key generated by the GBA method, and the derivative manner may be performed by the network side of the LTV service. Pre-set with the UE.

In the embodiment of the present invention, the SUK or SRK is referred to as a user key SUK, and the key is generally used to protect the delivery of user-specific confidential information, for example, to protect the service key.

In the embodiment of the present invention, the protection of the IPTV service may be classified into LTV (representing multicast service) protection and COD (representing unicast service) protection according to specific services. The following describes the multicast service by LTV, and unicast by CoD. business. The protection of these two services is specifically based on which keys are used for protection. For example, LTV protection can use SEK and TEK, media stream is protected by TEK, TEK is protected by SEK, encrypted TEK and encrypted media are delivered through media multicast, and SEK is sent through the signaling plane. LTV protection can also be used to protect media only by using TEK. The media stream is protected by TEK and delivered by the media multicast. The TEK is sent through the signaling plane. The COD protection can protect the media only by using the TEK. The media stream is sent by the TEK for protection through the media plane, and the TEK is sent through the signaling plane.

For a service package (a group of services), the key in the process may refer to a key shared by all services in the entire service package; or may refer to a different key corresponding to each service in the service package. The set of keys may be different for each service in the service package, but the key to be delivered is only the key corresponding to a certain service in the service package requested by the current user.

In the following specific embodiments of the present invention, the protected media content needs to be different from the used key, and may be a single or multiple different media streams. For example, if the UE is sent a KEK as a key, the UE The TEK stream encrypted by KEK and the media stream protected by TEK are received. At this time, the UE can decrypt the obtained KEK to obtain the TEK, and then decrypt the media stream with TEK. If the TEK is sent as a key to the UE, the UE receives the media stream protected by the TEK, and decrypts the media stream by using the obtained TEK. In the following description, KEK or TEK is commonly referred to as a key, and the media stream and/or key stream delivered by the media plane are simply referred to as protected media streams.

The following describes how to implement security protection for IPTV service media content after introducing KMF and CEF into the network.

FIG. 4 is a schematic diagram of a system for implementing IPTV media content security in an IMS system according to an embodiment of the present invention. KMF is introduced in a system for implementing an IPTV service based on an IMS network, and is used for a key and/or a key. The relevant parameters are provided to the required functional entities. In addition, KMF can generate or obtain keys and/or related parameters from other functional entities. KMF can also update keys and/or related parameters.

Here, the required functional entity may be a functional entity such as a UE, an MF, or an SCF, and the related parameters include a combination of one or more of a key identifier corresponding to the key, a security algorithm, and a key validity period.

In order to introduce the KMF into the architecture for implementing the IPTV service based on the IMS network, the embodiment of the present invention adds some interfaces in the architecture, including: a K1 interface between the KMF and the SCF; a K2 interface between the KMF and the UE; KMF and K4 interface between IMS Core; K3 interface between SCF and UE; K5 interface between KMF and MF. These interfaces are mainly used to transfer key or / and key related parameters between two functional entities connected through an interface.

In Figure 4, these interfaces are not all mandatory in the architecture of the specific implementation. Depending on the scheme used to transmit the key or/and the corresponding parameters corresponding to the key, if it is only transmitted in KMF and UE, Then the K2 interface is required, other interfaces are optional; if the KMF is transmitted between the SCF and the UE, the K1 and K3 interfaces are required, and other interfaces are optional; if the KMF and the SCF are transmitted, then K1 The interface is required, and other interfaces are optional. If the key is transmitted between KMF and MF, the K5 interface is required, and other interfaces are optional. If KMF directly transmits the key through the IMS Core, the K4 interface is required. The interface is optional. Give an example to illustrate, for example, the specific implementation used in KMF If the key or the key corresponding to the key is directly transmitted between the SCF and the SCF, the system architecture diagram shown in Figure 5 can be used. In the figure, it can be seen that the K1 interface must exist, and other interfaces can be There may or may not be.

The following examples of implementing the HTTP protocol in the various embodiments are only described by taking HTTP as an example. In the specific implementation, other protocols may also be implemented, for example, using XML format or using MIKEY to carry and send a key. The following is a detailed description of how the system provided in Figure 4 implements media content security.

Embodiment 1

This embodiment can be applied to the LTV service protection or the CoD service protection. The UE and the KMF directly interact with each other. When the embodiment is applied, the K2 interface is a necessary interface. In the first embodiment, the connections between the devices in the system shown in Fig. 4 are as shown in Fig. 5.

In this embodiment, the UE may generate a shared user key in advance with the KMF, for example, generated by a GBA (Geeric Bootstrapping Architec), and then use the shared key to protect the KMF from being transmitted to the UE. Key information. The process of generating a shared key may be performed before or after receiving a key request from the UE.

FIG. 6 is a flowchart of Embodiment 1 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 601: The UE performs a session process of service establishment or service switching (channel switching of the LTV). In this step, the session process and the key request process are not in an orderly sequence.

Step 602: The KMF sends a key acquisition indication information to the UE, instructing the UE to initiate a key acquisition request, and the step is optional.

In this step, it is mandatory only if the KMF uses this method to notify the UE that the key needs to be acquired. If the UE knows that the key needs to be obtained through other means, for example, the IMS network side uses Not ify to notify that the key acquisition is required, or by checking the identifier in the media stream that needs to be obtained (key identification). If the UE explicitly knows that the key needs to be obtained before the UE initiates the service, the indication message may not be sent. Step 603: The UE sends a key request message, such as an HTTP request message, to the KMF through the K2 interface, and carries the user identifier, the service/content identification information, or the key identification information.

Step 604: The KMF obtains the service authorization information of the user from the SCF or the UPF, and authorizes the user's request. This step is optional if the KMF itself has authorization capabilities.

Step 605: The KMF sends a response message to the UE through the K2 interface, where the key carries the key, or further includes related parameters of the key.

In this step, the key is a key corresponding to the service/content or key identification information carried in the request message, or includes related parameters of the key.

Step 606: The UE uses the obtained key to unlock the encrypted media content and perform viewing.

The service/content or service/content package identifier can be carried in the form of a URI or PS I in the IMS. The service/content or service/content package identifiers used in the following embodiments are similar and will not be repeatedly described.

For multicast services (such as LTV services), the key of this embodiment can be used as follows: The key model is a three-layer key model, the key issued in step 605 is KEK, and KEK uses SUK. For encryption protection, at the media level, the KEK encrypted TEK is sent to the UE through multicast. The UE first uses the SUK to decrypt the KEK, then uses the KEK to decrypt the TEK, and finally uses the TEK to decrypt the encrypted media stream.

For a unicast service (for example, a CoD service), the key of the embodiment may be similarly used according to the manner in which the multicast layer 3 key is sent. The difference is that the key delivered by the media plane is not It is delivered in multicast mode, but is sent in unicast mode. Or use the model of the layer 2 key. The key sent in step 605 is TEK. The TEK uses the SUK to perform encryption protection. At the media level, the key is not required to be sent to the UE. The UE first uses the SUK to decrypt the TEK. Use TEK to decrypt the media stream.

The response message of step 605 may specifically be a response message directly corresponding to the request, for example, the request is an HTTP request, and the response is a corresponding 200 message; or may be a separately sent message, for example, using a separate UPD message to carry the MIKEY format secret. key. Embodiment 2

This embodiment can be applied to the LTV service protection or the CoD service protection. The UE and the KMF directly interact with each other through the IMS Core. When the embodiment is applied, the K1 interface is the architecture of the interface that must be selected.

FIG. 7 is a flowchart of Embodiment 2 of implementing media content security according to an embodiment of the present invention, and the specific steps are as follows:

Step 701: The UE sends a service request to the SCF through the IMS Core, and carries the user identifier and the identification information of the service or the content.

Step 702: The SCF sends a service request to the MF through the IMS Core, and carries the user identifier and the identification information of the service or the content, and the MF returns a service response message to the SCF through the IMS Core.

This step is not required for LTV service requests.

Step 703: The SCF generates a service authorization token (Token), and returns a service response message to the UE through the IMS Core, and carries the service authorization Token, and may also carry the obtained key address information, such as an IP address or a URL or a PS I in the IMS.

Step 704: The UE sends a key request message to the KMF, where the user identifier, and the service or content identifier, and the service authorization token are carried.

Step 705: After receiving the message, the KMF verifies that the authorized Token passes, and returns a key to the UE.

Step 706: The UE uses the obtained key to unlock the encrypted media stream for viewing.

Before step 704 of FIG. 7, the KMF may also first send a trigger message to the UE, requesting the UE to obtain the key information from the KMF.

The granting of the Token in Figure 7 can be performed in multiple ways. The UE obtains the Token in addition to the session establishment process, and can also obtain the Token from other ways, such as service ordering, carrying and sending through an electronic decryption menu (EPG). The acquisition is not enumerated in this embodiment.

The key issued in this embodiment is similar to the key in the first embodiment, and may be KEK or TEK depending on whether the selected Layer 2 key or the Layer 3 key is different. In the embodiment of the present invention, the service authorization Token is a certificate issued by an authorized entity (for example, SCF or MF) to check the UE's right to obtain the key corresponding to the service and the relevant parameters of the key, and the form may be various. For example, the service authorization Token is a string or a number; it can also be a list, which contains the corresponding service or content identifier, user name and other information; in addition, the authorization entity can also sign and issue the token.

Embodiment 3

This embodiment can be applied to LTV service protection or CoD service protection, mainly for the UE to distribute keys through SCF and KMF. In combination with the system shown in FIG. 4, when the embodiment is applied, the K3 interface and K in the architecture are applied. The 1 interface is a mandatory interface.

In this embodiment, the UE may generate a shared user key in advance with the SCF, such as may be generated by the GBA method, and then use the shared key to protect the key information that the SCF delivers to the UE. The process of generating a shared key may be performed before or after receiving a key request from the UE.

FIG. 8 is a flowchart of Embodiment 3 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 801: The UE performs a session process of service establishment or service switching (channel switching of the LTV). In this step, the session process and the key request process are not in an orderly sequence.

Step 802: The SCF may send a key acquisition indication information to the UE, instructing the UE to initiate a key acquisition request, where the step is optional.

In this step, it is only necessary if the SCF uses this method to notify the UE that the key needs to be acquired. If the UE knows that the key needs to be obtained through other means, for example, the IMS network side uses

No t i fy (notification) may require the key acquisition, or by checking the identification (key identification) required to be obtained in the media stream, the indication message may not be sent.

Step 803: The UE sends a key request message to the SCF through the K3 interface, and carries the user identifier, the service/content identification information, or the key identification information.

Step 804: The SCF obtains a key and a related parameter of the key from the KMF.

Step 805: The SCF sends a response message to the UE, and carries the corresponding key. Step 806: The UE obtains the encrypted media stream, and uses the obtained key to unlock the media stream for viewing.

In the embodiment of the present invention, FIG. 8 may also perform a key update process, where the updated key may be obtained by the UE actively to the SCF, or the SCF may actively send the key to the UE.

For the SCF to obtain a key from the KMF, the SCF may initiate a key acquisition request message to the KMF, and carry the obtained service/content identification information or key identification information, and the KMF returns the service/content identifier or the key identifier to the SCF. The corresponding key, or also includes information such as algorithm, expiration date, and so on. The SCF can also save this information so that subsequent UEs can directly find the service request when making a service request. The specific protocol used can be obtained by using the Diameter protocol, the MIKEY protocol, or the HTTP protocol, SIP protocol, S0AP, XML, or the like. The methods of obtaining a key by the SCF or the MF in the following various embodiments are similar, and the description is not repeated.

Embodiment 4

This embodiment can be applied to the CoD service protection. The SCF obtains the service protection key from the KMF and sends it to the MF, and returns it to the UE through the IMS Core. In combination with the system shown in FIG. 4, when the embodiment is applied, the K1 in the architecture is mandatory. Select interface.

FIG. 9 is a flowchart of Embodiment 4 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 901: The UE sends a service request message, such as an INVITE, to the SCF through the IMS Core, where the user carries the user identifier, the service, or the content identifier information.

Step 902: The SCF acquires, by the SMF, a key corresponding to the service or the content identifier.

Step 903: The SCF sends a service request message to the MF through the IMS Core, where the service carries the service or the content identifier, and the corresponding key and other information.

Description: The MF can use this key to encrypt the content in real time. Here, the parameter carried in the request information sent by the SCF may not be a key, but an address information of the obtained key, such as an IP address or a URL or a PSI in the IMS. At this point, step 902 is not required.

Step 904: The MF sends a service response message to the SCF through the IMS Core, for example, 200 0K Interest and so on.

Step 905: The SCF adds the information such as the key to the service response message, and forwards the service response message to the UE through the IMS Core, where the key information or the key corresponding to the service or the content identifier is used to obtain the address information.

Step 906: The UE uses the obtained key to unlock the media stream and perform viewing.

The key issued here is specifically similar to the key in the first embodiment, and may be KEK or TEK depending on whether the selected layer 2 key or the layer 3 key is different.

Embodiment 5

This embodiment can be applied to CoD service protection. After obtaining the key from the KMF, the MF returns to the UE through the IMS Core. In conjunction with the system shown in FIG. 4, when the embodiment is applied, K5 is a mandatory interface; or MF uses the Y2 and K4 interfaces to obtain a corresponding key from KMF.

FIG. 10 is a flowchart of Embodiment 5 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 1001: The UE sends a service request message, such as an INVITE message, to the SCF through the IMS Core, where the UE carries the user identifier, the service, or the content identifier information.

Step 1002: The SCF sends a service request message to the MF through the IMS Core, where the user identifier, service or content identification information is carried.

Step 1003: The MF obtains a key corresponding to the service or the content identifier from the KMF.

Description: The MF can use this key to encrypt the content in real time.

Step 1004: The MF sends a service response message (for example, a 200 0K message) to the SCF through the IMS Core, and carries a key corresponding to the service or the content identifier.

Step 1005: The SCF sends a service response message to the UE through the IMS Core.

Step 1006: The UE uses the obtained key to unlock the encrypted media stream and view it.

Embodiment 6 This embodiment can be applied to the CoD service protection, and the SCF obtains the service key from the KMF and returns it to the UE through the IMS Core. In conjunction with the system shown in FIG. 4, when the embodiment is applied, the K1 interface is a mandatory interface.

FIG. 11 is a flowchart of Embodiment 6 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 1101: The UE sends a service request message (for example, INVITE) to the SCF through the IMS Core, where the UE carries the user identifier, the service, or the content identifier information.

Step 1102: The SCF sends a service request message to the MF through the IMS Core.

Step 1103: The MF sends a service response message, such as a 200 0K message, to the SCF through the IMS Core. Step 1104: The SCF obtains a key corresponding to the service or the content identifier from the KMF.

Step 1105: The SCF sends a service response message to the UE through the IMS Core, and carries a key corresponding to the service or the content identifier.

NOTE: The parameter carried in the service response information sent by the SCF may not be a key, but an address information of the obtained key, such as an IP address or a URL or a PSI in the IMS. At this point, step 1104 is not required.

Step 1106: The UE uses the obtained key to unlock the media stream and view it.

Example 7

This embodiment can be applied to the LTV or CoD service, and the SCF obtains the key from the KMF and returns it to the UE through the IMS session process. In conjunction with the system shown in FIG. 4, when the embodiment is applied, the K1 interface is a mandatory interface. The sudden is:

Step 1201: The UE sends a key request message, such as an INVITE message, to the SCF through the IMS Core, where the UE carries the identifier of the user identifier, the service, or the content. Step 1202: The SCF acquires a key corresponding to the service or the content identifier from the KMF. Step 1203: The SCF sends a service response message to the UE through the IMS Core, and carries a key corresponding to the service or the content identifier.

NOTE: The parameter carried in the service response information sent by the SCF may not be a key, but an address information of the obtained key, such as an IP address or a URL or a PS I identifier in the IMS. At this time, step 1202 may not be required.

Step 1204: The UE receives the encrypted media stream, obtains the media stream by using the key, and performs viewing. The key request message and the key response message in this embodiment may use an SIP request message, for example, an Inv i te message and a 200 response message.

The key is delivered in this embodiment by using the service response message directly. In addition, the key may not be carried by the service response message but carried by another message, for example, the KMF or the SCF sends the UE to the UE using a separate UDP message.

For multicast services (such as LTV services), the key of this embodiment can be used as follows: The key model is a three-layer key model, the key requested in step 1202 is KEK, and KEK uses SUK. Encryption protection. At the media level, the KEK-encrypted TEK can be delivered to the UE through multicast through KMF or MF. The UE first decrypts the KEK using SUK, then decrypts the TEK using KEK, and finally uses TEK to decrypt the encrypted media stream.

For a unicast service (for example, a CoD service), the key of the embodiment may be similarly used according to the manner in which the multicast layer 3 key is sent. The difference is that the key delivered by the media plane is not It is delivered in multicast mode, but is sent in unicast mode. Or use the model of the layer 2 key. The key requested in step 1202 is TEK. The TEK uses the SUK to perform encryption protection. At the media level, the key is not required to be sent to the UE. The UE first uses the SUK to decrypt the TEK. TEK decrypts the media stream.

For the case of using the GBA to establish the SUK, the request message here may also carry the GBA temporary user identification information B-TID, and the SCF sends the B-TID to the KMF, so that the KMF obtains the corresponding SUK according to the B-TID, and uses the SUK protection requirement. The issued key. Specific B-TID can use S IP request The element corresponding to the XML in the message is carried.

In FIG. 12, the key update process is basically similar to the basic service establishment process, and is divided into a key update process initiated by the UE and a key update process initiated by the network side. The key update may carry the key update request information and the key using an INVITE message in the SIP or an Upda te or Pub l i sh (release) message or a Not ify message and a corresponding reply message.

In FIG. 12, the service request may also be initiated by the entity on the network side, and the process is similar to this embodiment, except that the network side carries the key to the UE in the message initiating the request.

Process for channel switching: If all services in the entire service packet (multicast service group) share a set of keys or if a set of different keys corresponding to all services in the entire service packet is initially delivered; When switching between all channels in the same service package, there is no need to initiate a key request message. If the initial delivery is only a key corresponding to a service in a certain service or service packet, the UE needs to obtain a key from the network side when performing channel switching. Or when the UE switches to a service or channel in another service packet, it also needs to obtain a key from the network side.

Example eight

The embodiment can be applied to the LTV service and the CoD service, and the UE subscribes to the key from the SCF and subscribes to the key of the current service by using the subscription (Subscr ibe) in the SIP (RFC 3261) protocol. In conjunction with the system shown in FIG. 4, when the embodiment is applied, the K1 interface is a mandatory interface.

FIG. 13 is a flowchart of Embodiment 8 of implementing media content security according to an embodiment of the present invention, and the specific steps are:

Step 1301: The UE sends a Subscr ibe message to the SCF through the IMS Core, and the subscription event is a key of the current IPTV service, carrying the user identifier, and the service or content identifier.

Step 1302: The SCF returns a 200 0K message to the UE through the IMS Core, indicating that the subscription is successful. Step 1303: The UE performs an IPTV service establishment or handover process.

In this step, there is no necessary order relationship between the service establishment or the handover process and the subscription and delivery of the key. The subscription and delivery of the key may be before, during or after the service establishment or handover process. Then send it.

Step 1304: The SCF acquires current service information of the UE.

In this step, the SCF can obtain multiple current service modes of the UE, for example, the SCF subscribes to the current LTV channel information or CoD content information to the UE by using the Subscr ibe/Notify mode; or the SCF establishes or switches through the session. The information about the current service of the UE is known; or the SCF subscribes to the current service information of the UE to the presence server Presence Server.

Step 1305: The SCF obtains, from the KMF, a key corresponding to the current service or the content identifier of the UE.

Step 1306: The SCF sends a Not if y message to the UE through the IMS Core, and carries the key corresponding to the current service or content of the UE.

Step 1307: The UE returns a 200 OK message to the SCF through the IMS Core.

Step 1308: The UE unpacks the media stream according to the received key and performs viewing.

When the key is updated, the SCF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 0K message.

For the case of using the GBA to establish the SUK, the Subscr ibe request message here may also carry the GBA temporary user identification information B_T ID, and the SCF sends the B_T ID to the KMF, so that the KMF obtains the corresponding SUK according to the B_T ID, and uses the SUK protection. The key sent. The specific B-TID can be carried using the element corresponding to the XML in the request message.

Example nine

This embodiment can be applied to the LTV service and the CoD service. In this embodiment, the UE subscribes to the key from the SCF in the Subscr ibe mode and subscribes to the key corresponding to a certain service or content. In conjunction with the system shown in FIG. 4, when the embodiment is applied, the K1 interface is a mandatory interface. The sudden is:

Step 1401: The UE performs an IPTV service session establishment process or a channel switching process. In this step, the session establishment process or the channel switching process and the key subscription process are not sequentially required, and the process of subscribing to the key may be performed first without performing the session establishment process.

Step 1402: The UE sends a Subscr ibe message to the SCF through the IMS Core, and subscribes to one or more key event packets corresponding to the service or the content identifier, where the message carries the user identifier, and the service or the content identifier.

Step 1403: The SCF returns a 200 OK message to the UE through the IMS Core, indicating that the subscription has succeeded.

Step 1404: The SCF obtains, from the KMF, a service identifier corresponding to the UE or a key corresponding to the content identifier.

Step 1405: The SCF sends a Not ify message to the UE through the IMS Core, where the key corresponding to the UE subscription is carried.

Step 1406: The UE returns a 200 0K message to the SCF through the IMS Core.

Step 1407: The UE uses the key obtained in step 1405 to unlock the protected media stream and view it.

When the key is updated, the SCF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 0K message. In this embodiment, a channel subscription process and a basic LTV service session change process in the new IPTV service package may be re-initiated (similar to the initial LTV service session initial process). In this process, channel switching is required. At this point, the process of resubscribing with the method described in Figure 14 is required.

Example ten This embodiment can be applied to the LTV service and the CoD service. The UE subscribes to the key from the KMF in the Subscr ibe mode and subscribes to the key of the current service. In conjunction with the system shown in FIG. 4, when the embodiment is applied, the K4 interface is a mandatory interface. The sudden is:

Step 1501: The UE sends a Subscr ibe message to the KMF through the IMS Core, and subscribes to the current IPTV service key, and carries the user identifier, and the service or content identifier.

Step 1502: The KMF returns a 200 OK message to the UE through the IMS Core, indicating that the subscription is successful. Step 1503: The UE performs an IPTV service establishment or handover process.

In this step, the service establishment or handover process does not have an inevitable sequence relationship with the subscription and delivery of the key. The subscription and delivery of the key may be sent before, during or after the service establishment or handover process.

Step 1504: The KMF obtains current service information of the UE.

In this step, the KMF obtains the UE's current service mode. For example, the KMF subscribes to the UE's current LTV channel information or CoD content information in the Subscr ibe/Notify mode; or the KMF establishes or switches through the session. The information about the current service of the UE is known; or the KMF subscribes to the current service information of the UE to the Presence Server.

Step 1505: The KMF sends a Not ify message to the UE through the IMS Core, and carries the key corresponding to the current service identifier or the content identifier of the UE.

Step 1506: The UE returns a 200 OK message to the KMF through the IMS Core.

Step 1507: The UE unlocks the media stream according to the received key and performs viewing.

When the key is updated, the KMF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 0K message.

The UE can also subscribe to the MF by using the Subscr ibe mode and subscribe to the key of the current service. In combination with the system shown in FIG. 4, the K5 interface is a mandatory interface, that is, the UE subscribes to the MF, and the MF uses the K5 interface to KMF gets the key. The key issued in this embodiment is similar to the key in the first embodiment, and may be KEK or TEK depending on whether the selected Layer 2 key or the Layer 3 key is different.

In the case of using the GBA to establish a SUK, the Subscr ibe request message can also carry the GBA temporary user identification information B-TID, so that the KMF obtains the corresponding SUK according to the B-TID, and uses the SUK to protect the key to be delivered. The specific B-TID can be carried using the element corresponding to the XML in the request message.

Embodiment 11

This embodiment can be applied to the LTV service and the CoD service. The UE subscribes to the key from the KMF in the Subscr ibe mode and subscribes to the key corresponding to a certain service or content. In conjunction with the system shown in Figure 4, the K4 interface is the architecture of the mandatory interface when the embodiment is applied.

FIG. 16 is a flowchart of Embodiment 11 of implementing media content security according to an embodiment of the present invention, where specific steps are as follows:

Step 1601: The UE performs an IPTV service session establishment process or a channel switching process.

In this step, the session establishment process or the channel switching process and the key subscription process have no prior sequence requirements, and the session establishment process may not be performed first, and the process of subscribing to the key is first performed.

Step 1602: The UE sends a Subscr ibe message to the KMF through the IMS Core, and subscribes to one or more service identifiers or a key corresponding to the content identifier, where the message carries the user identifier, the service identifier, or the content identifier.

Step 1603: The KMF returns a 200 OK message to the UE through the IMS Core, indicating that the subscription has succeeded.

Step 1604: The SCF sends a Not ify message to the UE through the IMS Core, where the key corresponding to the UE request is carried.

Step 1605: The UE returns a 200 OK message to the SCF through the IMS Core.

Step 1606: The UE uses the key obtained in step 4 to unlock the protected media stream and view it. When the key is updated, the KMF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 OK message. In this embodiment, a channel subscription process and a basic LTV service session change process in the new IPTV service package may be re-initiated (similar to the initial LTV service session initial process, in which a channel switching process is required) At this time, the process of re-subscribing with the method described in FIG. 16 is required.

The UE can also subscribe to the MF by using the Subs cr i be mode and subscribe to the key of a certain service. In combination with the system shown in FIG. 4, the K5 interface is a mandatory interface, that is, the UE subscribes to the MF, and the MF passes. The K5 interface obtains the key from KMF.

For the case of using the GBA to establish the SUK, the Subs cr i request message may also carry the GBA temporary user identification information B-TID, so that the KMF obtains the corresponding SUK according to the B-TID, and uses the SUK to protect the key to be delivered. . The specific B-TID can be carried using the element corresponding to the XML in the request message.

FIG. 17 is a schematic diagram of a system 2 for implementing IPTV media content security in an IMS system according to an embodiment of the present invention. A KMF function module is introduced in a system for implementing an IPTV service based on an IMS network, and KMF is integrated into the SCF. Service protection, that is, SCF has the function of KMF to manage keys.

At this time, the SCF having the KMF key management function can provide the key and/or related parameters to the required functional entity. The SCF can also generate or obtain keys and/or related parameters from other functional entities, and the SCF can also update the keys and/or related parameters.

Here, the required functional entity may be a functional entity such as a UE or an MF, and the related parameters include a combination of one or more of a key identifier corresponding to the key, a security algorithm, a key validity period, and the like.

Since the KMF is integrated into the SCF, the K1 interface between the SCF and the KMF described in FIG. 4 does not exist or becomes an internal interface, and the S1 interface between the SCF and the UE also has a function of transmitting a key to the UE; The S2 interface between the SCF and the MF also has a function of transmitting a key to the MF;

In Figure 17, the interfaces in the actual application system are not all mandatory, according to the distribution secret. The key or the corresponding parameters of the key corresponding to the key are different, and the interface selected by the actual architecture is also different. If the SCF interface is directly transmitted between the SCF and the UE, the S1 interface exists, other interfaces may exist or not exist; if transmitted between the SCF and the MF, the S2 interface must exist, and other interfaces may exist or not exist.

In the system 2 shown in FIG. 17, the specific process of service protection is similar to the service protection process of the KMF of FIG. 4 as an independent functional entity (Embodiment 1 to Embodiment 11), except that KMF is an internal part of the SCF. The function module does not need the step of acquiring the key from the SCF to the KMF in the embodiment, and the interaction of the other functional entities with the KMF is changed to the interaction with the SCF. The following examples are explained.

Example twelve

FIG. 18 is a flowchart of Embodiment 12 of implementing media content security according to an embodiment of the present invention. It can be seen that, compared with the flowchart of Embodiment 3, the flowchart does not require SCF to KMF to acquire a key, and the SCF has KMF manages the key and sends the key directly to the UE, which saves the steps. When the embodiment is applied, the S1 interface in the architecture is a mandatory interface.

Step 1801: The UE performs a session process of service establishment or service switching (channel switching of the LTV).

In this step, the session process and the key request process are not in an orderly sequence.

Step 1802: The SCF may send a key acquisition indication information to the UE, instructing the UE to initiate a key acquisition request, and the step is optional.

Step 1803: The UE sends a key request message to the SCF through the S1 interface, and carries the user identifier, service/content identification information, or key identification information.

Step 1804: The SCF sends a response message to the UE, and carries the key.

Step 1805: The UE obtains the protected media stream, and uses the obtained key to unlock the media stream for viewing. For the case where KMF is integrated into the SCF, the above embodiments in which the KMF is an independent functional entity can be handled similarly to the present embodiment.

FIG. 19 is a schematic diagram of a system for implementing IPTV media content security in an IMS system according to an embodiment of the present invention. As shown in the figure, a KMF function module is introduced in a system for implementing an IPTV service based on an IMS network, and is integrated into the MF. Conduct business protection. That is to say, the MF has the function of managing the key by the KMF.

At this time, the MF having the KMF key management function can provide the key and/or related parameters to the required functional entity. The MF can also generate or obtain keys and/or related parameters from other functional entities, and the MF can also update the keys and/or related parameters.

Here, the required functional entity may be a functional entity such as a UE or an SCF, and the related parameters include a combination of one or more of a key identifier corresponding to the key, a security algorithm, and a key validity period.

Since KMF is integrated into the MF, the K5 interface between the MF and the KMF described in FIG. 4 does not exist or becomes an internal interface, and the L1 interface between the MF and the SCF has an existing function, and also has a UE. The transmission key and the related parameter function corresponding to the key; the L2 interface between the IMS Core and the MF has the functions of the MF transmission key and the related parameters corresponding to the key, the SCF and the UE The L3 interface transmits the key and the related parameter function corresponding to the key.

In Figure 19, these interfaces are not all mandatory. The selected interfaces are different depending on the path through which the transmission key or / and the corresponding parameters of the key correspond. If the L1 interface between the MF and the SCF is transmitted, the L1 interface between the MF and the SCF exists, and other interfaces may exist or not exist; if the L2 interface between the IMS Core and the MF is transmitted, the IMS Core and the MF The L2 interface must exist between the other interfaces, and other interfaces may exist or not exist.

In the system 3 shown in FIG. 19, the specific process of service protection is similar to the service protection process of the KMF of FIG. 4 as an independent functional entity (Embodiment 1 to Embodiment 11), except that KMF is an internal part of the MF. The function module does not need to acquire the key in the MF to KMF in the embodiment, and the interaction of the other functional entities with the KMF is changed to the interaction with the MF. Give an example.

Example thirteen FIG. 20 is a flowchart of Embodiment 13 of implementing media content security according to an embodiment of the present invention. As shown in the flowchart, compared with the flowchart of Embodiment 5, the MF does not need to obtain a key to the KMF, and the MF has KMF manages the key function and directly sends the key to the UE through the IMS Core and SCF. This embodiment can be applied in CoD service protection, and M is returned to the UE key through the IMS Core. In conjunction with the system shown in FIG. 19, L2 is a mandatory interface when the embodiment is applied. The specific steps are:

Step 2001: The UE sends a service request message, such as an INVITE message, to the SCF through the IMS Core, where the UE carries the user identifier, service, or content identification information.

Step 2002: The SCF sends a service request message to the MF through the IMS Core, where the user identifier, service or content identification information is carried.

Step 2003: The MF sends a service response message (such as a 200 0K message) to the SCF through the IMS Core, and carries a key corresponding to the service or the content identifier.

Step 2004: The SCF sends a service response message to the UE through the IMS Core.

Step 2005: The UE uses the obtained key to unlock the media stream and view it.

For the case where KMF is integrated into the MF, each of the above embodiments in which the KMF is an independent functional entity can be handled similarly to this embodiment.

For the embodiment in which all the UEs obtain the key, if the network side obtains the corresponding key information required by the user in advance, for example, the network side knows that the user switches to a new encrypted channel, the network side may be in the UE. When the request is not initiated, the UE or the key corresponding to the content is actively sent to the UE. That is, the UE does not need to send the key request message. The specific process and parameters used are similar to the embodiments that the UE actively requests.

The embodiment of the present invention further provides a structure diagram of a KMF, as shown in FIG. 21, including: a key distribution unit 2101 and a key information service function unit 2102, where

a key distribution unit 2101, configured to send a related parameter of a key or/and a key to a UE or other functional entity; The key information service function unit 2102 is configured to provide a key or/and a related parameter of the key to the key distribution unit 211, and the related parameter of the key or/and the key is generated by the unit itself, or may be from another The place to get.

The embodiment of the present invention further provides a system diagram for transmitting a key between the MF and the KMF. As shown in FIG. 22, in the figure, the KMF sends the key to the MF through M1, or sends the message through M2, SCF, Core IMS. Give MF. The MF in this figure performs the encryption processing of the service protection. For the case where the TEK is used for the delivery of the TEK in the LTV, the MF also needs to deliver the TEK multicast to the UE.

The interface Ml : is used to pass the key directly; interface M2 : The key is passed through the SCF. The Ml and M2 interfaces do not need to exist at the same time. Different interfaces are selected according to different schemes.

Architecture 1: Architecture selection Ml is a mandatory interface, and an M2 interface is optional. Architecture 2: Architecture selection M2 is a mandatory interface, and Ml interface is an optional interface.

Based on the architecture one:

Solution 1: The case where the TEK is directly used to protect the media content between the UE and the MF. Suitable for LTV and CoD services. The TEK is generated by the KMF and sent to the MF in a way that the KMF actively sends the MF or MF to the KMF to actively request the key. MF uses TEK to encrypt media content.

Option 2: For the case where the TEK is directly used to protect the media content between the UE and the MF. Suitable for LTV and CoD services. The MF generates TEK, which uses TEK to encrypt media content. The TEK is sent to the KMF in such a way that the MF actively sends the KMF or KMF to the MF request key.

Solution 3: For the case where the MF will directly use the key to protect the media TEK is sent to the UE in multicast mode, the TEK needs to be protected by a key, which is called KEK. Suitable for LTV business and COD business. It can be KMF to generate KEK, MF to generate TEK; KMF actively sends KEK to MF or MF to KMF to request KEK to send KEK to MF, MF uses KEK to encrypt TEK, and the multicast is sent to the UE.

Solution 4: For the case where the MF directly uses the key TEK for protecting the media to be sent to the UE in multicast mode, the TEK needs to be protected by using a key, which is called KEK. Applicable to LTV business and C0D business. KMF generates KEK and TEK; KMF actively sends KEK and TEK to MF or MF to KMF actively requests KEK and TEK.

Architecture 2 uses the M2 interface to pass the key. The specific process is similar to the process of architecture one, except that the path of key transfer between KMF and MF is KMF - M2 - SCF - Core IMS - MF.

In addition, the I PTV media security system described in the above embodiments may further include a content encryption entity for encrypting the media content.

The content encryption entity CEF is configured to generate a media protection key TEK and send the TEK to the key management function entity KMF;

The key management function entity KMF is configured to encrypt the media protection key by using a key encryption key KEK, and send the encrypted media protection key to the content encryption entity.

Or the content encryption entity is configured to generate a media protection key, and send a key request message to the key management function entity, requesting a key encryption key KEK; using the key encryption key pair The media protection key is encrypted;

The key management function entity is configured to provide a key encryption key to the content encryption entity. Or the content encryption entity is configured to send a key request message to the key management function entity;

The key management function entity is configured to generate a key encryption key and a media protection key, and encrypt the media protection key by using a key encryption key according to the key request message; The subsequent media protection key and the unencrypted media protection key are sent to the content encryption entity.

Or the content encryption entity is configured to send a key request message to the key management function entity; and encrypt the media protection key by using a key encryption key;

The key management function entity is configured to generate a key encryption key and a media protection key, and send the key encryption key and the media protection key to the content encryption entity.

Next, the working process diagrams of the above systems will be described with reference to Figs. 23-27.

As shown in Figure 23, a direct interface N1 is used between KMF and CEF to deliver one or more of the following: SEK, TEK, SEK encrypted TEK. Embodiment 14

The CEF generates a TEK, as shown in Figure 24, which includes the following steps:

In step 2401, the CEF generates a media protection key TEK.

Step 2402: The CEF sends a key request message to the KMF, where the content identifier and/or the service identification information and the media protection key TEK are carried.

Step 2403, after receiving the key request message, the KMF encrypts the key SEK with the corresponding key encryption TEK.

This step is optional if the CEF only reports the generated TEK to KMF and does not require a SEK-encrypted TEK.

Step 2404, the KMF sends a response message to the CEF, which carries the TEK encrypted by the SEK.

If step 2403 is not available, then KMF does not send the SEK encrypted TEK parameter in this step. The subsequent processing may be: the content encryption entity CEF sends the encrypted TEK to the user equipment, or the encrypted TEK is sent to the media function entity and sent to the user equipment.

If the CEF only reports the generated TEK to the KMF, the KMF is subsequently responsible for sending the TEK to the user terminal.

Example fifteen

The CEF generates the TEK and obtains the SEK sent by the KMF. As shown in FIG. 25, the method includes the following steps: Step 2501: The CEF sends a key request message to the KMF, requesting the SEK, where the content identifier and/or the service identifier information is carried;

Step 2502, the KMF receives the key request message, and sends the corresponding SEK to the CEF;

In step 2503, the CEF encrypts the TEK using the returned SEK.

The subsequent processing may be: the content encryption entity CEF sends the encrypted TEK to the user equipment, or the encrypted TEK is sent to the media function entity and sent to the user equipment.

Example sixteen

KMF generates TEK and SEK, as shown in Figure 26, including the following steps:

Step 2601, the CEF sends a key request message to the KMF, where the content identifier and/or service is carried. Identification information.

Step 2602: After receiving the key request message, the KMF encrypts the corresponding TEK by using the SEK corresponding to the content identifier and/or the service identifier information.

In step 2603, the KMF sends the SEK encrypted TEK and the unencrypted TEK to the CEF.

Subsequent processing can be: Content Encryption Entity CEF uses TEK to encrypt media. The encrypted TEK is sent to the user equipment, or the encrypted TEK is handed over to the media function entity and sent to the user equipment.

Example seventeen

The CEF obtains the SEK and the TEK sent by the KMF. As shown in FIG. 27, the method includes the following steps: Step 2701: The CEF sends a key request message to the KMF, where the content identifier and/or the service identifier information are carried.

Step 2702: After receiving the key request message, the KMF sends the corresponding SEK and TEK to the CEF. In step 2703, the CEF encrypts the TEK by using the returned SEK.

Specifically, the CEF can be a separate functional entity, or can be combined with KMF as a functional entity, or can be combined with MF as a functional entity. In the case of a combination, CEF as a function module, the interaction with the connected entity becomes internal processing. In Figure 28, the NEK interface between the CEF and the MF entity transmits information such as TEK encrypted by the SEK.

The content encryption entity of the embodiment of the present invention may be the structure shown in any of Figs. 29-32.

As shown in FIG. 29, the content encryption medium of the embodiment of the present invention includes: a key generation unit 2901, configured to generate a media protection key; and a key transceiver unit 2902, configured to send the media protection key to a key management function. entity. The key transceiver unit 2902 is further configured to receive the encrypted media protection key sent by the key management function entity.

As shown in FIG. 30, the content encryption medium in the embodiment of the present invention includes: a key generation unit 3001, Generating a media protection key; a message sending unit 3002, configured to send a key request message to the key management function entity, requesting a key encryption key; and a key transceiving unit 3003, configured to receive and manage the key a key encryption key sent by the functional entity; an encryption operation unit 3004, configured to encrypt the media protection key by using the key encryption key.

As shown in FIG. 31, the content encryption entity of the embodiment of the present invention includes: a message sending unit 31 01, configured to send a key request message to a key management function entity; and a key transceiver unit 31 02, configured to receive the key by the key The encrypted media protection key sent by the management function entity and the unencrypted media protection key.

As shown in FIG. 32, the content encryption entity of the embodiment of the present invention includes: a message sending unit 3201, configured to send a key request message to a key management function entity; a key transceiving unit 3202, configured to receive the key management function The key encryption key and the media protection key sent by the entity; the encryption operation unit 3203 is configured to encrypt the media protection key by using the key encryption key.

In all the above embodiments, if the system of the two-layer key model is used, that is, the user key SUK and the media encryption key TEK are used, the KMF interacts with the CEF and the KMF, so that the KMF obtains the TEK, and The encrypted media is deployed to the MF, specifically CEF encrypted media and the encrypted media is sent to the MF. The UE obtains the TEK through the TEK embodiment obtained from the KMF to the SUK encryption described above, and then uses the TEK to decrypt the encrypted media sent by the MF.

In all of the above embodiments, if the system of the three-layer key model is used, the user key SUK, the media encryption key TEK and the key encryption key KEK are used. The specific step may be that the CEF uses the TEK encryption medium and sends the encrypted media to the MF. For the KEK-encrypted TEK to be sent to the UE: The CEK-encrypted TEK can be sent to the MF by the CEF, and then sent by the MF to the UE through the multicast media channel. After the CEF reports the CEF to the KMF, the KMF uses the KEK. Encrypt the TEK, and then the KEK encrypts the TEK encrypted by the KEK to the UE through the multicast media channel. The UE obtains the SUK encrypted KEK through the above-mentioned embodiment of acquiring the key with KMF, obtains the KEK encrypted TEK and TEK encrypted media through the multicast channel, and then uses the KEK decryption to obtain the TEK, and then uses the TEK to decrypt the encrypted media. In the case where the CEF is an internal module of KMF or MF, the above interaction becomes internal processing.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium. In execution, the flow of an embodiment of the methods as described above may be included. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Acces s Memory (RAM).

The above is a description of specific embodiments of the present invention, and the method of the present invention may be appropriately modified in a specific implementation process to suit the specific needs of a specific situation. Therefore, it is to be understood that the specific embodiments of the present invention are not intended to limit the scope of the invention.

Claims

Claim

A system for implementing IPTV media security, comprising an IMS core network IMS Core, wherein the system further comprises: a user equipment UE, a service control function entity SCF, a media function entity MF, and a key management function entity KMF, where,

The user equipment is configured to receive the encrypted media sent by the media function entity, and use the received key to obtain the unencrypted media.

2. The system for implementing IPTV media security according to claim 1, wherein the key management function entity provides a key to the user equipment through a K2 interface with the user equipment.

The system for implementing IPTV media security according to claim 1, wherein the user equipment sends a key request message to the key management function entity, where the key request message includes a service identifier, Content identification or key identification information;

After receiving the key request message, the key management function entity sends a corresponding to the service identifier, the content identifier, or the key identifier information to the user equipment by using a K2 interface with the user equipment. Key.

The system for implementing IPTV media security according to claim 2 or 3, wherein the key management function entity obtains a key from the service control function entity or the user data function before transmitting the key to the user equipment. The service authorization information of the user equipment, and determining that the user equipment has the right to acquire the key.

The system for implementing IPTV media security according to claim 1, wherein the service control function entity acquires a key by using a K1 interface with the key management function entity;

The service control function entity sends the key through a K3 interface with the user equipment.

The system for implementing IPTV media security according to claim 1, wherein the user equipment sends a key request message to the service control function entity, where the key request message includes a service identifier or content. Identification information;

The service control function entity acquires, by using a K1 interface between the key management function entity, a key corresponding to the service identifier or the content identifier to the key management function entity;

After receiving the key, the service control function entity sends the key to the user equipment through a K3 interface with the user equipment.

The system for implementing IPTV media security according to claim 1, wherein the service control function entity is obtained by the key management function entity through a K1 interface with the key management function entity. Key

The service control function entity sends the key to the user equipment through an IMS Core.

The system for implementing IPTV media security according to claim 1, wherein the user equipment sends a request message to the service control function entity through the IMS Core, and includes a service identifier or a content identifier in the key request message. Information

Obtaining, by the K1 interface between the service control function entity and the key management function entity, a key corresponding to the service identifier or the content identifier to the key management function entity;

The system for implementing IPTV media security according to claim 8, wherein the request message includes GBA temporary user identification information, and the service control function entity sends the GBA temporary user identification information to the a key management function entity;

The key management function entity obtains a user key by using the GBA temporary user identification information, and encrypts the key requested by the request message by using the user key, and then uses the encrypted key of the request message request Sent to the service control function entity.

10. The system for implementing IPTV media security according to claim 1, wherein the media function entity obtains a secret from the key management function entity through a K5 interface with the key management function entity. Key; or the media function entity passes Y2 with the IMS Core The interface, the IMS Core, and the interface K4 interface between the key management function entity, and acquiring the key to the key management function entity;

The media function entity sends the key to the user equipment through an IMS Core.

The system for implementing IPTV media security according to claim 1, wherein the user equipment sends a request message to the service control function entity through the IMS Core, and carries the service or content identification information in the request message;

The service control function entity sends a request message to the media function entity through the IMS Core; the media function entity acquires a key corresponding to the service or content identification information from the key management function entity, and controls the service to the service The functional entity sends a response message, where the key is carried in the response message;

The service control function entity sends a response message to the user equipment through the IMS Core, where the key is carried.

The system for implementing IPTV media security according to claim 11, wherein the media function entity acquires the information from the key management function entity through a K5 interface with the key management function entity. Key; or,

The media function entity acquires the key from the key management function entity through a Y2 interface with the IMS Core, an interface K4 interface between the IMS Core and the key management function entity.

13. The system for implementing IPTV media security according to claim 1, wherein the user equipment subscribes to the service control function entity SCF a key corresponding to the current service/content or any service/content;

The service control function entity SCF obtains the corresponding key by the key management function entity through the K1 interface with the key management function entity, and then sends the key to the user equipment through the IMS Core.

The system for implementing IPTV media security according to claim 1, wherein the user equipment subscribes to the key service function entity KMF for the current service/content or the key corresponding to any service/content; After acquiring the current service/content or any service/content key, the key management function entity KMF sends the key to the user equipment through a K4 interface with the IMS Core.

The system for implementing IPTV media security according to any one of claims 1, 2, 3, and 5-14, wherein the key is a key encryption key KEK, and the key is encrypted. The key KEK is used to encrypt the media protection key TEK, and the media protection key TEK is used to directly encrypt the media.

The system for implementing IPTV media security according to claim 15, wherein the media protection key TEK is sent by the key management function entity or the media function entity to the user equipment.

The system for implementing IPTV media security according to any of claims 11-14, wherein the key is a media protection key TEK, and the media protection key TEK is used to directly encrypt the media.

The system for implementing IPTV media security according to any one of claims 1 to 2, 3, 5-14, wherein the system further comprises:

A content encryption entity that is used to encrypt media content.

The system for implementing IPTV media security according to claim 18, wherein the content encryption entity is further configured to generate a media protection key TEK, and the media protection key

The TEK is sent to the key management function entity, and the media protection function TEK is sent by the key management function entity to the user equipment.

The system for implementing IPTV media security according to claim 18, wherein the content encryption entity is configured to receive a media protection key TEK sent by the key management function entity, and use the media Protection key TEK encrypted media;

The key management function entity is configured to generate a media protection key TEK, and send the media protection key TEK to the content encryption entity.

The system for implementing IPTV media security according to claim 18, wherein the content encryption entity is configured to generate a media protection key TEK, and the media protection key

The TEK is sent to the key management function entity; The key management function entity is configured to encrypt the media protection key TEK by using a key encryption key KEK, and send the encrypted media protection key TEK to the content encryption entity, so that the The content encryption entity sends the encrypted TEK to the user equipment, or the encrypted TEK is handed over to the media function entity, and sent by the media function entity to the user equipment.

The system for implementing IPTV media security according to claim 18, wherein the content encryption entity is configured to generate a media protection key TEK, and send a key request message to the key management function entity, Requesting a key encryption key KEK; encrypting the media protection key TEK with the key encryption key KEK, the content encryption entity transmitting the encrypted TEK to the user equipment, or handing over the encrypted TEK And being sent to the user equipment by the media function entity;

The key management function entity is configured to provide a key encryption key KEK to the content encryption entity.

The system for implementing IPTV media security according to claim 1, wherein the key management function entity is a logical function module in the service control function entity or the media function entity.

A method for implementing IPTV media security, the method includes the following steps: The user equipment UE obtains a key corresponding to the media service security from the key management function KMF;

Receiving, by the user equipment UE, the encrypted media sent by the media function entity MF;

The user equipment UE obtains the decrypted media using the key.

The method for implementing the IPTV media security according to claim 24, wherein the step of the user equipment UE obtaining the key corresponding to the media service security from the key management function KMF is specifically:

The key management function entity receives a key request message sent by the user equipment, where the key request message carries a service identifier, a content identifier, or a key identifier information;

The key management function entity sends a key corresponding to the service identifier, the content identifier, or the key identifier information to the user equipment.

26. The method for implementing IPTV media security according to claim 24, wherein The step of the user equipment UE obtaining the key corresponding to the media service security from the key management function KMF is specifically:

The user equipment sends a request message to the service control function entity, where the request message includes a service identifier or content identifier information;

The service control function entity obtains a key by using a K1 interface with the key management function entity, and acquires a corresponding key by the key management function entity;

The user equipment sends a request message to the service control function entity through the IMS Core; the service control function entity acquires a corresponding key by the key management function entity; the service control function entity uses the IMS Core to set the secret The key is sent to the user equipment.

The user equipment sends a request message to the service control function entity through the IMS Core, and carries the service identifier or the content identifier information in the request message;

The service control function entity sends a response message to the user equipment through the IMS Core; where the key is carried.

29. The method for implementing IPTV media security according to claim 24, wherein The step of the user equipment UE obtaining the key corresponding to the media service security from the key management function KMF is specifically:

The user equipment subscribes to the service control function entity SCF for the current service/content or the key corresponding to any service/content;

The user equipment subscribes to the key management function entity KMF for the current service/content or the key corresponding to any service/content;

After obtaining the current service/content or any service/content key, the key management function entity KMF sends the key to the user equipment through a K4 interface with the IMS Core.

31. A key management function entity, comprising: a key distribution unit and a key information service function unit;

a key information service function unit, configured to provide a key related to media service security to the key distribution unit;

And a key distribution unit, configured to send the key related to the media service security to the user equipment.

32. A content encryption entity, comprising:

a key generation unit, configured to generate a media protection key;

And a key transceiver unit, configured to send the media protection key to the key management function entity.

33. The content encryption entity of claim 32, wherein:

The key transceiving unit further receives the encrypted media protection key sent by the key management function entity.

34. A content encryption entity, comprising: a key generation unit, configured to generate a media protection key;

a message sending unit, configured to send a key request message to the key management function entity, requesting a key encryption key KEK;

a key transceiving unit, configured to receive a key encryption key sent by the key management function entity

KEK;

And an encryption operation unit, configured to encrypt the media protection key by using the key encryption key KEK.