WO2009106007A1 - 一种实现iptv组播业务媒体安全的方法、***及设备 - Google Patents

一种实现iptv组播业务媒体安全的方法、***及设备 Download PDF

Info

Publication number
WO2009106007A1
WO2009106007A1 PCT/CN2009/070557 CN2009070557W WO2009106007A1 WO 2009106007 A1 WO2009106007 A1 WO 2009106007A1 CN 2009070557 W CN2009070557 W CN 2009070557W WO 2009106007 A1 WO2009106007 A1 WO 2009106007A1
Authority
WO
WIPO (PCT)
Prior art keywords
sek
media
service
tek
kmf
Prior art date
Application number
PCT/CN2009/070557
Other languages
English (en)
French (fr)
Inventor
张占军
何承东
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2009106007A1 publication Critical patent/WO2009106007A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, system and device for implementing IPTV multicast service media security. Background technique
  • the IMS IP Multimedia Core Network Subsystem
  • 3GPP The Third Generation Partnership Project
  • SIP Session Initiation Protocol
  • the IMS Core includes the following logical functional entities: S-CSCF (Service-Call Session Control Function, Service CSCF), P-CSCF (Proxy-Call Session Control Function, Proxy CSCF), and I-CSCF (Query CSCF) ).
  • the IPTV (IP Television) service based on the IMS network is a system for transmitting multimedia over an IP (Internet Protocol) network, including media content such as video and audio.
  • IP Internet Protocol
  • the service essentially provides IPTV services under the IMS network architecture, and fully utilizes the existing session control and charging mechanisms in the IMS network to provide TV-type multimedia services for the UE (User Equipment).
  • the typical service example of IPTV is LTV (Linear Television) service.
  • the LTV service sends media to the UE in IP multicast mode. For all users who watch the same program, the program content received at each moment is exactly the same. of. Of course, for the case where the same service content needs to be simultaneously sent to multiple users, the multicast mode can be used. Can be seen as a multicast service.
  • CA Consumer Access
  • CW Control Word
  • SK Service Key
  • SK is transmitted in the EMM (Entitlement Management Message), and the SK is encrypted by the PDK (Personal Distribution Key) before being transmitted, and the PDK is stored in the user.
  • SC Smart Card, Smart Card.
  • the existing CA system is suitable for a digital television broadcasting network without a return channel, and the EMM message sent to each user adopts a corresponding user key.
  • the user needs to be grouped and rotated to deliver EMM, and can only be applied to the TS encapsulation format.
  • the IMS-based IPTV system there is a return channel, and there is a media format directly using the RTP encapsulation. Therefore, the prior art cannot be directly applied to the IMS-based IPTV system. Summary of the invention
  • the embodiments of the present invention provide a method, a system, and a device for implementing IPTV multicast service media security, and the SEK and TEK of the multicast media protection in the IMS-based IPTV system are delivered.
  • the embodiment of the invention provides a method for implementing media security of an IPTV multicast service, including: The user equipment UE obtains the service encryption key SEK from the key management function KMF; the UE receives the media encryption key TEK key stream encrypted by the SEK sent by the multicast;
  • the UE decrypts the TEK using the SEK and uses the TEK to decrypt the multicast media encrypted by the TEK.
  • the embodiment of the invention provides a system for implementing media security of an IPTV multicast service, including:
  • a key management function entity configured to send a SEK to the user equipment, and deploy the SEK encrypted TEK to the media service function entity;
  • a media service function entity configured to send the encrypted multicast media to the user equipment, and the SEK encrypted TEK corresponding to the encrypted multicast medium;
  • a user equipment configured to obtain an SEK from the key management function entity, receive a multicast sent TEK key stream protected by the SEK encryption from the media service function entity, and decrypt the TEK using the SEK, and use The TEK decrypts the multicast media encrypted by TEK.
  • An embodiment of the present invention provides a key management function entity for implementing IPTV multicast service media security, including:
  • a SEK sending module configured to send a SEK to the user equipment
  • the TEK deployment module is used to deliver one of the following information to the MCF or CEF: SEK, TEK or SEK encrypted TEK.
  • the embodiment of the invention provides a user equipment for implementing IPTV multicast service media security, including:
  • a SEK acquisition module configured to obtain a SEK from a key management function entity
  • a TEK obtaining module configured to receive, from the media service function entity, a multicast sent TEK key stream protected by the SEK encryption;
  • a decryption module configured to decrypt the TEK by using the SEK, and use the TEK to decrypt the multicast media encrypted by the TEK.
  • the LTV multicast media transmission security of the IMS-based IPTV architecture is implemented by distributing the keys SEK and TEK to the UE and the media service function entity.
  • Figure la is a service function architecture diagram of IMS based IPTV in an application scenario in the embodiment of the present invention.
  • Figure lb is a schematic diagram of a key system in an embodiment of the present invention.
  • FIG. 2 is a structural diagram of a functional entity in an embodiment of the present invention.
  • FIG. 3 is a flowchart of media protection type information and/or SEK key identification information of each channel delivered by an EPG of an SSF according to an embodiment of the present invention; a type information and/or a SEK key identification information flowchart;
  • FIG. 5 is a schematic diagram of acquiring a SEK architecture from a KMF based on a K1 interface according to an embodiment of the present invention
  • FIG. 6 is a flowchart of acquiring a SEK from a KMF based on a K1 interface according to an embodiment of the present invention
  • FIG. 7 is a KIM interface based on a KMF interface in an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of acquiring an SEK architecture from a KMF based on a K2 interface according to an embodiment of the present invention
  • FIG. 9 is another architecture diagram of acquiring a SEK from a KMF based on a K2 interface according to an embodiment of the present invention;
  • FIG. 10 is a flowchart of acquiring a SEK from a KMF based on a K2 interface according to an embodiment of the present invention
  • FIG. 11 is a block diagram of acquiring a SEK from a KMF based on a K2 interface according to an embodiment of the present invention
  • FIG. 12 is a flowchart of acquiring a SEK from a KMF based on a K2 interface according to an embodiment of the present invention
  • FIG. 13 is a structural diagram of transmitting information between a KMF and an MCF/MDF through a direct interface according to an embodiment of the present invention
  • FIG. 14 is a structural diagram of information transfer between a KMF and an MCF/MDF through a Y2 interface and an ISC interface in an embodiment of the present invention
  • FIG. 15 is a flow chart of a TEK in which MCF/MDF (CEF) generates TEK and KMF generates SEK encryption in an embodiment of the present invention
  • 16 is a flow chart of TEK for generating TEK and SEK encryption by MCF/MDF (CEF) in an embodiment of the present invention
  • 17 is a TEK stream in which KMF generates TEK and SEK encryption in an embodiment of the present invention.
  • 19 is a structural diagram of a TEK interface for transferring a key between an MCF and an MDF in an embodiment of the present invention
  • FIG. 20 is a flow chart of the MCF transmitting the TEK to the MDF in the embodiment of the present invention
  • FIG. 21 is a flowchart of the MCF sending media protection mode to the MDF in the embodiment of the present invention
  • FIG. 22 is a media security for implementing the IPTV multicast service in the embodiment of the present invention
  • KMF structure diagram
  • FIG. 23 is a structural diagram of a user equipment for implementing IPTV multicast service media security in an embodiment of the present invention. detailed description
  • the service function architecture of the IMS based IPTV in the application scenario of the embodiment of the present invention mainly includes: UE (User Equipment), such as a mobile phone, a set top box, and the like; SDF (Service Discovery Function) ;), for providing the UE with service attachment information, such as EPG (Electronic Program Guide) server address information, etc.; SSF (Service Selection Function), for providing service menu information to the UE; SCF (Service Control Function, service control function entity;), for processing user service requests; UPSF (User Profile Server Function), for storing user subscription information; Core IMS (Core IMS), for IMS subsystem The general name of P-CSCF, I-CSCF and S-CSCF; MF (Media Functions, media function entity), responsible for controlling and delivering media to the UE media stream, from the functional perspective to MCF (Media Control Function, media control) Functional entity) and MDF (Media Delivery Function)
  • the MCF is used to control the MDF to send the media stream, the MDF
  • the key system used in the embodiment of the present invention is as shown in FIG. 1b and includes: TEK ( Traffic Encryption Key, media encryption and integrity protection for media streams, MPEG2TS (Moving Picture Expert Group 2 Transport Stream - Conditional Access), conditional access protection in MPEG2 TS mode Mode)
  • the corresponding key is CW.
  • SEK Service Encryption Key
  • the key corresponding to the MPEG2TS transmission mode protected by the traditional CA is SK.
  • SK protects the confidentiality issued by the CW.
  • URK User Root Key
  • the user root key can be established in GBA mode or pre-configured.
  • the key corresponding to the MPEG2TS transmission mode protected by the conventional CA may be an existing PDK, or may be established by using a GBA, or a pre-configured URK.
  • the keys in the embodiment are uniformly described using URK, SEK, and TEK, and are also applicable to the embodiments of PDK, SK, and CW of the CA system.
  • the functional entity in the embodiment of the present invention includes: KMF (Key Management Function), which is used to provide a key for media protection to a UE or other functional entity, and KMF can be used as an independent
  • KMF Key Management Function
  • the functional entity, or as a functional module, is integrated into the SCF or other functional entities.
  • the CEF Content Encryption Function
  • the MCF/MDF performs the CEF function.
  • the method for implementing IPTV multicast service media security in conjunction with FIG. 2 includes the following steps:
  • Step 201 Service deployment process: KMF and MCF/MDF (complete CEF function) Pass one or more of the following information SEK, TEK, SEK encrypted TEK, and deploy the SEK encrypted TEK to the MDF.
  • KMF and MCF/MDF complete CEF function
  • Another way to encrypt using CEF includes:
  • Step 201a KMF and CEF pass one or more of the following information to the CEF: SEK, TEK, SEK TEK;
  • step 201b the CEF sends the SEK encrypted TEK to the MCF/MDF (without CEF function).
  • step 201 (steps 201a and 201b) is not required.
  • Step 202 The UE obtains the SEK from the KMF.
  • the SEK can also be protected by URK encryption, and the URK encrypts the SEK by encrypting the SEK or URK to complete the encryption protection of the SEK. After receiving the encrypted SEK, the UE decrypts the SEK using the URK.
  • the UE Before the UE obtains the SEK, if the UE does not have the session description protocol SDP description information and/or the media security description information of the TEK key stream, the UE needs to obtain the media security description information from the media service function entity through the SSF or the SCF.
  • Step 203 When transmitting the encrypted multicast medium, the MDF sends the TEK encrypted by the SEK corresponding to the encrypted multicast medium to the UE through the IP multicast.
  • Step 204 The UE receives the encrypted multicast media and the TEK key stream sent by the multicast, decrypts the TEK by using the SEK, and decrypts the multicast media by using the TEK.
  • the media security description information mentioned in step 202 of the embodiment includes one or more of the following information: a media protection type identifier, a SEK key identifier, and an address information of the SEK.
  • the media protection type identifier is used to indicate the protection type of the media stream sent to the UE, for example, the type protection using SRTP (Security Real-time Transport Protocol), or the CA protection type using MPEG2TS.
  • SRTP Security Real-time Transport Protocol
  • CA protection type using MPEG2TS MPEG2TS.
  • the session description protocol of the TEK key stream The SDP description information and/or the media security description information are delivered in the following ways:
  • a Media-Protection-Typt: MPEG-TS-CA;
  • SRTP For the protection type using SRTP, SRTP can be used as the identifier; for the CA protection type of MPEG2TS, MPEG2TS-CA can be used as the identifier.
  • an SDP that uses SRTP-protected audio streams is:
  • the algorithm parameter may be further carried to indicate the algorithm used by the UE for the media protection, and the specific attribute may be carried by using an attribute of an SDP:
  • an AES-Counter Mode algorithm using a 128-bit key corresponding to a MPEG2 TS-CA protected video media stream is represented as:
  • a fmtp: Media-Protection-Typt: MPEG2TS-CA; AES-CM-128; 2.
  • the SDP of the multicast media carries the key identifier (ID) of the SEK and/or the address information (URI) of the SEK.
  • the UE uses the key identifier (ID) of the SEK to obtain the SEK key corresponding to the ID from the KMF;
  • the UE requests the SEK corresponding to the service packet and/or the channel identifier by using "Get SEK Address Information (URI)".
  • URI Get SEK Address Information
  • the SDP description in the session level is carried, or carried in the SDP description of the media level or in the SDP description of the key stream, for example, using an a attribute in the SDP to carry the key identifier, or using the SDP
  • the k header field is used to carry the address information of the SEK. For example, the following uses the SDP of the key stream to carry:
  • the SDP description of the TEK key stream can also carry two adjacent TEK multicasts.
  • the interval of the key update is used to indicate how often the UE obtains the updated TEK.
  • the specific implementation uses an a attribute to carry, for example:
  • Use the XML to carry the media protection type information Use the media protection type information carried by the SDP, the protection type of the media, the key identifier (ID) of the SEK, the address information (URI) of the SEK, and the adjacent two TEK multicast secrets.
  • One or more of the key update intervals can be sent to the UE using an element of XML:
  • the media protection type protection-type
  • SEK-ID SEK identifier
  • the specific embodiments of the SDP description information and/or the media security description information of the UE acquiring the TEK key stream in the step 202 include the following:
  • the SDP description information and/or the media security description information of the TEK key stream corresponding to each service packet identifier and/or the channel identifier (or the service identifier) are delivered through the EPG delivery process of the SSF, as shown in FIG. 3 Show, including the following steps:
  • Step 301 The UE sends an EPG request message to the SSF.
  • the request message can use a GET or POST request message in HTTP (HyperText Transfer Protocol). If the EPG is broadcast to the UE, for example, using the FLUTE mode broadcast transmission defined in 3GPP, the request message of step 301 is not required.
  • Step 302 The SSF sends a message, such as an HTTP 200 response message, to the UE, where the SEK key identifier of the SEK corresponding to each service packet identifier and/or channel (or service) is carried and/or the address information of the SEK is obtained.
  • the corresponding media protection type information and/or the key stream may also be carried.
  • the SDP description information is the same as the above SDP mode or XML representation and carrying method.
  • the SDP description information and/or the media security description information of the TEK key stream corresponding to the initial channel (or the service) is delivered by using a session initiation protocol (SIP), as shown in FIG. Steps:
  • Steps 401-402 the UE sends an INVITE service request message to the SCF via the Core IMS, where the identifier information of the initial channel (or service) is carried.
  • Steps 403-404 the SCF sends a service response (183 or 200) message to the UE via the Core IMS, where the initial channel (or service) identifier carries the key identifier corresponding to the SEK and/or obtains the address information of the SEK.
  • the initial channel (or service) identifier carries the key identifier corresponding to the SEK and/or obtains the address information of the SEK.
  • Step 405 The UE continues to perform the subsequent session flow.
  • step 403 and step 404 the corresponding media protection type information and/or the SDP description information of the TEK key stream may also be carried.
  • the foregoing information is the same as the SDP mode or the XML representation mode and the carrying method.
  • the UE directly requests the SEK from the KMF, and can be carried by using the HTTP request.
  • the SEK is obtained from the KMF based on the K1 interface in FIG. 5, and the specific process is as shown in FIG. 6, which includes the following steps:
  • Step 601 The UE sends a request message to the KMF, for example, using a GET or POST request message in the HTTP, where one or more of the following information is carried: a service packet identifier, a channel (service) identifier, and a key ID identifier of the SEK;
  • the key ID information here carries the key ID information of the SEK.
  • Step 602 The KMF sends a response message to the UE, for example, an HTTP 200 response message, where the corresponding SEK: is carried.
  • the KMF sends the service response message to the UE and also carries the algorithm parameters.
  • the KMF may also carry the corresponding media protection type identification information in the response message, so that the UE can use the corresponding decryption according to the media protection type identifier. The way to handle encrypted media.
  • the UE uses the HTTP request SEK, and the KMF separately delivers the SEK. As shown in FIG. 7, the following steps are included:
  • Step 701 The UE sends a SEK key request message to the KMF, for example, a GET or POST request message in the HTTP, where one or more of the following information is carried: a service packet identifier, a channel (service) identifier, and a key ID of the SEK. Identifies, receives the IP address of the SEK, and receives the port number information of the SEK. If the KMF sends the SEK using the IP address of the request message sent by the UE, the message does not need to carry the information of the IP address. If the SEK is sent by using the port number agreed by the UE and the KMF, the message does not need to carry the port number information.
  • a SEK key request message for example, a GET or POST request message in the HTTP, where one or more of the following information is carried: a service packet identifier, a channel (service) identifier, and a key ID of the SEK. Identifies, receives the IP address of the SEK, and receives the port
  • Step 702 The KMF sends a service response message, such as an HTTP response message, to the UE.
  • a service response message such as an HTTP response message
  • Step 703 The KMF sends a SEK to the UE, where the SEK carries the SEK corresponding to the service identifier in the request and/or the key ID identifier of the SEK.
  • step 703 for the case that the EPG is not sent to the UE algorithm or there is no default algorithm, the KMF needs to send the algorithm parameters to the UE.
  • the UE if the identifier of the media protection type (SRTP or MPEG2TS-CA) is not obtained during the process of acquiring the EPG or the SIP session, the UE also carries the corresponding media protection type identification information, so that the UE can identify the identifier according to the media protection type. Use the appropriate decryption process.
  • step 202 the UE obtains other specific implementations of the SEK as follows:
  • the SEP is used to carry the SEK corresponding to the service package, including the following methods:
  • the SDP carries the address information (URI) of the SEK
  • the UE uses the "Get SEK Address Information (URI)" to continue to acquire the SEK corresponding to the service packet and/or channel identifier.
  • URI Get SEK Address Information
  • the SDP carries the key identifier (ID) of the SEK.
  • ID key identifier
  • An attribute of the SDP is added under the identifier of each Service Package to carry the ID of the SEK.
  • IPTV-SEK-ID service-package 1-SEKl
  • IPTV-SEK-ID service-package2-SEK2
  • the UE continues to use the key identifier (ID) of the SEK to obtain the key corresponding to the ID at the KMF.
  • ID key identifier
  • the third embodiment is specifically applied to the multicast service in the IPTV: the SCF uses the K2 interface in the architecture of FIG. 8 to acquire the SEK, or uses the SCF_ICC-Core IMS interface and the Core IMS-ISC-KMF interface in FIG.
  • the key the specific process shown in Figure 10, includes the following steps:
  • Steps 1001 to 1002 the UE sends an INVITE request message to the SCF via the Core IMS. It carries one or more service package identifiers and/or content identification information.
  • Step 1003 The SCF sends a request message to the KMF, where the service packet identification information and/or the content identification information in the INVITE message is carried.
  • Step 1004 The KMF sends a response message to the SCF, and carries the key SEK corresponding to the service package identifier and/or the content identifier.
  • Steps 1005 ⁇ 1006 the SCF sends a service response message (200 or 183 response message) to the UE via the Core IMS, and carries the SEK corresponding to one or more service package identifiers.
  • Step 1007 The UE continues the subsequent session flow.
  • the KMF needs to return the algorithm parameters in step 1004.
  • the SCF further sends the algorithm parameters to the UE.
  • the identifiers of the media protection type are also carried in the steps 1004, 1005, and 1006, and are used to indicate the specific protection mode of the UE.
  • SRTP protection type SRTP
  • MPEG2TS CA protection type MPEG2TS-CA
  • the carrying method of the service packet key may be carried by using the SDP method described above, or may be carried by using an XML method.
  • the method for delivering the SEK by using the SIP subscription uses the IMS Core-ISC-KMF interface in Figure 11.
  • the process shown in Figure 12 includes the following steps:
  • Step 1201 The UE sends a Subscribe message to the KMF through the IMS Core, where the service packet identifier and/or the channel identifier (or service identifier) is carried. Subscribe to the SEK corresponding to one or more service packages, or the SEK corresponding to each channel identifier (or service identifier) in a service package.
  • step 1202 the KMF returns a 200 OK message to the UE through the IMS Core.
  • Step 1203 The KMF sends a Notify message to the UE through the IMS Core, where the SEK corresponding to one or more service packets or the SEK corresponding to each channel identifier (or service identifier) in a service packet is carried.
  • step 1204 the UE returns a 200 OK message to the KMF through the IMS Core.
  • the KMF may also carry the algorithm parameters while transmitting the SEK.
  • the UE can also subscribe to the SCF.
  • the SCF obtains the key SEK from the KMF and sends it to the UE in the same way as Notify. The method and parameters are similar.
  • the architecture of one or more of the following information (SEK, TEK, SEK encrypted TEK) between KMF and MCF (or CEF, or media service functional entity, hereinafter collectively referred to as MCF) in step 201 includes two types: Architecture 1: Passing information through the direct interface, as shown in Figure 13, the direct interface N1 is used to transfer information between KMF and MCF (or CEF). One or more of the following information can be passed directly between KMF and MCF: SEK, TEK, SEK encrypted TEK; or one or more of the following information is first passed to CEF: SEK, TEK, SEK encrypted TEK, The CEF is then passed to the MCF/MDF.
  • Architecture 2 The information is passed through the KMF - ISC - Core IMS - Y2 - MCF interface, as shown in Figure 14. Implementation methods include the following:
  • the MCF/MDF (CEF) generates the TEK
  • the KMF generates the SEK encrypted TEK, as shown in FIG. 15, and applies to the interface for transmitting information of the first structure and the second structure: The following steps are included:
  • Step 1501 MCF/MDF (CEF) generates TEK
  • Step 1502 the MCF (CEF) sends a TEK encryption request to the KMF, which carries the content identifier and/or channel (service) identification information and the key TEK.
  • Step 1503 After receiving the request message, the KMF encrypts the TEK by using the corresponding SEK.
  • an indication of the media protection mode may be carried (instructing to use the SRTP to perform media encryption SRTP, or to indicate that the MPEG2TS is used to access the CA as the media protection mode MPEG2TS-CA).
  • the KMF may be different according to the The media protection mode is handled differently. For example, if the media protection mode indication is SRTP media protection mode, KMF can use the MIKEY to encapsulate the TEK carrying the SEK encryption; if the media protection mode indicates the MPEG2 TS-CA protection mode, KMF uses The ECM format in the existing CA system carries the SEK encrypted TEK. The TEK corresponding to the processed SEK encryption is sent to the MCF/MDF in step 1504. In the second embodiment, the MCF/MDF (CEF) generates the TEK, and uses the SEK sent by the KMF to encrypt the TEK. As shown in FIG. 16, the following steps are included:
  • Step 1601 the MCF (CEF) sends a message requesting the SEK key to the KMF, where the content identifier and/or channel (service) identification information is carried;
  • Step 1602 after receiving the request message, the KMF sends the corresponding SEK to the MCF (CEF);
  • the MCF/MDF (CEF) encrypts the TEK using the returned SEK.
  • the MCF/MDF (CEF) can also use the SEK to encrypt the TEK according to the media protection mode. If the media protection mode is SRTP, the MCF/MDF (CEF) can use the MIKEY to encapsulate the SEK encrypted TEK; For MPEG2 TS-CA, MCF/MDF (CEF) carries the SEK encrypted TEK using the ECM format in the existing CA system.
  • the KMF generates TEK and SEK encrypted TEK, as shown in FIG. 17, and includes the following steps:
  • Step 1701 The MCF (CEF) sends a request message to the KMF, where the content identifier and/or channel (service) identification information is carried.
  • Step 1702 After receiving the request message, the KMF encrypts the corresponding TEK by using the SEK corresponding to the content identifier and/or the channel (service) identification information.
  • Step 1703 KMF sends the SEK encrypted TEK, the unencrypted TEK to the MCF/MDF (CEF).
  • an indication of the media protection mode may be carried (instructing to use the SRTP to perform media encryption SRTP, or to indicate that the MPEG2TS is used to access the CA as the media protection mode MPEG2TS-CA).
  • the KMF may be different according to the The media protection mode is handled differently. For example, if the media protection mode indicates SRTP media protection mode, KMF can use the MIKEY package to carry SEK encryption. TEK; If the media protection mode indication is MPEG2 TS-CA protection mode, KMF carries the SEK encrypted TEK using the ECM format in the existing CA system. The corresponding SEK encrypted TEK is sent to the MCF/MDF in step 1703.
  • the MCF/MDF uses the SEK encryption TEK sent by the KMF, as shown in FIG. 18, and includes the following steps:
  • Step 1801 The MCF (CEF) sends a message requesting a key to the KMF, where the content identifier and/or channel (service) identification information is carried;
  • Step 1802 after receiving the request message, the KMF sends the corresponding SEK and TEK to the MCF (CEF);
  • step 1803 the MCF/MDF (CEF) encrypts the TEK using the returned SEK.
  • the MCF/MDF (CEF) may also use the SEK to encrypt the TEK according to the media protection mode. If the media protection mode is SRTP, the MCF/MDF (CEF) may use the MIKEY to encapsulate the SEK encrypted TEK; For MPEG2 TS-CA, MCF/MDF (CEF) carries the SEK encrypted TEK using the ECM format in the existing CA system.
  • the carrying manner of the specific message in the first embodiment, the second embodiment, the third embodiment, and the fourth embodiment may be:
  • TEK and media protection mode AVP can be expressed as follows.
  • ⁇ STKM-Info-Request>:: ⁇ Diameter Header: XXX, REQ, YYY, ⁇ >
  • Method 1 The MCF sends the TEK to the MDF. As shown in Figure 20, the following steps are included:
  • Step 2001 the MCF sends a request message to the MDF, where the service identifier and/or the content identifier, the key TEK, and the encryption algorithm are carried;
  • the MDF uses the TEK and the corresponding algorithm to encrypt the media content corresponding to the service identifier and/or the content identifier, and returns an acknowledgement message.
  • Method 2 The MCF sends the media protection mode to the MDF, as shown in Figure 21, including the following steps:
  • Step 2101 The MCF sends a request message to the MDF, where the service identifier and/or the content identifier, the media protection mode identifier, where the media protection mode identifier indicates that the SRTP is used as the media protection type (SRTP), or the conditional access using the MPEG2TS is performed.
  • CA as a media protection method (MPEG2TS-CA), TEK used by media protection.
  • Step 2102 The MDF uses the TEK and the corresponding algorithm to encrypt the media content corresponding to the service identifier and/or the content identifier according to the media protection manner indicated by the media protection mode, and returns an acknowledgement message.
  • a key-mgmt:mikey XXXXXX
  • the SDP and the key may be carried by using a request message and a Reply message corresponding to the H.248 protocol or the RTSP protocol.
  • the embodiment of the present invention further provides a structure diagram of KMF for implementing IPTV multicast service media security, as shown in FIG. 22, including:
  • the SEK sending module 2201 is configured to send the SEK to the user equipment
  • the TEK deployment module 2202 is used to deliver one of the following information to the MCF or CEF: SEK, TEK or SEK encrypted TEK.
  • the embodiment of the present invention further provides a schematic structural diagram of a user equipment for implementing IPTV multicast service media security. As shown in FIG. 23, the method includes:
  • the SEK obtaining module 2301 is configured to obtain the SEK from the key management function entity
  • the TEK obtaining module 2302 is configured to receive, by the media service function entity, a multicast sent TEK key stream protected by the SEK encryption;
  • the decryption module 2303 is configured to decrypt the TEK using the SEK, and decrypt the multicast media encrypted by the TEK using the TEK.
  • the LTV multicast media transmission security of the IMS-based IPTV architecture is implemented by distributing the keys SEK and TEK to the UE and the media service function entity.
  • the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. the way.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for making a A computer device (which may be a personal computer, server, or network device, etc.) performs the methods described in various embodiments of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

一种实现 IPTV组播业务媒体安全的方法、 ***及设备 本申请要求于 2008 年 2 月 27 日提交中国专利局， 申请号为 200810082852.4, 发明名称为 "一种实现 IPTV组播业务媒体安全的 方法、 ***及设备" 的中国专利申请的优先权， 其全部内容通过引用 结合在本申请中。 技术领域
本发明涉及通信技术领域， 尤其涉及一种实现 IPTV组播业务媒 体安全的方法、 ***及设备。 背景技术
3GPP ( The Third Generation Partnership Project, 第三代移动通信 ***）标准定义的 IMS ( IP Multimedia Core Network Subsystem, IP 多媒体业务子*** )采用 SIP ( Session Initial Protocol ,会话发起协议 ) 协议作为呼叫控制信令， 实现业务管理、会话控制以及承载接入的三 者分离。其中， IMS Core( IMS核心）包括以下逻辑功能实体： S-CSCF ( Service-Call Session Control Function , 服务 CSCF )、 P-CSCF ( Proxy-Call Session Control Function, 代理 CSCF )和 I-CSCF (查询 CSCF )。
基于 IMS网络的 IPTV ( IP Television， 因特网协议电视）业务是 在 IP ( Internet Protocol , 因特网协议 ) 网络上传输多媒体的***， 包 括视频、 音频等媒体内容。 该业务实质上是在 IMS 网络架构下提供 IPTV业务， 并充分利用 IMS网络中已有的会话控制、 计费等机制为 UE ( User Equipment, 用户设备）提供电视类的多媒体业务。 IPTV 典型业务实例是 LTV ( Linear Television, 线性电视） 业务， LTV业 务将媒体采用 IP组播方式发送给 UE,对于观看同一节目的全部用户， 在每一时刻所收到的节目内容都是完全相同的。 当然， 对于需要将同 一业务内容同时发送给多个用户的情况都可以采用组播方式来开展， 都可以看作是组播业务。
CA ( Conditional Access, 条件接入***）是传统广播电视中使 用的媒体安全的保护方法。 通过在内容源头对广播节目进行节目加 扰， 用户设备播放媒体内容时对加扰的节目内容进行解扰， 从而保证 内容的安全传送。用户设备解扰所需的安全信息通过独立于节目内容 的消息传送给用户设备。 节目内容、 安全信息以及***中的其他信息 复用成一个 TS ( Transport Stream, 传输流）发给用户设备。 IPTV系 统应用的 CA***中，密钥是分层保护的：节目内容经过 CW( Control Word, 控制字 )加扰， CW由 SK ( Service Key, 业务密钥 )加密处 理后在 ECM ( Entitlement Control Message, 授权控制消息 )消息中传 送， SK在 EMM ( Entitlement Management Message, 授权管理消息） 中传送， 且 SK在传送前要经过 PDK ( Personal Distribution Key, 个 人分发密钥） 的加密处理， PDK存放在用户的 SC ( Smart Card, 智 能卡） 中。
在实现本发明的过程中，发明人发现现有技术中至少存在以下缺 点： 现有 CA***适合没有返回通道的数字电视广播网络， 发送给每 个用户的 EMM消息都是采用对应的用户密钥进行加密， 需要对用户 进行分组以及轮播下发 EMM, 而且只能应用于 TS的封装格式。 在 基于 IMS的 IPTV***中， 存在返回通道， 而且存在直接使用 RTP 封装的媒体格式， 所以， 现有技术不能直接应用于基于 IMS的 IPTV ***中。 发明内容
本发明实施例提供了一种实现 IPTV组播业务媒体安全的方法、 ***及设备， 以基于 IMS的 IPTV***中的组播媒体保护的 SEK和 TEK的下发。
本发明实施例提供了一种实现 IPTV组播业务媒体安全的方法， 包括： 用户设备 UE从密钥管理功能 KMF获得业务加密密钥 SEK; 所述 UE接收组播发送的被所述 SEK加密的媒体加密密钥 TEK 密钥流；
所述 UE使用所述 SEK解密出 TEK, 并使用所述 TEK解密所述 由 TEK加密的组播媒体。
本发明实施例提供了一种实现 IPTV组播业务媒体安全的***， 包括：
密钥管理功能实体， 用于向用户设备发送 SEK, 并将 SEK加密 的 TEK部署到媒体服务功能实体；
媒体服务功能实体， 用于向用户设备发送加密的组播媒体， 及加 密组播媒体对应的被 SEK加密的 TEK;
用户设备，用于从所述密钥管理功能实体获得 SEK,从所述媒体 服务功能实体接收组播发送的被所述 SEK加密保护的 TEK密钥流， 并使用所述 SEK解密出 TEK, 使用所述 TEK解密所述由 TEK加密 的组播媒体。
本发明实施例提供了一种实现 IPTV组播业务媒体安全的密钥管 理功能实体， 包括：
SEK发送模块， 用于向用户设备发送 SEK;
TEK部署模块， 用于向 MCF或者 CEF传递以下信息的一种： SEK、 TEK或者 SEK加密的 TEK。
本发明实施例提供了一种实现 IPTV组播业务媒体安全的用户设 备， 包括：
SEK获取模块， 用于从密钥管理功能实体获得 SEK;
TEK获取模块， 用于从所述媒体服务功能实体接收组播发送的 被所述 SEK加密保护的 TEK密钥流；
解密模块， 用于使用所述 SEK解密出 TEK, 并使用所述 TEK解 密所述由 TEK加密的组播媒体。
本发明实施例中， 通过分发密钥 SEK和 TEK给 UE和媒体服务 功能实体， 实现基于 IMS的 IPTV架构的 LTV组播媒体传输安全。 附图说明
图 la是本发明实施例中应用场景中 IMS based IPTV的业务功能 架构图；
图 lb是本发明实施例中密钥体系示意图；
图 2是本发明实施例中功能实体结构图；
图 3是本发明实施例中通过 SSF的 EPG下发各个频道的媒体保 护类型信息和 /或 SEK密钥标识信息流程图； 型信息和 /或 SEK密钥标识信息流程图；
图 5是本发明实施例中基于 K1接口从 KMF获取 SEK架构图； 图 6是本发明实施例中基于 K1接口从 KMF获取 SEK流程图； 图 7是本发明实施例中基于 K1接口 KMF单独下发 SEK流程图； 图 8是本发明实施例中基于 K2接口从 KMF获取 SEK架构图； 图 9是本发明实施例中基于 K2接口从 KMF获取 SEK另一架构 图；
图 10是本发明实施例中基于 K2接口从 KMF获取 SEK流程图； 图 11是本发明实施例中基于 K2接口从 KMF获取 SEK又一架 构图；
图 12是本发明实施例中基于 K2接口从 KMF获取 SEK流程； 图 13是本发明实施例中 KMF和 MCF/MDF间通过直接接口传 递信息结构图；
图 14是本发明实施例中 KMF和 MCF/MDF间通过 Y2接口和 ISC 接口传递信息结构图；
图 15是本发明实施例中 MCF/MDF ( CEF )产生 TEK, KMF产 生 SEK加密的 TEK流程图；
图 16是本发明实施例中 MCF/MDF ( CEF )产生 TEK和 SEK加 密的 TEK流程图；
图 17是本发明实施例中 KMF产生 TEK和 SEK加密的 TEK流 程图；
图 18是本发明实施例中 MCF/MDF使用 KMF发送的 SEK加密 TEK流程图；
图 19是本发明实施例中 MCF和 MDF间传递密钥 TEK接口结 构图；
图 20是本发明实施例中 MCF将 TEK发送给 MDF流程图； 图 21是本发明实施例中 MCF发送媒体保护方式给 MDF流程图； 图 22是本发明实施例中实现 IPTV组播业务媒体安全的 KMF结 构图；
图 23是本发明实施例中实现 IPTV组播业务媒体安全的用户设 备结构图。 具体实施方式
本发明实施例的应用场景中 IMS based IPTV的业务功能架构， 如图 la所示， 主要包括： UE ( User Equipment, 用户设备）， 如手机， 机顶盒等； SDF ( Service Discovery Function, 业务发现功能实体；)， 用于给 UE提供业务附着信息， 如 EPG ( Electronic Program Guide, 电子节目指南）服务器地址信息等； SSF ( Service Selection Function, 业务选择功能实体）， 用于给 UE提供业务菜单信息； SCF ( Service Control Function,业务控制功能实体；)，用于处理用户业务请求； UPSF ( User Profile Server Function, 用户签约服务功能）， 用于存储用户签 约信息； Core IMS (核心 IMS ) , 为 IMS子***中的 P-CSCF、 I-CSCF 和 S-CSCF的总称； MF ( Media Functions, 媒体功能实体），负责到 UE媒体流的控制与交付媒体，从功能角度分解为 MCF( Media Control Function, 媒体控制功能实体 )和 MDF ( Media Delivery Function, 媒 体交付功能实体）， MCF 用于， 控制 MDF发送媒体流， MDF, 在 MCF的控制下分发媒体给 UE。
本发明实施例中使用的密钥体系如图 lb所示，包括： TEK( Traffic Encryption Key,媒体加密密钥）， 为媒体流提供机密性和 /或完整性保 护，对于使用传统 CA保护的 MPEG2TS( Moving Picture Expert Group 2 Transport Stream - Conditional Access , MPEG2 TS模式下的条件接入 保护方式）对应的密钥是 CW。 SEK ( Service Encryption Key, 业务 加密密钥）， 保护 TEK 下发信息的机密性和 /或完整性， 对于使用传 统 CA保护的 MPEG2TS传输方式对应的密钥是 SK, SK保护 CW下 发的机密性和 /或完整性。 URK ( User Root Key, 用户根密钥）， 用于 保护 SEK下发信息的机密性和 /或完整性，用户根密钥可以使用 GBA 的方式建立， 或者预先配置。 对于使用传统 CA保护的 MPEG2TS传 输方式对应的密钥可以是现有的 PDK, 也可以是使用 GBA的方式来 建立， 或者是预先配置好的 URK。 实施例中的密钥统一使用 URK、 SEK、 TEK进行描述， 对于 CA***的 PDK、 SK、 CW的实施例也 适用。
本发明实施例中功能实体如图 2 所示， 包括： KMF ( Key Management Function, 密钥管理功能实体）， 用于向 UE或其它功能 实体提供媒体保护所需的密钥， KMF可以作为一个独立的功能实体， 或者作为一个功能模块集成到 SCF 或者其它功能实体之中。 CEF ( Content Encryption Function,媒体加密功能实体），用于对媒体进行 加密、完整性保护等操作，对于 MCF/MDF完成媒体加密功能的情况， MCF/MDF完成 CEF的功能。 结合图 2实现 IPTV组播业务媒体安全 的方法包括以下步骤：
步骤 201 , 业务部署过程： KMF与 MCF/MDF (完成 CEF功能） 传递以下的一种或者几种信息 SEK、 TEK、 SEK加密的 TEK,将 SEK 加密的 TEK部署到 MDF上。
另外一种使用 CEF进行加密的方法包括：
步骤 201a, KMF与 CEF将以下信息的一种或几种传递给 CEF: SEK、 TEK、 SEK力口密的 TEK;
步骤 201b, CEF再将 SEK加密的 TEK发送给 MCF/MDF (不具 有 CEF功能）。 对于 MCF/MDF上已经拥有 SEK加密的 TEK的条件下， 则步骤 201 (步骤 201a和步骤 201b ) 不需要。
步骤 202, UE从 KMF获得 SEK。
具体实施中， 该 SEK还可以被 URK加密保护， URK通过加密 SEK或者 URK加密整个携带 SEK的消息来完成对 SEK的加密保护。 UE接收到加密的 SEK后， 使用 URK解密出 SEK。
在 UE获取 SEK前， 如果 UE没有 TEK密钥流的会话描述协议 SDP描述信息和 /或媒体安全描述信息，还需要 UE通过 SSF或者 SCF 从媒体服务功能实体获取媒体安全描述信息。
步骤 203, MDF在发送加密组播媒体时，将加密组播媒体对应的 被 SEK加密的 TEK通过 IP组播发送给 UE。
步骤 204 , UE接收加密的组播媒体和组播发送的 TEK密钥流， 使用 SEK解密出 TEK, 并使用 TEK解密组播媒体。
实施例步骤 202 中提到的媒体安全描述信息包括以下信息的一 种或几种： 媒体保护类型标识、 SEK密钥标识、 获取 SEK的地址信 息。 其中， 媒体保护类型标识用来指示发送给 UE的媒体流的保护类 型， 例如使用 SRTP ( Security Real-time Transport Protocol, 安全实时 传输协议）的类型保护， 或使用 MPEG2TS的 CA保护类型。 TEK密 钥流的会话描述协议 SDP描述信息和 /或媒体安全描述信息下发的方 式包括以下几种：
1、使用 SDP携带媒体保护类型信息，具体可以采用 SDP的一个 新 a属性携带：
例如， a=Media-Protection-Typt: MPEG-TS-CA;
或者使用 a=fmtp属性携带：
列^口, a=fmtp: media-protection- typt: SRTP
对于使用 SRTP 的保护类型可以使用 SRTP 作为标识； 对于 MPEG2TS的 CA保护类型可以使用 MPEG2TS-CA作为标识。
例如， 一个使用 SRTP保护的音频流的 SDP为：
m= Audio 49168 RTP/AVP 96 c=IN IP4 224.2.17.12/127
a=rtpmap:96 H264/90000
a=fmtp: Media-Protection-Typt: SRTP;
对于媒体的保护类型为 MPEG2TS-CA的情况， 还可以进一步携 带算法参数， 用来指示 UE该媒体保护使用的算法， 具体的可以使用 一个 SDP的 a属性来携带：
a= Media-Protection-Typt: MPEG2TS-CA; 安全算法标识； 或者 a=fmtp: Media-Protection-Typt: MPEG2TS-CA; 安全算法 标识；
例如， 一个使用 MPEG2TS-CA保护的视频媒体流对应的 128位 密钥的 AES-Counter Mode算法表示为：
m=video 53810 RTP/AVP nl
a=rtpmap: nl TS
a=fmtp: Media-Protection-Typt: MPEG2TS-CA; AES-CM- 128; 2、 SDP中携带 SEK的信息：
组播媒体的 SDP中携带 SEK的密钥标识（ID )和 /或获取 SEK 的地址信息 （URI )。
UE使用 SEK的密钥标识（ ID )到 KMF处获取该 ID对应的 SEK 密钥；
UE使用 "获取 SEK的地址信息 （URI )" 请求该业务包和 /或频 道标识对应的 SEK。 例如：
具体的实现中， 使用会话级的 SDP描述中携带， 或者在媒体级 的 SDP描述中或者密钥流的 SDP描述中携带， 例如， 使用 SDP中的 一个 a属性来携带密钥标识，或者使用 SDP的 k头域来携带获取 SEK 的地址信息。 例如， 下面使用密钥流的 SDP进行携带：
m= application 49230 udp IPTV.TISPAN.TEKM
c= IP4 224.2.17.12/127
k=URI; 或者 a=SEK-ID ；
此外， TEK密钥流的 SDP描述中还可以携带相邻 2个 TEK组播 密钥更新的间隔时间， 用来指示 UE多长时间获取一次更新的 TEK, 具体的实现中使用一个 a属性来携带， 例如：
m= application 49230 udp IPTV.TISPAN.TEKM
c= IP4 224.2.17.12/127
a=fmtp: traffic_key_Interim_Time
3、 使用 XML携带媒体保护类型信息： 使用 SDP携带的媒体保 护类型信息、 媒体的保护类型、 SEK的密钥标识（ID )、 获取 SEK的 地址信息 （ URI )、 相邻 2个 TEK组播密钥更新的间隔时间中的一种 或几种都可以使用 XML的一个元素发送给 UE:
例如媒体保护类型 （ protection-type )和 SEK标识（ SEK-ID )如 下：
<Media-Protection-Descryption>
<Service-IDl>
<protection-type>SRTP</ protection-type >
<SEK-ID>SEK-ID1</ SEK-ID >
</Service-IDl>
</ Media-Protection-Descryption >
步骤 202中 UE获取 TEK密钥流的 SDP描述信息和 /或媒体安全 描述信息的具体实施例包括以下几种：
实施例一， 通过 SSF的 EPG下发过程， 下发各个业务包标识和 / 或频道标识（或者业务标识）对应的 TEK密钥流的 SDP描述信息和 /或媒体安全描述信息， 如图 3所示， 包括以下步骤：
步骤 301 , UE向 SSF发送 EPG请求消息。 其中请求消息可以使 用 HTTP ( HyperText Transfer Protocol, 超文本传输协议） 中的 GET 或者 POST请求消息。 如果 EPG通过广播方式发给 UE, 例如使用 3GPP中定义的 FLUTE方式广播发送， 步骤 301的请求消息不需要。
步骤 302, SSF向 UE发送消息， 例如 HTTP的 200响应消息， 其中携带各个业务包标识和 /或频道（或者业务）对应的 SEK的密钥 标识和 /或获取 SEK的地址信息。 此外， 还可以携带对应的媒体保护类型信息和 /或 ΤΕΚ密钥流的
SDP描述信息，以上各个信息与上述的 SDP方式或者 XML表示方式 和携带的方法相同。
实施例二， 通过 SIP ( Session Initial Protocol, 会话发起协议）会 话下发初始频道（或者业务）对应的 TEK密钥流的 SDP描述信息和 /或媒体安全描述信息， 如图 4所示， 包括以下步骤：
步骤 401~402, UE经 Core IMS向 SCF发送 INVITE业务请求消 息， 其中携带初始频道（或者业务） 的标识信息。
步骤 403~404, SCF经 Core IMS向 UE发送业务响应（ 183或者 200 )消息， 其中携带初始频道（或者业务）标识对应 SEK的密钥标 识和 /或获取 SEK的地址信息。
步骤 405, UE继续执行后续的会话流程。
此外， 步骤 403和步骤 404中， 还可以携带对应的媒体保护类型 信息和 /或 TEK密钥流的 SDP描述信息，以上各个信息与上述的 SDP 方式或者 XML表示方式和携带的方法相同。
实施例一， UE直接到 KMF请求 SEK, 具体可以使用 HTTP请 求携带， 基于图 5中的 K1接口从 KMF获取 SEK, 具体流程如图 6 所示， 包括以下步骤：
步骤 601 , UE向 KMF发送请求消息， 例如， 使用 HTTP中的 GET或者 POST请求消息， 其中携带以下信息的一种或几种： 业务 包标识、 频道（业务 )标识、 SEK的密钥 ID标识； 钥 ID信息， 则此处携带 SEK的密钥 ID信息。
步骤 602, KMF向 UE发送响应消息， 例如， HTTP的 200响应 消息， 其中携带对应的 SEK：。
对于 EPG中没有发给 UE算法或者没有默认算法的情况下， KMF 向 UE发送业务响应消息中还携带算法参数。对于 UE在获取 EPG或 者 SIP 会话过程中没有获得媒体保护类型的标识 （SRTP 或者 MPEG2TS-CA )的情况， 则 KMF在响应消息中还可以携带对应的媒 体保护类型标识信息， 便于 UE根据媒体保护类型标识使用对应的解 密方式处理加密的媒体。
实施例二， UE使用 HTTP请求 SEK, KMF单独下发 SEK, 如 图 7所示， 包括以下步骤：
步骤 701 , UE向 KMF发起 SEK密钥请求消息， 例如， HTTP 中的 GET或者 POST请求消息， 其中携带以下信息的一种或几种： 业务包标识、 频道（业务 )标识、 SEK的密钥 ID标识， 接收 SEK的 IP地址，接收 SEK的端口号信息。 如果 KMF使用 UE发送请求消息 的 IP地址发送 SEK, 则消息中不必携带 IP地址的信息； 如果使用 UE与 KMF事先约定好的端口号发送 SEK, 则消息中不必携带端口 号信息。
步骤 702 , KMF向 UE发送业务响应消息， 例如 HTTP的 200响 应消息。
步骤 703、 KMF向 UE发送 SEK, 该 SEK与请求中携带请求中 的业务标识和 /或 SEK的密钥 ID标识对应的 SEK。
步骤 703中， 对于 EPG中没有下发给 UE算法或者没有默认算 法的情况， KMF向 UE还需要发送算法参数。 步骤 702中， 对于 UE 在获取 EPG或者 SIP会话过程中没有获得媒体保护类型的标识（ SRTP 或者 MPEG2TS-CA ) 的情况， 则还要携带对应的媒体保护类型标识 信息， 便于 UE根据媒体保护类型标识使用相应的解密处理。 步骤 202中 UE获取 SEK的其它具体实施例如下：
使用 SDP携带业务包对应的 SEK, 具体包括以下方式：
1、 SDP携带业务包对应的 SEK, 使用一个 a=key-mgmt头域携 带， 例如：
a= bc_service_package: service package 1
a=key-mgmt:mikey XXXX ( SEK1 ) 对于 SDP 中包含多个业务包的情况， 每个业务包下面可以对应 一个 a=key-mgmt头域来携带对应的 SEK , 例如：
a= bc_service_package: service package 1
a=key-mgmt:mikey XXXX ( SEK1 )
a= bc_service_package: service package 2
a=key-mgmt:mikey YYYY ( SEK2 )
2、 SDP中携带获取 SEK的地址信息 （URI ),
例如：在每个 Service Package标识的下面增加一个 k字段来携带 获取密钥 SEK的地址。
a= bc_service_package: service package 1
k=http ://ltv.example . com/ service-package 1 -SEK 1
a= bc_service_package: service package 2
k=http ://ltv.example . com/ service-package2- SEK2
UE使用该 "获取 SEK的地址信息 （URI )" 来继续获取该业务 包和 /或频道标识对应的 SEK。
3、 SDP中携带 SEK的密钥标识（ID ), 在每个 Service Package 标识的下面增加一个 SDP的 a属性来携带获取密钥 SEK的 ID。
a= bc_service_package: service package 1
a=IPTV-SEK-ID： service-package 1-SEKl
a= bc_service_package: service package 2
a= IPTV-SEK-ID: service-package2-SEK2
UE使用 SEK的密钥标识（ ID )继续到 KMF处获取该 ID对应 的密钥。 实施例三， 具体的应用于 IPTV中的组播业务： SCF使用如图 8 架构中的 K2接口获取 SEK,或者使用图 9中的 SCF _ ISC - Core IMS 接口和 Core IMS - ISC - KMF接口获取密钥，具体过程如图 10所示， 包括以下步骤：
步骤 1001 ~ 1002, UE经 Core IMS向 SCF发送 INVITE请求消息， 其中携带一个或者多个业务包标识和 /或内容标识信息。
步骤 1003, SCF向 KMF发起请求消息， 其中携带 INVITE消息 中的业务包标识信息和 /或内容标识信息。
步骤 1004, KMF向 SCF发送响应消息， 携带该业务包标识和 / 或内容标识对应的密钥 SEK。
步骤 1005~1006, SCF经 Core IMS向 UE发送业务响应消息（ 200 或者 183响应消息 ) , 携带一个或者多个业务包标识对应的 SEK。
步骤 1007, UE继续后续的会话流程。
步骤 1004、 1005和 1006中， 对于 EPG中没有下发给 UE算法 或者没有默认算法的情况下，步骤 1004中 KMF还需要返回算法参数， 步骤 1005~1006中， SCF向 UE还发送算法参数。对于 UE在 EPG中 没有获得媒体保护类型的标识的情况， 步骤 1004、 1005和 1006中还 携带媒体保护类型的标识，用来指示 UE具体的保护方式。例如： SRTP 的保护类型： SRTP;或者 MPEG2TS的 CA保护类型： MPEG2TS-CA )。 具体的可以采用 SDP 中的 a 属性来携带， 例如： a=fmtp: media-protection-type= SRTP或者 MPEG-TS-CA。
业务包密钥的携带方法可以使用上述的 SDP方法携带， 也可以 使用 XML的方式来携带。
实施例四， SIP订阅下发 SEK的方式，使用图 11中的 IMS Core- ISC-KMF接口， 过程如图 12所示， 包括以下步骤：
步骤 1201 , UE通过 IMS Core向 KMF发送 Subscribe消息， 其 中携带业务包标识和 /或频道标识（或者业务标识）。 订阅一个或多个 业务包对应的 SEK,或者一个业务包中各个频道标识（或者业务标识 ) 对应的 SEK。
步骤 1202, KMF通过 IMS Core向 UE返回 200 OK消息。
步骤 1203 , KMF通过 IMS Core向 UE发送 Notify消息，其中携 带一个或多个业务包对应的 SEK, 或者一个业务包中各个频道标识 (或者业务标识 )对应的 SEK。
步骤 1204, UE通过 IMS Core向 KMF返回 200 OK消息。 对于 EPG中没有下发给 UE算法或者没有默认算法的情况下， 步骤 1203 中， KMF发送 SEK的同时，还可以携带算法参数。 UE还可以向 SCF 订阅， SCF向 KMF获取密钥 SEK后以 Notify同样的方法发送给 UE, 方法和参数类似。 步骤 201中 KMF和 MCF (或者 CEF,或者称为媒体服务功能实 体， 以下统一称为 MCF )间传递以下信息的一种或几种（SEK、 TEK、 SEK加密的 TEK ) 的架构包括两种： 架构一： 通过直接接口传递信 息， 如图 13所示， KMF和 MCF (或者 CEF )之间使用直接的接口 N1传递信息。 以下信息的一种或几种可以直接在 KMF和 MCF之间 传递： SEK、 TEK、 SEK加密的 TEK; 或者以下信息的一种或几种先 传递给 CEF: SEK、 TEK、 SEK加密的 TEK, CEF再传递给 MCF/MDF。 架构二： 通过 KMF - ISC - Core IMS - Y2 - MCF接口传递信息， 如 图 14所示。 实施方法包括以下几种：
实施例一， MCF/MDF ( CEF )产生 TEK, KMF产生 SEK加密 的 TEK,如图 15所示，对架构一和架构二的传递信息的接口都适用： 包括以下步骤：
步骤 1501 , MCF/MDF ( CEF )产生 TEK;
步骤 1502, MCF ( CEF ) 向 KMF发送 TEK加密请求， 其中携 带内容标识和 /或频道（业务）标识信息和密钥 TEK。
步骤 1503 , KMF收到请求消息后， 使用对应的 SEK加密 TEK。 步骤 1504 , KMF向 MCF发送响应消息， 其中携带 SEK加密的 TEK。
步骤 1502中，还可以携带媒体保护方式的指示（指示使用 SRTP 进行媒体加密 SRTP, 或者是指示使用 MPEG2TS的条件接入 CA作 为媒体保护方式 MPEG2TS-CA ), KMF收到指示后， 可以根据不同 的媒体保护方式进行不同的处理， 例如， 如果媒体保护方式指示为 SRTP媒体保护方式， KMF可以使用 MIKEY封装携带 SEK加密的 TEK; 如果媒体保护方式指示为 MPEG2TS-CA保护方式， KMF使用 现有 CA***中的 ECM格式携带 SEK加密的 TEK。 对应处理后的 SEK加密的 TEK在步骤 1504中发送给 MCF/MDF。 实施例二， MCF/MDF ( CEF )产生 TEK, 并使用 KMF发送的 SEK加密 TEK, 如图 16所示， 包括以下步骤：
步骤 1601 , MCF ( CEF ) 向 KMF发送请求 SEK密钥的消息， 其中携带内容标识和 /或频道（业务）标识信息；
步骤 1602, KMF收到请求消息后， 将对应的 SEK发送给 MCF ( CEF );
步骤 1603, MCF/MDF ( CEF )使用返回的 SEK加密 TEK。 此外， 步骤 1603中， MCF/MDF ( CEF )还可以根据媒体保护方 式来使用 SEK加密 TEK, 如果媒体保护方式为 SRTP, MCF/MDF ( CEF )可以使用 MIKEY封装 SEK加密的 TEK; 如果媒体保护方 式为 MPEG2TS-CA, MCF/MDF ( CEF )使用现有 CA***中的 ECM 格式携带 SEK加密的 TEK。 实施例三， KMF产生 TEK和 SEK加密的 TEK, 如图 17所示， 包括以下步骤：
步骤 1701 , MCF ( CEF )向 KMF发送请求消息， 其中携带内容 标识和 /或频道（业务）标识信息。
步骤 1702, KMF收到请求消息后， 使用内容标识和 /或频道（业 务）标识信息对应的 SEK加密对应的 TEK。
步骤 1703 , KMF将 SEK加密 TEK, 未加密的 TEK发送给 MCF/MDF ( CEF )。
步骤 1701中，还可以携带媒体保护方式的指示（指示使用 SRTP 进行媒体加密 SRTP, 或者是指示使用 MPEG2TS的条件接入 CA作 为媒体保护方式 MPEG2TS-CA ), KMF收到指示后， 可以根据不同 的媒体保护方式进行不同的处理， 例如， 如果媒体保护方式指示为 SRTP媒体保护方式， KMF可以使用 MIKEY封装携带 SEK加密的 TEK; 如果媒体保护方式指示为 MPEG2TS-CA保护方式， KMF使用 现有 CA***中的 ECM格式携带 SEK加密的 TEK。 对应的 SEK加 密的 TEK在步骤 1703中发送给 MCF/MDF。
实施例四， MCF/MDF ( CEF )使用 KMF发送的 SEK加密 TEK, 如图 18所示， 包括以下步骤：
步骤 1801 , MCF ( CEF )向 KMF发送请求密钥的消息， 其中携 带内容标识和 /或频道（业务）标识信息；
步骤 1802, KMF收到请求消息后， 将对应的 SEK和 TEK发送 给 MCF ( CEF );
步骤 1803, MCF/MDF ( CEF )使用返回的 SEK加密 TEK。
此外， 步骤 1803中， MCF/MDF ( CEF )还可以根据媒体保护方 式来使用 SEK加密 TEK, 如果媒体保护方式为 SRTP, MCF/MDF ( CEF )可以使用 MIKEY封装 SEK加密的 TEK; 如果媒体保护方 式为 MPEG2TS-CA, MCF/MDF ( CEF )使用现有 CA***中的 ECM 格式携带 SEK加密的 TEK。
实施例一、 实施例二、 实施例三、 实施例四中的具体消息的携带 方式可以采用：
方式 1、 HTTP+XML的方式， 各个参数都作为 XML的一个元素 来携带；
方式 2、 Diameter扩展新的 AVP
例如， TEK和媒体保护方式的 AVP可以按照如下的方法表示。 < STKM-Info-Request>：: =<Diameter Header: XXX, REQ, YYY, ζζζ >
{ STKM-Service-Identifier }； Service identifiers
{ TEK } ； TEK AVP
{ Media protection method };媒体保护方式 AVP
{ Algorithem } ； 力口密算法 AVP 实施例五， 对于加密操作由 MCF/MDF来执行的情况， MCF和 MDF间需要传递密钥 TEK, 使用接口 Xp如图 19所示，
方法 1、 MCF将 TEK发送给 MDF, 如图 20所示， 包括以下步 骤：
步骤 2001 , MCF向 MDF发送请求消息， 其中携带业务标识和 / 或内容标识， 密钥 TEK, 加密算法；
步骤 2002, MDF使用 TEK和对应的算法加密业务标识和 /或内 容标识对应的媒体内容， 并返回确认消息。 方法 2、 MCF发送媒体保护方式给 MDF, 如图 21所示， 包括以 下步骤：
步骤 2101 , MCF向 MDF发送请求消息， 其中携带业务标识和 / 或内容标识， 媒体保护方式标识， 其中媒体保护方式标识指示使用 SRTP作为媒体保护的类型 （SRTP ), 或者是使用 MPEG2TS的条件 接入 CA作为媒体保护方式（ MPEG2TS-CA ),媒体保护使用的 TEK。
步骤 2102, MDF使用 TEK和对应的算法，按照媒体保护方式指 示的媒体保护方式对业务标识和 /或内容标识对应的媒体内容加密处 理， 并返回确认消息。 方式 1和方式 2中的参数的具体携带方式：
1 ) MCF和 MDF之间采用 RTSP协议：
TEK使用 Keymgmt头域携带，其中的 data字段携带 TEK,例如： Keymgmt: prot=mikey; uri="rtsp://movie.example. com/action"; data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..." RTSP消息可以使用 DESCRIBE请求消息和对应的响应消息。
2 ) MCF和 MDF之间采用 SDP携带密钥：
TEK可以使用 SDP中的 a=key-mgmt属性头域携带， TEK携带 在 MIKEY消息中的密钥字段， 例如：
a=key-mgmt:mikey XXXXXX 可以使用 H.248协议或者 RTSP协议对应的请求消息和 Reply消 息携带 SDP和密钥。
本发明实施例还提供一种实现 IPTV组播业务媒体安全的 KMF 的结构示意图， 如图 22所示， 包括：
SEK发送模块 2201 , 用于向用户设备发送 SEK;
TEK部署模块 2202, 用于向 MCF或者 CEF传递以下信息的一 种： SEK、 TEK或者 SEK加密的 TEK。
本发明实施例还提供一种实现 IPTV组播业务媒体安全的用户设 备的结构示意图， 如图 23所示， 包括：
SEK获取模块 2301 , 用于从密钥管理功能实体获得 SEK;
TEK获取模块 2302, 用于从所述媒体服务功能实体接收组播发 送的被所述 SEK加密保护的 TEK密钥流；
解密模块 2303, 用于使用所述 SEK解密出 TEK, 并使用所述 TEK解密所述由 TEK加密的组播媒体。
本发明的实施例中， 通过分发密钥 SEK和 TEK给 UE和媒体服 务功能实体， 实现基于 IMS的 IPTV架构的 LTV组播媒体传输安全。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解 到本发明可借助软件加必需的通用硬件平台的方式来实现， 当然也可 以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解， 本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以 软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质 中， 包括若干指令用以使得一台计算机设备（可以是个人计算机， 服 务器， 或者网络设备等）执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例， 但是， 本发明并非局 限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护 范围。

Claims

权利要求
1、 一种实现因特网协议电视 IPTV组播业务媒体安全的方法， 其特征在于， 包括：
用户设备 UE从密钥管理功能 KMF获得业务加密密钥 SEK; 所述 UE接收组播发送的被所述 SEK加密的媒体加密密钥 TEK 密钥流；
所述 UE使用所述 SEK解密出 TEK, 并使用所述 TEK解密所述 由 TEK加密的组播媒体。
2、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述用户设备 UE从密钥管理功能 KMF获得业务加密密 钥 SEK具体包括：
所述 UE从所述 KMF接收被用户根密钥 URK加密保护的 SEK; 所述 UE使用所述 URK解密出所述 SEK。
3、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE从 KMF获得 SEK具体包括：
UE向 KMF发送请求消息，其中携带业务标识和 /或 SEK的密钥 ID标识；
KMF向 UE发送响应消息， 其中携带对应的 SEK。
4、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE从 KMF获得 SEK具体包括：
UE向 KMF发起 SEK密钥请求消息， 其中携带业务标识和 /或 SEK的密钥 ID标识；
KMF向 UE发送响应消息；
KMF向 UE发送对应的 SEK。
5、 如权利要求 3或 4所述实现 IPTV组播业务媒体安全的方法， 其特征在于， 所述 KMF还向 UE发送媒体保护方式和 /或加密算法。
6、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE从 KMF获得 SEK具体包括： UE通过 Core IMS向 SCF发送业务请求消息， 其中携带业务包 标识和 /或内容标识；
所述 SCF通过 Core IMS向 UE发送业务响应消息， 携带业务包 标识和 /或内容标识对应的 SEK。
7、 如权利要求 6所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， SCF获取对应的 SEK的过程包括：
所述 SCF向 KMF发起请求消息，其中携带请求消息中的业务包 标识和 /或内容标识；
所述 KMF向所述 SCF发送响应消息， 携带所述业务包标识和 / 或内容标识对应的 SEK。
8、 如权利要求 6所述实现 IPTV组播业务媒体安全的方法， 其 特征在于，
所述 UE通过 Core IMS向 SCF发送业务请求消息中携带多个业 务包标识和 /或内容标识；
所述 SCF通过 Core IMS向 UE发送业务响应消息中携带每个业 务包标识和 /或内容标识对应的 SEK。
9、 如权利要求 6至 8中任一项所述实现 IPTV组播业务媒体安 全的方法， 其特征在于，
使用 SDP中的 a属性行来携带 SEK。
10、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE从 KMF获得 SEK具体包括：
UE通过 IMS Core向 KMF发送订阅消息， 其中携带一个或多个 业务包标识， 或者一个业务包中的各个频道标识或者业务标识；
KMF通过 IMS Core向 UE返回响应消息；
KMF通过 IMS Core向 UE发送通知消息， 其中携带一个或多个 业务包对应的 SEK, 或者一个业务包中各个业务标识对应的 SEK。
11、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE从 KMF获得 SEK之前还包括：
所述 UE获取 TEK密钥流的会话描述协议 SDP描述信息和 /或媒 体的安全描述信息。
12、如权利要求 11所述实现 IPTV组播业务媒体安全的方法，其 特征在于， 所述媒体的安全描述信息具体包括：
SEK的密钥标识或获取 SEK的地址信息。
13、 如权利要求 12所述实现 IPTV组播业务媒体安全的方法， 其特征在于，
使用 SDP的一个 a属性行或者 k头域携带所述 SEK的密钥标识 或者获取 SEK的地址信息。
14、如权利要求 11所述实现 IPTV组播业务媒体安全的方法，其 特征在于， 所述媒体的安全描述信息中包括：
媒体流保护类型信息， 用于指示媒体使用的保护方式。
15、 如权利要求 14所述实现 IPTV组播业务媒体安全的方法， 其特征在于， 使用 a属性行或者 a=fmtp携带所述媒体流保护类型信 息。
16、 如权利要求 14所述实现 IPTV组播业务媒体安全的方法， 其特征在于， 所述保护方式包括指示使用 SRTP作为保护类型， 或者 指示使用 CA作为保护类型。
17、如权利要求 11所述实现 IPTV组播业务媒体安全的方法，其 特征在于， 所述 UE获取媒体的安全描述信息具体包括：
UE经 Core IMS向 SCF发送 INVITE业务请求消息，其中携带初 始频道的标识信息；
SCF经 Core IMS向 UE发送业务响应消息， 其中携带 SEK的密 钥标识和 /或获取 SEK的地址信息。
18、如权利要求 11所述实现 IPTV组播业务媒体安全的方法，其 特征在于， 所述 UE获取媒体的安全描述信息具体包括：
UE向 SSF发送 EPG请求消息；
所述 UE接收所述 SSF返回的消息，其中携带各个业务包标识和 /或业务标识对应的 SEK的密钥标识和 /或获取 SEK的地址信息。
19、 如权利要求 1所述实现 IPTV组播业务媒体安全的方法， 其 特征在于， 所述 UE获取 SEK之前还包括：
KMF与媒体功能实体进行交互， 将 SEK加密的 TEK部署到所 述媒体功能实体； 或
KMF与 CEF进行交互， 由所述 CEF将 SEK加密的 TEK部署到 所述媒体服务功能实体。
20、 如权利要求 19所述实现 IPTV组播业务媒体安全的方法， 其特征在于， 所述 TEK部署过程具体包括：
媒体服务实体产生 TEK;
媒体服务功能实体向 KMF发送请求，其中携带内容标识和 /或业 务标识信息和密钥 TEK;
KMF收到请求消息后， 使用对应的 SEK加密 TEK;
KMF向 MCF返回应答消息， 其中携带 SEK加密的 TEK;
或
媒体服务功能实体向 KMF发送请求，其中携带内容标识和 /或业 务标识信息；
KMF收到请求消息后，将对应的 SEK发送给媒体服务功能实体； 媒体服务功能实体使用返回的 SEK加密 TEK;
或
媒体服务功能实体向 KMF发送请求消息，其中携带内容标识和 / 或业务标识信息；
KMF使用 SEK加密 TEK,将加密的 TEK和未加密的 TEK发送 给媒体服务功能实体；
或
媒体服务功能实体向 KMF发送请求消息，其中携带内容标识和 / 或业务标识信息；
KMF将 SEK和 TEK发送给媒体服务功能实体。
21、 一种实现 IPTV组播业务媒体安全的***， 其特征在于， 包 括： 密钥管理功能实体， 用于向用户设备发送 SEK, 并将 SEK加密 的 TEK部署到媒体服务功能实体；
媒体服务功能实体， 用于向用户设备发送加密的组播媒体， 及加 密组播媒体对应的被 SEK加密的 TEK;
用户设备，用于从所述密钥管理功能实体获得 SEK,从所述媒体 服务功能实体接收组播发送的被所述 SEK加密保护的 TEK密钥流， 并使用所述 SEK解密出 TEK, 使用所述 TEK解密所述由 TEK加密 的组播媒体。
22、 如权利要求 21所述实现 IPTV组播业务媒体安全的***， 其特征在于， 所述用户设备通过 K1接口从 KMF获取 SEK; 或通过 K2接口从 KMF获取 SEK; 或通过 SCF ISC - Core IMS接口和 Core IMS ISC KMF接口获取 SEK。
23、 如权利要求 22所述实现 IPTV组播业务媒体安全的***， 其特征在于， 所述用户设备通过 K1接口从 KMF获取 SEK, 具体包 括： UE向 KMF发送请求消息， 其中携带以下信息的一种或几种： 业务包标识、 业务标识、 SEK的密钥 ID标识； UE通过 K1接口从 KMF接收响应消息， 其中携带对应的 SEK。
24、 如权利要求 22所述实现 IPTV组播业务媒体安全的***， 其特征在于，
所述用户设备通过 K2接口从 KMF获取 SEK,具体包括： UE经 Core IMS向 SCF发送 INVITE请求消息， 其中携带业务包标识和 /或 内容标识信息； SCF通过 K2接口向 KMF发起请求消息， 其中携带 INVITE消息中的业务包标识信息和 /或内容标识信息； KMF通过 K2 接口向 SCF发送响应消息， 携带该业务包标识和 /或内容标识对应的 密钥 SEK; SCF经 Core IMS向 UE发送响应消息， 携带该业务包标 识和 /或内容标识对应的密钥 SEK。
25、 如权利要求 21所述实现 IPTV组播业务媒体安全的***， 其特征在于， 还包括：
KMF与媒体功能实体进行交互， 将 SEK加密的 TEK部署到所 述媒体功能实体； 或
KMF与 CEF进行交互， 由所述 CEF将 SEK加密的 TEK部署到 所述媒体服务功能实体。
26、 如权利要求 25所述实现 IPTV组播业务媒体安全的***， 其特征在于，
KMF和 MCF,或者 CEF通过直接接口 N1传递以下信息的一种： SEK、 TEK或者 SEK加密的 TEK; 或者
通过 KMF ISC Core IMS - Y2 MCF接口传递以下信 息的一种： SEK、 TEK或者 SEK加密的 TEK。
27、 一种实现 IPTV组播业务媒体安全的密钥管理功能实体， 其 特征在于， 包括：
SEK发送模块， 用于向用户设备发送 SEK;
TEK部署模块， 用于向 MCF或者 CEF传递以下信息的一种： SEK、 TEK或者 SEK加密的 TEK。
28、一种实现 IPTV组播业务媒体安全的用户设备，其特征在于， 包括：
SEK获取模块， 用于从密钥管理功能实体获得 SEK;
TEK获取模块， 用于从所述媒体服务功能实体接收组播发送的 被所述 SEK加密保护的 TEK密钥流；
解密模块， 用于使用所述 SEK解密出 TEK, 并使用所述 TEK解 密所述由 TEK加密的组播媒体。
PCT/CN2009/070557 2008-02-27 2009-02-26 一种实现iptv组播业务媒体安全的方法、***及设备 WO2009106007A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810082852A CN101521570B (zh) 2008-02-27 2008-02-27 一种实现iptv组播业务媒体安全的方法、***及设备
CN200810082852.4 2008-02-27

Publications (1)

Publication Number Publication Date
WO2009106007A1 true WO2009106007A1 (zh) 2009-09-03

Family

ID=41015543

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/070557 WO2009106007A1 (zh) 2008-02-27 2009-02-26 一种实现iptv组播业务媒体安全的方法、***及设备

Country Status (2)

Country Link
CN (1) CN101521570B (zh)
WO (1) WO2009106007A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102143129B (zh) * 2010-05-26 2015-03-18 华为软件技术有限公司 超文本传输协议流媒体传输中实现业务保护的方法和***
CN102694769B (zh) * 2011-03-22 2015-09-30 华为技术有限公司 媒体数据处理方法及其装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1848944A (zh) * 2005-04-05 2006-10-18 华为技术有限公司 一种iptv***、加密数字节目的发布、收看方法
CN101009553A (zh) * 2006-12-30 2007-08-01 中兴通讯股份有限公司 实现多网融合移动多媒体广播***密钥安全的方法和***
CN101009551A (zh) * 2006-01-24 2007-08-01 华为技术有限公司 基于ip多媒体子***的媒体流的密钥管理***和方法
CN101047829A (zh) * 2006-03-30 2007-10-03 华为技术有限公司 一种移动多媒体业务实现方法和条件接收***
WO2007132165A1 (en) * 2006-05-04 2007-11-22 Nds Limited Scrambled digital data item
CN101369886A (zh) * 2007-08-17 2009-02-18 华为技术有限公司 实现iptv媒体内容安全的***、方法及设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1848944A (zh) * 2005-04-05 2006-10-18 华为技术有限公司 一种iptv***、加密数字节目的发布、收看方法
CN101009551A (zh) * 2006-01-24 2007-08-01 华为技术有限公司 基于ip多媒体子***的媒体流的密钥管理***和方法
CN101047829A (zh) * 2006-03-30 2007-10-03 华为技术有限公司 一种移动多媒体业务实现方法和条件接收***
WO2007132165A1 (en) * 2006-05-04 2007-11-22 Nds Limited Scrambled digital data item
CN101009553A (zh) * 2006-12-30 2007-08-01 中兴通讯股份有限公司 实现多网融合移动多媒体广播***密钥安全的方法和***
CN101369886A (zh) * 2007-08-17 2009-02-18 华为技术有限公司 实现iptv媒体内容安全的***、方法及设备

Also Published As

Publication number Publication date
CN101521570A (zh) 2009-09-02
CN101521570B (zh) 2012-09-19

Similar Documents

Publication Publication Date Title
CN101155191B (zh) 支持ims终端享用现有iptv业务的***和方法
US10397644B2 (en) Switching between delivery methods in an IPTV communication network
EP2279598B1 (en) IPTV security in a communication network
EP2319224B1 (en) Application server, media distribution system, control method thereof, program, and computer-readable storage medium
KR101203266B1 (ko) 스트리밍을 위한 제어 프로토콜 및 전송 프로토콜을 사용한보호 콘텐츠 반송
US20090180614A1 (en) Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network
US7561696B2 (en) Delivering policy updates for protected content
CN101379802B (zh) 在媒体服务器和用户设备之间以加密方式传输媒体数据的方法和装置
WO2007085186A1 (fr) Procédé de gestion de clé de flux multimédia, système et serveur d&#39;application
WO2009024071A1 (fr) Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv
WO2009024092A1 (fr) Procédé et système permettant la commande d&#39;autorisation de ressource de service
US20110060900A1 (en) Method, system, corresponding device, and communication terminal for providing mbms service
WO2009106007A1 (zh) 一种实现iptv组播业务媒体安全的方法、***及设备
WO2006024234A1 (en) Method ano apparatus for protecting broadband video and audio broadcast content
WO2008128475A1 (fr) Système de télévision sur ip à base d&#39;architecture ims et entité de service de protection de contenu et procédé
Yeung et al. Secure Real-Time Streaming Protocol (RTSP) for Hierarchical Proxy Caching.
CN102546574A (zh) 基于ip多媒体子***的流媒体点播方法和装置

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: 09714337

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: 09714337

Country of ref document: EP

Kind code of ref document: A1