WO2009024071A1 - Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv - Google Patents

Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv Download PDF

Info

Publication number
WO2009024071A1
WO2009024071A1 PCT/CN2008/072015 CN2008072015W WO2009024071A1 WO 2009024071 A1 WO2009024071 A1 WO 2009024071A1 CN 2008072015 W CN2008072015 W CN 2008072015W WO 2009024071 A1 WO2009024071 A1 WO 2009024071A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
function entity
media
service
user equipment
Prior art date
Application number
PCT/CN2008/072015
Other languages
English (en)
Chinese (zh)
Inventor
Zhaojun Peng
Zhanjun Zhang
Jincheng Li
Jun Yan
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009024071A1 publication Critical patent/WO2009024071A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Definitions

  • 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.
  • IMS Core also known as Core IMS
  • 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).
  • CSCF Call Control Function
  • UPSF User Profile Serving Function
  • S_CSCF service CSCF
  • P-CSCF proxy CSCF
  • I-CSCF query 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.
  • IP Internet Protocol
  • 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).
  • LTV service is a service for transmitting media content to the UE in a multicast manner
  • 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.
  • MCF Media Function Function
  • MDF Media Delivery Function
  • 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 are used to process Provides IPTV service control from the IPTV service request sent by the UE.
  • UPSF User Profile Serving Function
  • SSF Service Selection Function
  • 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.
  • 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.
  • 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.
  • a conditional access (CA) method is a method for protecting media content security used in traditional broadcast television.
  • the UE 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.
  • TS Transport Stream
  • 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).
  • the SK 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.
  • ECM Entitlement Control Message
  • EMM Entitlement Management Message
  • the process of transmitting the media content is as shown in FIG. 3.
  • the UE 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.
  • 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.
  • 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.
  • 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.
  • 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
  • a key distribution unit configured to send the key related to the media service security to the user equipment.
  • the system, method, and device provided by the embodiments of the present invention can implement protection of IPTV media content.
  • an embodiment of the present invention further provides a content encryption entity, including:
  • a key generation unit configured to generate a media protection key
  • 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.
  • the content encryption entity encrypts the media content by using the media protection key, so that the security of the media content is ensured.
  • FIG. 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.
  • 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
  • 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
  • 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;
  • 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
  • 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.
  • FIG. 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.
  • 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.
  • KMF Key Management function entity
  • KMF Key Manage Funct ion
  • 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.
  • CEF Content Encryption Function
  • 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.
  • 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.
  • PKI Program Encryption Key
  • 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.
  • 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.
  • different levels of UEs may have different receiving media stream rights.
  • 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.
  • the general SEK, PEK or SGK is used for the protection of the TEK.
  • 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 is used to authenticate the user of the IPTV service.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the protected media content needs to be different from the used key, and may be a single or multiple different media streams.
  • 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.
  • the UE can decrypt the obtained KEK to obtain the TEK, and then decrypt the media stream with TEK.
  • 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.
  • KEK or TEK is commonly referred to as a key
  • 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.
  • KMF can generate or obtain keys and/or related parameters from other functional entities.
  • KMF can also update keys and/or related parameters.
  • the required functional entity may be a functional entity such as a UE, an MF, or an SCF
  • 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.
  • 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.
  • these interfaces are not all mandatory in the architecture of the specific implementation.
  • 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.
  • the K5 interface is required, and other interfaces are optional.
  • KMF directly transmits the key through the IMS Core
  • the K4 interface is required. The interface is optional.
  • 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.
  • 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.
  • the K2 interface is a necessary interface.
  • the connections between the devices in the system shown in Fig. 4 are as shown in Fig. 5.
  • 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.
  • 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.
  • a key request message such as an HTTP request message
  • 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.
  • 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.
  • the key model is a three-layer key model
  • the key issued in step 605 is KEK
  • KEK uses SUK.
  • 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.
  • 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.
  • 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.
  • Token service authorization token
  • 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.
  • 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).
  • EPG electronic decryption menu
  • 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.
  • 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.
  • 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.
  • This embodiment can be applied to LTV service protection or CoD service protection, mainly for the UE to distribute keys through SCF and KMF.
  • the K3 interface and K in the architecture are applied.
  • the 1 interface is a mandatory interface.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a service request message such as an INVITE
  • 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.
  • the MF can use this key to encrypt the content in real time.
  • 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.
  • 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.
  • 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.
  • 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.
  • a service request message such as an INVITE message
  • 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.
  • 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.
  • a service response message for example, a 200 0K message
  • 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.
  • 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 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.
  • 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.
  • a service request message for example, INVITE
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the key model is a three-layer key model
  • the key requested in step 1202 is KEK
  • 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.
  • 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.
  • 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.
  • B-TID can use S IP request
  • the element corresponding to the XML in the message is carried.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SCF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 0K message.
  • 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.
  • 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 specific B-TID can be carried using the element corresponding to the XML in the request message.
  • This embodiment can be applied to the LTV service and the CoD service.
  • 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.
  • 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.
  • 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.
  • the SCF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 0K message.
  • 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.
  • 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.
  • 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 specific B-TID can be carried using the element corresponding to the XML in the request message.
  • 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.
  • 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.
  • 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.
  • the KMF obtains the UE's current service mode.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the KMF transmits the updated key information to the UE through Not ify, and the UE replies with the 200 OK message.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the required functional entity may be a functional entity such as a UE or an MF
  • 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.
  • 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;
  • 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.
  • 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.
  • 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.
  • the S1 interface in the architecture is a mandatory interface.
  • 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.
  • Step 1801 The UE performs a session process of service establishment or service switching (channel switching of the LTV).
  • 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.
  • 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.
  • 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.
  • 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.
  • the required functional entity may be a functional entity such as a UE or an SCF
  • 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.
  • the K5 interface between the MF and the KMF described in FIG. 4 does not exist or becomes an internal interface
  • the L1 interface between the MF and the SCF has an existing function, and also has a UE.
  • 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.
  • 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.
  • 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.
  • FIG. 20 is a flowchart of Embodiment 13 of implementing media content security according to an embodiment of the present invention.
  • 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.
  • 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.
  • a service request message such as an INVITE message
  • 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.
  • a service response message such as a 200 0K message
  • 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.
  • 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.
  • each of the above embodiments in which the KMF is an independent functional entity can be handled similarly to this embodiment.
  • the network side may be in the UE.
  • 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.
  • the KMF sends the key to the MF through M1, or sends the message through M2, SCF, Core IMS.
  • M1 the key to the MF
  • M2 the message through M2
  • SCF Sends the message through M2
  • Core IMS the message through M2
  • the MF in this figure performs the encryption processing of the service protection.
  • 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.
  • 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.
  • KEK a key
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a direct interface N1 is used between KMF and CEF to deliver one or more of the following: SEK, TEK, SEK encrypted TEK.
  • the CEF generates a TEK, as shown in Figure 24, which includes the following steps:
  • 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.
  • step 2403 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.
  • the KMF is subsequently responsible for sending the TEK to the user terminal.
  • the CEF generates the TEK and obtains the SEK sent by the KMF.
  • 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • CEF as a function module
  • the interaction with the connected entity becomes internal processing.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the UE 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.
  • the CEF is an internal module of KMF or MF
  • the above interaction becomes internal processing.
  • the storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a Random Acces s Memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Un mode de réalisation de l'invention concerne un système, un procédé et un dispositif pour réaliser une protection de sécurité de contenu multimédia de télévision sur IP (IPTV), relatifs au domaine des communications, visant à réaliser une protection de contenu multimédia IPTV. Le système comprend : un équipement utilisateur (UE), une entité fonctionnelle de commande de service (SCF), un réseau central IMS (noyau IMS), une entité fonctionnelle multimédia (MF) et une entité fonctionnelle de gestion de clé (KMF), l'entité fonctionnelle multimédia servant à fournir une clé pour l'équipement utilisateur ; ladite entité fonctionnelle de commande de service servant à fournir une commande de service de service IPTV ; ladite entité fonctionnelle multimédia servant à envoyer du contenu multimédia crypté à l'équipement utilisateur ; ledit équipement utilisateur servant à recevoir le contenu multimédia provenant de l'entité fonctionnelle multimédia, et à utiliser la clé reçue pour obtenir le contenu multimédia décrypté. Le mode de réalisation de l'invention est appliqué à IPTV.
PCT/CN2008/072015 2007-08-17 2008-08-15 Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv WO2009024071A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710146735 2007-08-17
CN200710146735.5 2007-08-17

Publications (1)

Publication Number Publication Date
WO2009024071A1 true WO2009024071A1 (fr) 2009-02-26

Family

ID=40377855

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/072015 WO2009024071A1 (fr) 2007-08-17 2008-08-15 Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv

Country Status (2)

Country Link
CN (1) CN101369886A (fr)
WO (1) WO2009024071A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101521570B (zh) * 2008-02-27 2012-09-19 华为技术有限公司 一种实现iptv组播业务媒体安全的方法、系统及设备
CN101510825B (zh) * 2009-02-25 2014-04-30 中兴通讯股份有限公司 一种管理消息的保护方法及系统
MX2011005294A (es) * 2009-05-18 2011-06-17 Ericsson Telefon Ab L M Metodo para ejecutar la funcionalidad ims en la caja sobre el aparato.
CN101729535B (zh) * 2009-06-30 2013-03-20 中兴通讯股份有限公司 一种媒体点播业务的实现方法
CN101998384B (zh) * 2009-08-18 2014-03-26 中国移动通信集团公司 一种加密传输媒体流的方法、加密服务器和移动终端
CN102546574B (zh) * 2010-12-24 2014-10-08 中国移动通信集团公司 基于ip多媒体子系统的流媒体点播方法和装置
CN105656621A (zh) * 2014-11-12 2016-06-08 江苏威盾网络科技有限公司 一种密码设备安全管理方法
US10779345B2 (en) 2017-03-20 2020-09-15 Qualcomm Incorporated User plane relocation techniques in wireless communication systems
CN112118206B (zh) * 2019-06-19 2022-04-12 贵州白山云科技股份有限公司 一种解密方法、装置、系统、介质及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1848944A (zh) * 2005-04-05 2006-10-18 华为技术有限公司 一种iptv系统、加密数字节目的发布、收看方法
CN1946162A (zh) * 2006-10-27 2007-04-11 华为技术有限公司 一种获取epg的方法及iptv业务系统
WO2007070652A1 (fr) * 2005-12-15 2007-06-21 Lucent Technologies Inc. Procede et reseau pour proposer un eventail de services a un abonne

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1848944A (zh) * 2005-04-05 2006-10-18 华为技术有限公司 一种iptv系统、加密数字节目的发布、收看方法
WO2007070652A1 (fr) * 2005-12-15 2007-06-21 Lucent Technologies Inc. Procede et reseau pour proposer un eventail de services a un abonne
CN1946162A (zh) * 2006-10-27 2007-04-11 华为技术有限公司 一种获取epg的方法及iptv业务系统

Also Published As

Publication number Publication date
CN101369886A (zh) 2009-02-18

Similar Documents

Publication Publication Date Title
JP4705958B2 (ja) ブロードキャスト／マルチキャストサービスにおけるデジタル著作権管理方法
WO2009024071A1 (fr) Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv
KR101203266B1 (ko) 스트리밍을 위한 제어 프로토콜 및 전송 프로토콜을 사용한보호 콘텐츠 반송
US8738910B2 (en) Method and arrangement for enabling play-out of media
US8948394B2 (en) Method and apparatus for distribution and synchronization of cryptographic context information
US20090180614A1 (en) Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network
JP5153938B2 (ja) 通信ネットワークにおけるｉｐｔｖセキュリティ
EP2319224B1 (fr) Serveur d'application, système de distribution de média, procédé de commande associé, programme et support de stockage lisible par un ordinateur
JP2011172276A (ja) コンテンツの保護のためのエンティティ同士の関連付け方法及び装置、並びにそのシステム
US8645680B2 (en) Sending media data via an intermediate node
WO2007085186A1 (fr) Procédé de gestion de clé de flux multimédia, système et serveur d'application
US8417933B2 (en) Inter-entity coupling method, apparatus and system for service protection
KR20060105934A (ko) 브로드캐스트 서비스를 지원하는 서비스 제공자와 단말기간에 디지털 저작권 관리 컨텐츠 공유 방법 및 장치,그리고 그 시스템
WO2009132551A1 (fr) Procédé d’obtention de clé de flux multimédia, équipement de session et entité à fonction de gestion de clé
JP2003229844A (ja) データ転送システム
CN101521570B (zh) 一种实现iptv组播业务媒体安全的方法、系统及设备
WO2008128475A1 (fr) Système de télévision sur ip à base d'architecture ims et entité de service de protection de contenu et procédé
CN118018776A (zh) 一种视联网点播业务的实现方法、装置、设备及介质
Lee et al. License administration mechanism for multiple devices in a domain.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08784006

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08784006

Country of ref document: EP

Kind code of ref document: A1