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

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

Info

Publication number
CN101521570A
CN101521570A CN200810082852A CN200810082852A CN101521570A CN 101521570 A CN101521570 A CN 101521570A CN 200810082852 A CN200810082852 A CN 200810082852A CN 200810082852 A CN200810082852 A CN 200810082852A CN 101521570 A CN101521570 A CN 101521570A
Authority
CN
China
Prior art keywords
sek
tek
kmf
media
key
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN200810082852A
Other languages
English (en)
Other versions
CN101521570B (zh
Inventor
张占军
何承东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huizhou wisdom Enterprise Management Co., Ltd.
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
Priority to CN200810082852A priority Critical patent/CN101521570B/zh
Priority to PCT/CN2009/070557 priority patent/WO2009106007A1/zh
Publication of CN101521570A publication Critical patent/CN101521570A/zh
Application granted granted Critical
Publication of CN101521570B publication Critical patent/CN101521570B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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

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)

Abstract

本发明公开了一种实现组播媒体安全的方法、系统及装置，该方法包括以下步骤：用户设备UE从密钥管理功能KMF获得业务加密密钥SEK；所述UE接收组播发送的被所述SEK加密的媒体加密密钥TEK密钥流；所述UE使用所述SEK解密出TEK，并使用所述TEK解密所述由TEK加密的组播媒体。本发明在基于IMS网络的IPTV业务的网络中，通过分发密钥SEK和TEK给UE和媒体服务功能实体，实现基于IMS的IPTV架构的LTV组播媒体传输安全。

Description

一种实现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组播媒体传输安全。
附图说明
图1a是本发明实施例中应用场景中IMS based IPTV的业务功能架构图；
图1b是本发明实施例中密钥体系示意图；
图2是本发明实施例中功能实体结构图；
图3是本发明实施例中通过SSF的EPG下发各个频道的媒体保护类型信息和/或SEK密钥标识信息流程图；
图4是本发明实施例中通过SIP会话下发初始频道的媒体保护类型信息和/或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的业务功能架构，如图1a所示，主要包括：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。
本发明实施例中使用的密钥体系如图1b所示，包括：TEK(TrafficEncryption Key，媒体加密密钥)，为媒体流提供机密性和/或完整性保护，对于使用传统CA保护的MPEG2TS(Moving Picture Expert Group 2 TransportStream-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 ManagementFunction，密钥管理功能实体)，用于向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(SecurityReal-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 n1
a＝rtpmap:n1 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-ID1>
           <protection-type>SRTP</protection-type>
          <SEK-ID>SEK-ID1</SEK-ID>
        </Service-ID1>
</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的地址信息。
此外，还可以携带对应的媒体保护类型信息和/或TEK密钥流的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表示方式和携带的方法相同。
步骤202中UE获取SEK的具体实施例包括以下几种：
实施例一，UE直接到KMF请求SEK，具体可以使用HTTP请求携带，基于图5中的K1接口从KMF获取SEK，具体流程如图6所示，包括以下步骤：
步骤601，UE向KMF发送请求消息，例如，使用HTTP中的GET或者POST请求消息，其中携带以下信息的一种或几种：业务包标识、频道(业务)标识、SEK的密钥ID标识；
如果在上述实施例中通过EPG或者SIP会话过程获得了SEK密钥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-package1-SEK1
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-package1-SEK1
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，ZZZ>
...
{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 (28)

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、7或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加密的组播媒体。
CN200810082852A 2008-02-27 2008-02-27 一种实现iptv组播业务媒体安全的方法、系统及设备 Expired - Fee Related CN101521570B (zh)

Priority Applications (2)

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

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
CN101521570A true CN101521570A (zh) 2009-09-02
CN101521570B CN101521570B (zh) 2012-09-19

Family

ID=41015543

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810082852A Expired - Fee Related CN101521570B (zh) 2008-02-27 2008-02-27 一种实现iptv组播业务媒体安全的方法、系统及设备

Country Status (2)

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

Cited By (2)

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

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100459697C (zh) * 2005-04-05 2009-02-04 华为技术有限公司 一种iptv系统、加密数字节目的发布、收看方法
CN101009551B (zh) * 2006-01-24 2010-12-08 华为技术有限公司 基于ip多媒体子系统的媒体流的密钥管理系统和方法
CN100551034C (zh) * 2006-03-30 2009-10-14 华为技术有限公司 一种移动多媒体业务实现方法和条件接收系统
EP2439946B1 (en) * 2006-05-04 2013-07-10 NDS Limited Scrambled digital data item
CN101009553A (zh) * 2006-12-30 2007-08-01 中兴通讯股份有限公司 实现多网融合移动多媒体广播系统密钥安全的方法和系统
WO2009024071A1 (fr) * 2007-08-17 2009-02-26 Huawei Technologies Co., Ltd. Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102143129A (zh) * 2010-05-26 2011-08-03 华为软件技术有限公司 超文本传输协议流媒体传输中实现业务保护的方法和系统
CN102143129B (zh) * 2010-05-26 2015-03-18 华为软件技术有限公司 超文本传输协议流媒体传输中实现业务保护的方法和系统
CN102694769A (zh) * 2011-03-22 2012-09-26 华为技术有限公司 媒体数据处理方法及其装置
CN102694769B (zh) * 2011-03-22 2015-09-30 华为技术有限公司 媒体数据处理方法及其装置
US9390274B2 (en) 2011-03-22 2016-07-12 Huawei Technologies Co., Ltd. Media data processing method and apparatus

Also Published As

Publication number Publication date
CN101521570B (zh) 2012-09-19
WO2009106007A1 (zh) 2009-09-03

Similar Documents

Publication Publication Date Title
CN101155191B (zh) 支持ims终端享用现有iptv业务的系统和方法
KR100724935B1 (ko) 컨텐츠 보호를 위한 개체 간 연동 방법 및 장치, 그리고 그시스템
CA2572345C (en) Method of descrambling a scrambled content data object
US20090180614A1 (en) Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network
US20080065548A1 (en) Method of Providing Conditional Access
EP2279598B1 (en) IPTV security in a communication network
EP2319224B1 (en) Application server, media distribution system, control method thereof, program, and computer-readable storage medium
WO2008046323A1 (fr) Procédé, système et appareil pour la protection de service de télévision pour téléphone mobile
CN101945248A (zh) 处理流中的可录制内容
Hartung et al. Drm protected dynamic adaptive http streaming
WO2011120901A1 (en) Secure descrambling of an audio / video data stream
WO2009024071A1 (fr) Système, procédé et dispositif pour réaliser une sécurité de contenu multimédia iptv
CN101945249A (zh) 处理流中的可录制内容
KR100663443B1 (ko) 서비스 보호를 위한 구조 및 개체간 연동 방법 및 장치그리고 그 시스템
CN1946018B (zh) 一种媒体流的加密及解密方法
Diaz-Sanchez et al. Sharing conditional access modules through the home network for Pay TV Access
CN101521570B (zh) 一种实现iptv组播业务媒体安全的方法、系统及设备
KR100916228B1 (ko) 페이 퍼 뷰 및 서비스 기반 방송 가입자를 위한 ｓｅｋ와ｐｅｋ의 관리 방법 및 그 통신 시스템
Proserpio et al. Achieving IPTV service portability through delegation
KR101175354B1 (ko) 복수의 수신 제한 시스템을 이용하는 콘텐츠 보안 시스템 및 방법
CN103634624A (zh) 基于ip网络的数字电视直播方法及系统
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é
Cortés Sharing Conditional Access Modules through the Home Network for Pay TV Access
Sánchez et al. An Identity Management Infrastructure for Secure Personalized IPTV Services
Lian et al. A secure solution for ubiquitous multimedia broadcasting

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: HUIZHOU ZHITAI ENTERPRISE MANAGEMENT CO., LTD.

Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO., LTD.

Effective date: 20150408

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: 518129 SHENZHEN, GUANGDONG PROVINCE TO: 516003 HUIZHOU, GUANGDONG PROVINCE

TR01 Transfer of patent right

Effective date of registration: 20150408

Address after: 516003 Guangdong province Huizhou City Mountain Road No. 4 Building 12 layer Dweh No. 06 A District

Patentee after: Huizhou wisdom Enterprise Management Co., Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: Huawei Technologies Co., Ltd.

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120919

Termination date: 20160227