CN101369886A - 实现iptv媒体内容安全的系统、方法及设备 - Google Patents

实现iptv媒体内容安全的系统、方法及设备 Download PDF

Info

Publication number
CN101369886A
CN101369886A CNA2008102104870A CN200810210487A CN101369886A CN 101369886 A CN101369886 A CN 101369886A CN A2008102104870 A CNA2008102104870 A CN A2008102104870A CN 200810210487 A CN200810210487 A CN 200810210487A CN 101369886 A CN101369886 A CN 101369886A
Authority
CN
China
Prior art keywords
key
media
function entity
business
entity
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.)
Pending
Application number
CNA2008102104870A
Other languages
English (en)
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.)
Huawei Technologies 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 CNA2008102104870A priority Critical patent/CN101369886A/zh
Publication of CN101369886A publication Critical patent/CN101369886A/zh
Pending legal-status Critical Current

Links

Images

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

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

本发明实施例提供一种实现媒体安全保护的系统、方法及设备，涉及通信技术领域，为能够实现IPTV媒体内容的保护而发明。其中，所述系统包括：用户设备UE、业务控制功能实体SCF、IMS核心网IMS Core、媒体功能实体MF，还包括密钥管理功能实体KMF，其中，所述密钥管理功能实体，用于向用户设备提供密钥；所述业务控制功能实体，用于提供对IPTV业务的服务控制；所述媒体功能实体，用于向用户设备发送加密的媒体；所述用户设备，用于接收由媒体功能实体发送的加密的媒体，并使用接收到的密钥得到未加密的媒体。本发明实施例主要应用于IPTV技术中。

Description

实现IPTV媒体内容安全的系统、方法及设备
技术领域
本发明涉及通信技术领域，特别涉及一种实现IPTV媒体内容安全的系统、方法及设备。
背景技术
IMS Core(IMS核心网)又称Core IMS，是叠加在分组域网络之上，由呼叫控制功能(CSCF，Call Session Control Function)和用户数据服务功能实体(UPSF，User Profile Serving Function)等功能实体组成的网络系统。其中CSCF又可以分为服务CSCF(S-CSCF)、代理CSCF(P-CSCF)和查询CSCF(I-CSCF)三个逻辑实体。
基于IMS网络的IPTV业务是近几年迅速发展的一种新业务，该业务在因特网协议(IP，Internet Protocol)网络上传输多媒体，包括视频、音频和数据等媒体内容。该业务实质上是在IMS网络架构下提供IPTV业务，充分利用IMS网络中已有的会话控制、计费等机制来为用户设备(UE，User Equipment)提供TV业务。IPTV媒体流业务典型实例是线性电视(LTV，Linear Television)业务(又叫组播业务BC，BroadCast Service)和内容点播业务(CoD，Contenton Demand)。其中，LTV业务为将媒体内容采用组播方式发送给UE的业务，CoD业务为单播业务。
图1为现有技术基于IMS网络的IPTV业务的业务功能架构一示意图，该架构是TISPAN标准组织提出的，其中：
IPTV媒体功能实体(MF，IPTV Media Function)负责媒体内容的交付给UE。IPTV Media Function从功能角度可以分解为媒体功能实体(MCF，MediaControl Function)和媒体交付功能实体(MDF，Media Delivery Function)。MDF通常为一些媒体分发服务器，在MCF的控制下向UE发送媒体流。
IPTV业务控制功能实体(SCF，Service Control Functions)用于处理从UE发出的IPTV业务请求，提供IPTV的业务控制。
用户签约服务功能实体(UPSF，User Profile Serving Function)，用于存储UE的签约信息；
业务选择功能实体(SSF，Service Selection Function)，用于给UE提供可浏览和选择的业务菜单信息；
传输功能(Transport Functions)，用于传输IPTV中的MF交付给UE的媒体内容。图2为现有技术基于IMS网络的IPTV业务的业务功能架构二示意图，该架构是国际电信联盟(ITU-T)标准组织提出的，包括UE、IPTV应用服务功能实体(applications)、业务用户签约功能实体(Service user profilefunction)、IMS Core、内容交付功能实体(Content delivery function)以及传输层(Transport Stratum)，其中：
Content delivery function，用于为UE提供媒体内容分发服务，该实体的功能和图1中的MF的功能类似；
IPTV应用服务功能实体(applications)，用于处理从UE发出的IPTV业务请求，提供IPTV的业务控制，该实体的功能和图1中的SCF类似；
Service user profile function，用于存储UE的业务签约信息，该实体的功能和图1中的UPSF类似；
Transport Stratum，用于传输Content delivery function分发给UE的媒体内容，该实体的功能和Transport Functions类似。
在本发明实施例中的描述为了简便起见，仅仅以图1所述的实体定义描述，对应图2中的类似功能实体如果不做特殊说明，同样也适用。
图1和图2所示的系统可以传输IPTV业务中的媒体内容，特别是在IPTV业务是LTV业务时可以以组播方式传输媒体流，以及IPTV业务是CoD业务时可以以单播方式传输媒体流。但是，目前在组播方式或单播方式传输媒体流时，没有对所传输的媒体流进行安全保护，因此无法保证LTV业务或CoD业务的安全性。
目前，现有技术中，条件接入系统(CA，Conditional Access)方式是传统广播电视中使用的媒体内容安全的保护方法。在该系统中，通过在内容源头对媒体内容进行加扰，UE播放媒体内容时进行解扰，从而实现媒体内容的安全传输。媒体内容、安全信息以及系统中的其它信息封装成一个传输流(TS，Transport Stream)发送给UE。在CA中，安全信息中的密钥是分层保护的:媒体内容使用控制字(CW，Control Word)加扰保护处理，CW由业务密钥(SK，Service Key)加密处理后在授权控制消息(ECM，Entitlement Control Message)中发送给UE，SK通过授权管理消息(EMM，Entitlement Management Message)发送给UE，且SK在传送前需要经过用户个人密钥进行加密处理，这个发送媒体内容过程如图3所示，UE接收到后，先采用存储在自身的用户个人分配密钥解密SK，再用SK解密CW，再用CW解扰媒体内容。
对于现有的CA系统是应用于传统的广播电视系统的媒体加密技术，采用的是加扰解扰技术，密钥是采用TS封装的格式，不能直接应用在目前的IPTV系统中。因此，如何在IMS网络中实现LTV业务的媒体内容安全保护还是一个亟待解决的问题。
发明内容
第一方面，本发明实施例提供一种实现媒体安全保护的系统，该系统能够实现IPTV媒体内容的保护。
一种实现IPTV媒体安全的系统，包括：用户设备UE、业务控制功能实体SCF、IMS核心网IMS Core、媒体功能实体MF，还包括密钥管理功能实体KMF，其中，
所述密钥管理功能实体，用于向用户设备提供密钥；
所述业务控制功能实体，用于提供对IPTV业务的服务控制；
所述媒体功能实体，用于向用户设备发送加密的媒体；
所述用户设备，用于接收由媒体功能实体发送的加密的媒体，并使用接收到的密钥得到未加密的媒体。
第二方面，本发明实施例提供一种实现媒体安全保护的方法，该方法能够实现IPTV媒体内容的保护。
一种实现IPTV媒体安全的方法，包括如下步骤：
用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥；
所述用户设备UE接收媒体功能实体MF发送的加密的媒体；
所述用户设备UE使用所述密钥得到解密的媒体。
第三方面，本发明实施例还提供一种密钥管理功能实体，包括：密钥分发单元以及密钥信息服务功能单元；
密钥信息服务功能单元，用于向所述密钥分发单元提供媒体业务安全相关的密钥；
密钥分发单元，用于将所述媒体业务安全相关的密钥发送给用户设备。
从上述方案可以看出，本发明实施例提供的系统、方法及设备，将进行密钥管理的密钥管理功能实体，引入到现有基于IMS网络实现IPTV业务的系统中，从而使UE可以采用密钥对系统所传输的加密IPTV媒体内容进行解密、收看，其他没有密钥的UE无法解密系统所传输的IPTV媒体内容。因此，本发明实施例提供的系统、方法及设备能够实现IPTV媒体内容的保护。
此外，本发明实施例还提供一种内容加密实体，包括：
密钥生成单元，用于生成媒体保护密钥；
密钥收发单元，用于将所述媒体保护密钥发送给密钥管理功能实体，并接收由所述密钥管理功能实体发送的加密后的媒体保护密钥。
本发明实施例还提供一种内容加密实体，包括：
密钥生成单元，用于生成媒体保护密钥；
消息发送单元，用于向所述密钥管理功能实体发送密钥请求消息，请求密钥加密密钥；
密钥收发单元，用于接收由所述密钥管理功能实体发送的密钥加密密钥；
加密操作单元，用于利用所述密钥加密密钥对所述媒体保护密钥进行加密。
在上述技术方案中，内容加密实体利用媒体保护密钥对媒体内容进行加密，使得媒体内容的安全性得到了保证。
附图说明
图1为现有技术基于IMS网络的IPTV业务的业务功能架构一示意图；
图2为现有技术基于IMS网络的IPTV业务的业务功能架构二示意图；
图3为现有技术在CA中发送媒体内容的示意图；
图4为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统一示意图；
图5为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统一的举例示意图；
图6为本发明实施例实现媒体内容安全实施例一的流程图；
图7为本发明实施例实现媒体内容安全实施例二的流程图；
图8为本发明实施例实现媒体内容安全实施例三的流程图；
图9为本发明实施例实现媒体内容安全实施例四的流程图；
图10为本发明实施例实现媒体内容安全实施例五的流程图；
图11为本发明实施例实现媒体内容安全实施例六的流程图；
图12为本发明实施例实现媒体内容安全实施例七的流程图；
图13为本发明实施例实现媒体内容安全实施例八的流程图；
图14为本发明实施例实现媒体内容安全实施例九的流程图；
图15为本发明实施例实现媒体内容安全实施例十的流程图；
图16为本发明实施例实现媒体内容安全实施例十一的流程图；
图17为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统二示意图；
图18为本发明实施例实现媒体内容安全实施例十二的流程图；
图19为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统三示意图；
图20为本发明实施媒体内容安全实施例十三的流程图；
图21为本发明实施例提供的KMF结构示意图；
图22为本发明实施例提供一种在MF和KMF之间传输密钥的系统示意图；
图23是本发明实施例中KMF和CEF间通过直接接口传递信息系统图；
图24是本发明实施媒体内容安全实施例十四的流程图；
图25是本发明媒体内容安全实施例十五的流程图；
图26是本发明媒体内容安全实施例十六的流程图；
图27是本发明媒体内容安全实施例十七的流程图；
图28是本发明媒体内容安全CEF与MF传递信息的系统图；
图29-图32为本发明实施例内容加密实体的实施例一到实施例四的示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明实施例作进一步的详细描述。
本发明实施例为了保证IPTV媒体内容的安全性，需要对该媒体内容进行安全保护，将对该媒体内容在进行安全保护时使用的密钥传送给UE，UE接收采用密钥对接收到的进行安全保护的媒体内容进行安全验证或解密处理。因此，本发明实施例重新架构了实现基于IMS网络的IPTV业务的网络，在该网络中引入了密钥管理功能实体(KMF，Key Manage Function)。其中，KMF用于发送媒体安全相关的密钥。KMF是逻辑功能模块，具体实现时，可以作为一个独立的功能实体存在；也可以是SCF的内部逻辑功能单元；也可以MF或者其它的功能实体的内部逻辑功能单元。
此外，在该网络架构中，还可以引入内容加密功能实体(CEF，ContentEncryption Function)，用来对内容进行加密等处理。CEF是逻辑功能模块，具体实现时，可以作为一个独立的功能实体存在；也可以MF或者其它的功能实体的内部逻辑功能单元。
在IPTV业务中，为了对媒体内容进行安全保护，需要使用各种密钥进行保护，以下针对各种可能使用的密钥的功能进行详细说明。“/”表示“或”的意思。
媒体保护密钥(TEK，Traffic Encryption Key)，或者称作内容加密密钥，用于直接对媒体流或内容进行机密性保护或者完整性保护。
业务保护密钥(SEK，Service Encryption Key)，用于对应一个或多个组播业务、或一个或多个组播业务频道的密钥，可以用来保护TEK在媒体层面的安全传输(机密性或/和完整性保护)，也可以用来保护业务相关的安全信息，例如加密算法或密钥有效期等参数，也可以用来保护一个媒体流内容的节目保护密钥(PEK)的安全保护。
节目保护密钥(PEK，Program Encryption Key)，可以对应一个或多个频道中的媒体内容进行安全保护的密钥，可以用来保护TEK在媒体层面的安全传输，也可以用来保护业务相关的安全信息，例如加密算法或密钥有效期等参数。
业务组密钥(SGK，Service Group Key)，用来保护TEK在媒体层面的安全传输。对于同一LTV业务的UE进行分组，每组分配一个组密钥SGK，使用SGK加密的TEK媒体流发送给该组中的UE。同时，所有接收同一媒体内容的UE可以接收到相同保护的媒体流，各组可以异步的进行SGK的更新。各组的SGK进行各自更新，可以做到新加入组的UE无法接收以前发送的媒体流，离开组的UE也无法接收以后发送的媒体流，这样可以减少TEK更新影响的范围。另外，对于不同级别的UE可能有不同的接收媒体流权限，这时，可以按照不同级别UE的权限进行分组，每一个组对应一个SGK来保护TEK的安全下发。
在本发明实施例中，一般SEK、PEK或SGK用于对TEK的保护，为了下文的叙述简便，通称为业务密钥SEK或者密钥加密密钥(KEK，Key EncryptionKey)。TEK下文称为媒体保护密钥。
业务用户密钥(SUK，Service User Key)，这是用户相关的密钥，可以用于进行SEK或PEK或SGK的保护，SUK可以是网络侧和UE预先设置的密钥，也可以是使用通用引导架构(GBA，Generic Bootstrapping Architecture)方式产生的密钥，还可以是GBA方式产生的共享密钥衍生出来的用户密钥。
业务注册密钥(SRK，Service Registration Key)，用来实现IPTV业务的用户认证，例如可以使用HTTP摘要(HTTP digest)认证方法对用户进行认证。SRK可以是网络侧和UE预先设置的密钥，也可以是使用GBA方式产生的密钥，还可以是GBA方式产生的共享密钥衍生出来的用户密钥，衍生方式可以由LTV业务的网络侧和UE预先设置好。
在本发明实施例中，将SUK或SRK称为用户密钥SUK，这个密钥一般用于保护用户特定的机密信息的下发，例如，对业务密钥进行保护。
在本发明实施例中，IPTV业务的保护根据具体业务不同，可以分为LTV(代表组播业务)保护和COD(代表单播业务)保护，以下以LTV说明组播业务，以CoD说明单播业务。这两种业务的保护具体采用哪些密钥进行保护是根据业务实际部署需要而有所取舍的。例如，LTV保护可以使用SEK和TEK，媒体流使用TEK进行保护，TEK使用SEK进行保护，加密后的TEK和加密的媒体都通过媒体组播下发，SEK通过信令面下发。LTV保护也可以只使用TEK对媒体进行保护，媒体流使用TEK进行保护通过媒体组播下发，TEK通过信令面下发。COD保护可以只使用TEK对媒体进行保护，媒体流使用TEK进行保护通过媒体面下发，TEK通过信令面下发。
对于业务包(一组业务)来说，流程中的密钥可以指的是整个业务包内的所有业务共享的密钥；也可以指的是业务包内的每个业务对应的不同的密钥的集合；也可以是虽然业务包内的每个业务对应的密钥不同，但是下发密钥只是当前用户请求的业务包内的某个业务对应的密钥。
在本发明以下的具体实施例中，保护的媒体内容需根据采用的密钥不同，可能为单个或多个不同的媒体流。例如，如果向UE下发KEK作为密钥时，UE接收使用KEK加密的TEK流以及用TEK保护的媒体流，这时，UE就可以采用得到的KEK解密得到TEK，再用TEK解密媒体流收看。如果向UE下发TEK作为密钥时，UE接收用TEK保护的媒体流，采用得到的TEK解密媒体流。以下在具体叙述时，KEK或TEK都通称为密钥，媒体面下发的媒体流和/或密钥流都简称为保护的媒体流。
以下对如何在网络中引入了KMF和CEF后，实现对IPTV业务媒体内容进行安全保护进行详细说明。
图4为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统一示意图，在现有基于IMS网络实现IPTV业务的系统中引入了KMF，用于将密钥和/或密钥相关参数提供给需要的功能实体。此外，KMF还可以产生或从其它功能实体中获取密钥和/或相关参数，KMF还可以对密钥和/或相关参数进行更新。
这里，需要的功能实体可以为UE、MF、SCF等功能实体，相关参数包括密钥对应的密钥标识、安全算法、密钥有效期等参数的一个或者多个的组合。
为了将KMF引入到基于IMS网络实现IPTV业务的架构中，本发明实施例在该架构中增加了一些接口，包括：KMF和SCF之间的K1接口；KMF和UE之间的K2接口；KMF和IMS Core之间的K4接口；SCF和UE之间的K3接口；KMF和MF之间的K5接口。这些接口主要用于在通过接口连接的两个功能实体之间传输密钥或/和密钥对应的相关参数。
在图4中，这些接口在具体实现的架构中并不全都是必选的，根据发送密钥或/和密钥对应的相关参数的所采用的方案不同，如果只在KMF和UE传输，则K2接口是必须的，其他接口可选；如果在KMF经SCF到UE之间传输，则K1和K3接口是必须的，其他接口可选；如果KMF和SCF之间传输，则K1接口是必须的，其他接口可选；如果KMF和MF之间传输密钥，则K5接口是必须的，其他接口可选；如果KMF直接经IMS Core传输密钥，则K4接口是必须的，其他接口可选。举一个例子说明一下，例如，具体实现中采用在KMF和SCF之间直接传输密钥或/和密钥对应的相关参数，则可以采用图5所示的系统架构图，在图中，可以看出，K1接口是必须存在的，其他的接口可以存在也可以没有。
以下的各个实施例中以HTTP协议实现的例子只是举HTTP为例进行说明，具体实现中也可以采用其它协议实现，例如，使用XML的格式或者使用MIKEY来携带和发送密钥。以下具体说明采用图4提供的系统是如何实现媒体内容安全的。
实施例一
该实施例可以应用在LTV业务保护或CoD业务保护中，主要是UE和KMF直接进行交互，应用该实施例时，K2接口就是必须的接口。在实施例一中，图4所示系统中各设备之间的连接如图5所示。
在该实施例中，UE可以预先与KMF之间产生共享用户密钥，例如，采用引导架构(GBA，Generic Bootstrapping Architecture)方式产生，然后使用共享密钥来保护KMF传递给UE的密钥信息。产生共享密钥过程可以在接收到UE的密钥请求之前或之后进行。
图6为本发明实施例实现媒体内容安全实施例一的流程图，其具体步骤为：
步骤601、UE进行业务建立或者业务切换(LTV的频道切换)的会话过程。
在本步骤中，会话过程与密钥请求过程没有必然的先后顺序。
步骤602、KMF向UE发送一个密钥获取指示信息，指示UE发起密钥获取请求，该步骤为可选。
在本步骤中，只有在KMF使用该方式通知UE密钥需要获取的情况才是必选的。如果UE通过其它的途径得知密钥需要获取，例如，IMS网络侧采用Notify(通知)进行通知需要密钥获取，或者通过检查媒体流中的指示密钥需要获取的标识(密钥标识)，或者UE发起该业务前就明确知道需要获取密钥，则该指示消息可以不发送。
步骤603、UE通过K2接口直接向KMF发送密钥请求消息，例如HTTP请求消息，携带用户标识，业务/内容标识信息或者密钥标识信息。
步骤604、KMF向SCF或UPF获取该用户的业务授权信息，对用户的请求进行授权。如果KMF本身具有授权能力，则该步骤可选。
步骤605、KMF通过K2接口向UE发送响应消息，其中携带密钥，或者还包括密钥的相关参数。
在本步骤中，密钥为请求消息中所携带的业务/内容或密钥标识信息对应的密钥、或者还包括密钥的相关参数。
步骤606、UE利用得到的密钥解开加密的媒体内容，进行观看。
业务/内容或者业务/内容包标识可采用URI或者IMS中的PSI的形式进行携带。以下的各个实施例中采用的业务/内容或者业务/内容包标识类似，不再重复描述。
对于组播的业务(例如LTV业务)来说，本实施例的密钥可以按照如下的方式使用:密钥模型是三层密钥模型，步骤605中下发的密钥是KEK，KEK使用SUK来进行加密保护，在媒体层面，KEK加密TEK通过组播下发给UE，UE首先使用SUK解密出来KEK，再使用KEK解密出来TEK，最后使用TEK解密加密的媒体流。
对于单播的业务(例如CoD业务)来说，本实施例的密钥可以按照上述的组播三层密钥的下发方式类似的使用，不同之处在于，媒体面下发的密钥不是使用组播的方式下发，而是使用单播的方式下发。或者使用二层密钥的模型，步骤605中下发的密钥是TEK，TEK使用SUK来进行加密保护，在媒体层面不需要再下发密钥给UE，UE首先使用SUK解密出来TEK，再使用TEK解密媒体流。
步骤605的响应消息具体的可以是直接对应请求的响应消息，例如请求为HTTP请求，响应为对应的200消息；也可以是单独发送的消息，例如，使用单独的UPD消息来携带MIKEY格式的密钥。
实施例二
该实施例可以应用在LTV业务保护或CoD业务保护中，主要是UE和KMF通过IMS Core直接进行交互，应用该实施例时，采用的架构是K1接口就是为必须选的接口的架构。
图7为本发明实施例实现媒体内容安全的实施例二的流程图，其具体步骤为:
步骤701、UE通过IMS Core向SCF发送业务请求，携带用户标识以及业务或者内容的标识信息。
步骤702、SCF通过IMS Core向MF发送业务请求，携带用户标识以及业务或者内容的标识信息，MF通过IMS Core向SCF返回业务响应消息。
本步骤对于LTV业务请求时不需要。
步骤703、SCF生成业务授权令牌(Token)，并通过IMS Core向UE返回业务响应消息，携带业务授权Token，还可能携带获取密钥地址信息，如IP地址或URL或IMS中的PSI。
步骤704、UE向KMF发送密钥请求消息，其中携带用户标识、以及业务或者内容标识，以及业务授权Token。
步骤705、KMF接收到该消息后，验证授权Token通过后，向UE返回密钥。
步骤706、UE利用得到的密钥解开加密的媒体流，进行观看。
在图7的步骤704之前，KMF也可以先发送一个触发消息给UE，要求UE到KMF来获取密钥信息。
图7中的授权Token的下发可以有多种方式，UE获取Token除了在会话建立过程中获取外，还可以从其它途径获取，如业务定购、通过电子解密菜单(EPG)携带下发等方式获取，在本实施例中不一一列举。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
在本发明实施例中，业务授权Token是指授权实体(例如SCF或者MF)检查UE有权获取业务对应的密钥以及密钥的相关参数而下发的一种凭证，形式可以是多样的，例如，业务授权Token是字符串或数字；也可以是一个列表，包含对应的业务或者内容的标识、用户名等信息；此外，授权实体还可以对token进行签名下发。
实施例三
该实施例可以应用在LTV业务保护或CoD业务保护中，主要是UE通过SCF和KMF进行密钥的分发，结合图4所示的系统，应用该实施例时，架构中的K3接口和K1接口就是必选的接口。
在该实施例中，UE可以预先与SCF之间产生共享用户密钥，如可以采用GBA方式产生，然后使用共享密钥来保护SCF传递给UE的密钥信息。产生共享密钥过程可以在接收到UE的密钥请求之前或之后进行。
图8为本发明实施例实现媒体内容安全实施例三的流程图，其具体步骤为:
步骤801、UE进行业务建立或者业务切换(LTV的频道切换)的会话过程。
在本步骤中，会话过程与密钥请求过程没有必然的先后顺序。
步骤802、SCF可以向UE发送一个密钥获取指示信息，指示UE发起密钥获取请求，该步骤为可选。
在本步骤中，只有在SCF使用该方式通知UE密钥需要获取的情况才是必选的。如果UE通过其它的途径得知密钥需要获取，例如，IMS网络侧采用Notify(通知)进行通知需要密钥获取，或者通过检查媒体流中的指示密钥需要获取的标识(密钥标识)，则该指示消息可以不发送。
步骤803、UE通过K3接口向SCF发送密钥请求消息，携带用户标识，业务/内容标识信息或者密钥标识信息。
步骤804、SCF向KMF获取密钥以及密钥的相关参数。
步骤805、SCF向UE发送响应消息，携带对应的密钥。
步骤806、UE获取加密的媒体流，并利用得到密钥解开媒体流，进行观看。
在本发明实施例中，图8还可以进行密钥更新过程，更新后的密钥可由UE主动向SCF获取，或SCF向UE主动发送密钥。
对于SCF向KMF获取密钥的方法，可以是SCF向KMF发起一个密钥获取请求消息，携带获取的业务/内容标识信息或者密钥标识信息，KMF向SCF返回该业务/内容标识或者密钥标识对应的密钥，或者还包括算法、有效期等信息。SCF也可以保存这些信息，以便后续其它UE进行业务请求时直接从本地查找得到。具体使用的协议可以使用Diameter协议，MIKEY协议，或者HTTP协议、SIP协议、SOAP、XML等协议或方式来获取。以下各个实施例中的SCF或者MF获取密钥的方法都类似，不再重复描述。
实施例四
该实施例可以应用在CoD业务保护中，SCF从KMF获取业务保护密钥发送给MF，并通过IMS Core返回给UE，结合图4所示的系统，应用该实施例时，架构中K1为必选接口。
图9为本发明实施例实现媒体内容安全实施例四的流程图，其具体步骤为:
步骤901、UE通过IMS Core向SCF发起业务请求消息，比如INVITE，其中携带用户标识、业务或者内容标识信息。
步骤902、SCF向KMF获取该业务或者内容标识对应的密钥。
步骤903、SCF通过IMS Core向MF发送业务请求消息，其中携带业务或者内容标识，以及对应的密钥等信息。
说明:MF可以使用该密钥对内容进行实时加密。此处SCF发送的请求信息中携带的参数也可以不是密钥，而是一个获取密钥的地址信息，例如IP地址或URL或IMS中的PSI等标识信息。此时，步骤902便不需要。
步骤904、MF通过IMS Core向SCF发送业务响应消息，比如200OK消息等。
步骤905、SCF将密钥等信息添加到业务响应消息中，并通过IMS Core向UE转发业务响应消息，其中携带业务或者内容标识对应的密钥信息或密钥获取地址信息。
步骤906、UE采用得到的密钥解开媒体流，并进行观看。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
实施例五
该实施例可以应用在CoD业务保护中，MF向KMF获取密钥后通过IMS Core返回给UE。结合图4所示的系统，应用该实施例时，K5为必选接口；或者MF使用Y2和K4接口向KMF获取对应的密钥。
图10为本发明实施例实现媒体内容安全实施例五的流程图，其具体步骤为:
步骤1001、UE通过IMS Core向SCF发起业务请求消息，如INVITE消息，其中携带用户标识，业务或者内容标识信息。
步骤1002、SCF通过IMS Core向MF发送业务请求消息，其中携带用户标识，业务或者内容标识信息。
步骤1003、MF向KMF获取该业务或者内容标识对应的密钥。
说明:MF可以使用该密钥对内容进行实时加密。
步骤1004、MF通过IMS Core向SCF发送业务响应消息(如，200OK消息)，携带业务或者内容标识对应的密钥。
步骤1005、SCF通过IMS Core将业务响应消息发送给UE。
步骤1006、UE采用得到的密钥解开加密的媒体流，并进行观看。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
实施例六
该实施例可以应用在CoD业务保护中，由SCF向KMF获取业务密钥后通过IMS Core返回给UE。结合图4所示的系统，应用该实施例时，K1接口为必选接口。
图11为本发明实施例实现媒体内容安全实施例六的流程图，其具体步骤为：
步骤1101、UE通过IMS Core向SCF发起业务请求消息(如，INVITE)，其中携带用户标识，业务或者内容标识信息。
步骤1102、SCF通过IMS Core向MF发送业务请求消息。
步骤1103、MF通过IMS Core向SCF发送业务响应消息，如200OK消息。
步骤1104、SCF向KMF获取该业务或者内容标识对应的密钥。
步骤1105、SCF通过IMS Core向UE发送业务响应消息，携带业务或者内容标识对应的密钥。
说明：此处SCF发送的业务响应信息中携带的参数也可以不是密钥，而是一个获取密钥的地址信息，例如IP地址或URL或IMS中的PSI等标识信息。此时，步骤1104便不需要。
步骤1106、UE采用得到的密钥解开媒体流，并进行观看。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
实施例七
该实施例可以应用到LTV或者CoD业务中，SCF向KMF获取密钥后通过IMS会话过程返回给UE。结合图4所示的系统，应用该实施例时，K1接口为必选接口。
图12为本发明实施例实现媒体内容安全的实施例七的流程图，其具体步骤为：
步骤1201、UE通过IMS Core向SCF发起密钥请求消息，如INVITE消息，其中携带用户标识，业务或者内容的标识信息。
步骤1202、SCF向KMF获取该业务或者内容标识对应的密钥。
步骤1203、SCF通过IMS Core向UE发送业务响应消息，携带业务或者内容标识对应的密钥。
说明：此处SCF发送的业务响应信息中携带的参数也可以不是密钥，而是一个获取密钥的地址信息，例如IP地址或URL或IMS中的PSI等标识信息。此时，步骤1202可以不需要。
步骤1204、UE接收加密的媒体流，采用密钥得到媒体流，并进行观看。
本实施例中的密钥请求消息和密钥响应消息可以使用SIP请求消息，例如，使用Invite消息和200响应消息。
本实施例中的密钥下发使用的是直接使用业务响应消息携带的。此外，所述密钥也可以不通过业务响应消息携带，而使用另外的消息来携带，例如KMF或者SCF使用一个单独的UDP消息发送给UE。
对于组播的业务(例如LTV业务)来说，本实施例的密钥可以按照如下的方式使用：密钥模型是三层密钥模型，步骤1202中请求的密钥是KEK，KEK使用SUK来进行加密保护，在媒体层面，KEK加密TEK可以通过KMF或者MF通过组播下发给UE。UE首先使用SUK解密出来KEK，再使用KEK解密出来TEK，最后使用TEK解密加密的媒体流。
对于单播的业务(例如CoD业务)来说，本实施例的密钥可以按照上述的组播三层密钥的下发方式类似的使用，不同之处在于，媒体面下发的密钥不是使用组播的方式下发，而是使用单播的方式下发。或者使用二层密钥的模型，步骤1202中请求的密钥是TEK，TEK使用SUK来进行加密保护，在媒体层面不需要再下发密钥给UE，UE首先使用SUK解密出来TEK，再使用TEK解密媒体流。
对于使用GBA建立SUK的情况，这里的请求消息中还可以携带GBA临时用户标识信息B-TID，SCF将B-TID发送给KMF，以便KMF根据B-TID得到对应的SUK，并使用SUK保护需要下发的密钥。具体的B-TID可以使用SIP请求消息中的XML对应的元素来携带。
在图12中，密钥更新过程和基本业务建立过程基本类似，分为UE主动发起的密钥更新过程和网络侧主动发起的密钥更新过程。密钥更新可以使用SIP中的INVITE(邀请)消息或者Update(更新)或者Publish(发布)消息或者Notify消息以及对应的应答消息来携带密钥更新请求信息以及密钥。
在图12中，业务请求也可以由网络侧的实体来发起，过程和本实施例类似，只不过是网络侧在发起请求的消息中便携带密钥给UE。
对于频道切换的过程：如果整个业务包(组播业务组)内的所有业务共享一套密钥或者如果初始下发了整个业务包内的所有业务对应的不同的密钥的集合；那么UE在同一个业务包内的所有频道间进行切换的时候，就不需要再发起密钥请求消息。如果初始下发的仅仅是某个业务或者业务包内的某个业务对应的密钥，那么UE在进行频道切换的时候，需要向网络侧获取密钥。或者UE切换到了另外一个业务包内的业务或者频道的时候，也需要向网络侧获取密钥。
实施例八
该实施例可以应用到LTV业务和CoD业务中，UE采用SIP(RFC3261)协议中的订阅(Subscribe)方式从SCF订阅密钥且订阅的为当前业务的密钥。结合图4所示的系统，应用该实施例时，K1接口为必选接口。
图13为本发明实施例实现媒体内容安全的实施例八的流程图，其具体步骤为:
步骤1301、UE通过IMS Core向SCF发送Subscribe消息，订阅事件为当前的IPTV业务的密钥，携带用户标识、以及业务或内容标识等信息。
步骤1302、SCF通过IMS Core向UE返回200 OK消息，表示订阅成功。
步骤1303、UE进行IPTV业务建立或者切换过程。
在本步骤中，业务建立或者切换过程与密钥的订阅和下发没有必然的顺序关系，密钥的订阅和下发可以在业务建立或者切换过程之前、过程中或者之后发送。
步骤1304、SCF获取UE当前的业务信息。
在本步骤中，SCF获取UE当前的业务方式可以有多种，如SCF采用Subscribe/Notify方式向UE订阅其当前的LTV频道信息或者CoD内容信息；或者SCF通过会话建立或者切换过程中得知UE当前的业务的信息；或者SCF向在线状态服务器Presence Server订阅UE的当前业务信息。
步骤1305、SCF从KMF获取UE当前业务或内容标识对应的密钥。
步骤1306、SCF通过IMS Core向UE发送Notify消息，携带UE当前业务或内容对应的密钥。
步骤1307、UE通过IMS Core向SCF返回200OK消息。
步骤1308、UE根据接收到的密钥解开媒体流并进行观看。
密钥更新时，由SCF通过Notify向UE传递更新后的密钥信息，UE回复200OK消息即可。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
对于使用GBA建立SUK的情况，这里的Subscribe请求消息中还可以携带GBA临时用户标识信息B-TID，SCF将B-TID发送给KMF，以便KMF根据B-TID得到对应的SUK，并使用SUK保护需要下发的密钥。具体的B-TID可以使用请求消息中的XML对应的元素来携带。
实施例九
该实施例可以应用到LTV业务和CoD业务中，该实施例UE采用Subscribe方式从SCF订阅密钥且订阅的为某个业务或内容对应的密钥。结合图4所示的系统，应用该实施例时，K1接口为必选接口。
图14为本发明实施例实现媒体内容安全的实施例九的流程图，其具体步骤为:
步骤1401、UE进行IPTV业务会话建立过程或者频道切换过程。
在本步骤中，会话建立过程或者频道切换过程和密钥订阅的过程没有先后顺序要求，也可以先不进行会话建立过程，而先进行订阅密钥的过程。
步骤1402、UE通过IMS Core向SCF发送Subscribe消息，订阅一个或者多个业务或内容标识对应的密钥事件包，消息中携带用户标识、以及业务或内容标识等信息。
步骤1403、SCF通过IMS Core向UE返回200 OK消息，表示已经订阅成功。
步骤1404、SCF从KMF获取对应UE请求的业务标识或者内容标识对应的密钥。
步骤1405、SCF通过IMS Core向UE发送Notify消息，其中携带对应UE订阅的密钥。
步骤1406、UE通过IMS Core向SCF返回200OK消息。
步骤1407、UE采用步骤1405得到的密钥解开保护的媒体流，并进行观看。
密钥更新时，由SCF通过Notify向UE传递更新后的密钥信息，UE回复200OK消息即可。在本实施例中，还可以重新发起对新IPTV业务包中某一频道密钥订阅过程和基本LTV业务会话更改流程(与基本LTV业务会话初始流程类似)，在这个过程中，需要进行频道切换过程，这时，需要采用图14所述的方法重新进行订阅的过程。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
对于使用GBA建立SUK的情况，这里的Subscribe请求消息中还可以携带GBA临时用户标识信息B-TID，SCF将B-TID发送给KMF，以便KMF根据B-TID得到对应的SUK，并使用SUK保护需要下发的密钥。具体的B-TID可以使用请求消息中的XML对应的元素来携带。
实施例十
该实施例可以应用到LTV业务和CoD业务中，这个方法UE采用Subscribe方式从KMF订阅密钥且订阅的为当前业务的密钥。结合图4所示的系统，应用该实施例时，K4接口为必选接口。
图15为本发明实施例实现媒体内容安全的实施例十的流程图，其具体步骤为：
步骤1501、UE通过IMS Core向KMF发送Subscribe消息，订阅当前的IPTV业务的密钥，携带用户标识、以及业务或内容标识等信息。
步骤1502、KMF通过IMS Core向UE返回200 OK消息，表示订阅成功。
步骤1503、UE进行IPTV业务建立或者切换过程。
在本步骤中，业务建立或者切换过程与密钥的订阅和下发没有必然的顺序关系，密钥的订阅和下发可以在业务建立或者切换过程之前、过程中或者之后发送。
步骤1504、KMF获取UE当前的业务信息。
在本步骤中，KMF获取UE当前的业务方式可以有多种，如KMF采用Subscribe/Notify方式向UE订阅其当前的LTV频道信息或者CoD内容信息；或者KMF通过会话建立或者切换过程中得知UE当前的业务的信息；或者KMF向Presence Server订阅UE的当前业务信息。
步骤1505、KMF通过IMS Core向UE发送Notify消息，携带UE当前业务标识或者内容标识对应的密钥。
步骤1506、UE通过IMS Core向KMF返回200OK消息。
步骤1507、UE根据接收到的密钥解开媒体流并进行观看。
密钥更新时，由KMF通过Notify向UE传递更新后的密钥信息，UE回复200OK消息即可。
UE还可以采用Subscribe方式向MF订阅密钥且订阅的为当前业务的密钥，结合图4所示的系统，K5接口为必选接口，即UE向MF进行订阅，MF通过K5接口向KMF获取密钥。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
对于使用GBA建立SUK的情况，这里的Subscribe请求消息中还可以携带GBA临时用户标识信息B-TID，以便KMF根据B-TID得到对应的SUK，并使用SUK保护需要下发的密钥。具体的B-TID可以使用请求消息中的XML对应的元素来携带。
实施例十一
该实施例可以应用到LTV业务和CoD业务中，这个方法UE采用Subscribe方式从KMF订阅密钥且订阅的为某个业务或者内容对应的密钥。结合图4所示的系统，应用该实施例时，K4接口为必选接口的架构。
图16为本发明实施例实现媒体内容安全的实施例十一的流程图，其具体步骤为：
步骤1601、UE进行IPTV业务会话建立过程或者频道切换过程。
在本步骤中，会话建立过程或者频道切换过程和密钥订阅的过程没有先后顺序要求，也可以先不进行会话建立过程，而先进行订阅密钥的过程。
步骤1602、UE通过IMS Core向KMF发送Subscribe消息，订阅一个或者多个业务标识或者内容标识对应的密钥，消息中携带用户标识、以及业务标识或者内容标识等信息。
步骤1603、KMF通过IMS Core向UE返回200OK消息，表示已经订阅成功。
步骤1604、SCF通过IMS Core向UE发送Notify消息，其中携带对应UE请求的密钥。
步骤1605、UE通过IMS Core向SCF返回200OK消息。
步骤1606、UE采用步骤4得到的密钥解开保护的媒体流，并进行观看。
密钥更新时，由KMF通过Notify向UE传递更新后的密钥信息，UE回复200OK消息即可。
在本实施例中，还可以重新发起对新IPTV业务包中某一频道密钥订阅过程和基本LTV业务会话更改流程(与基本LTV业务会话初始流程类似，在这个过程中，需要进行频道切换过程，这时，需要采用图16所述的方法重新进行订阅的过程。
UE还可以采用Subscribe方式向MF订阅密钥且订阅的为某个业务的密钥，结合图4所示的系统，K5接口为必选接口，即UE向MF进行订阅，MF通过K5接口向KMF获取密钥。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
对于使用GBA建立SUK的情况，这里的Subscribe请求消息中还可以携带GBA临时用户标识信息B-TID，以便KMF根据B-TID得到对应的SUK，并使用SUK保护需要下发的密钥。具体的B-TID可以使用请求消息中的XML对应的元素来携带。
图17为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的系统二示意图，在现有基于IMS网络实现IPTV业务的系统中引入了KMF功能模块，且将KMF集成到SCF中进行业务保护，也就是说，SCF具有KMF对密钥进行管理的功能。
这时，具有KMF对密钥进行管理功能的SCF就可以将密钥和/或相关参数提供给需要的功能实体。SCF还可以产生或从其它功能实体中获取密钥和/或相关参数，SCF还可以对密钥和/或相关参数进行更新。
这里，需要的功能实体可以为UE、MF等功能实体，相关参数包括密钥对应的密钥标识、安全算法、密钥有效期等参数的一个或者多个的组合。
由于KMF集成到了SCF中，所以图4所述的SCF和KMF之间的K1接口也就不存在或变为内部接口，SCF和UE之间的S1接口还具有给UE传输密钥的功能；SCF和MF之间的S2接口还具有给MF传输密钥的功能；
在图17中，实际应用系统中的架构这些接口并不全必选的，根据分发密钥或/和密钥对应的相关参数的所采用的方案不同，实际架构所选取的接口也不相同。如果在SCF和UE之间直接传输，则S1接口存在，其他的接口可以存在或不存在；如果在SCF和MF之间传输，则S2接口必须存在，其它接口可以存在或不存在。
在图17所示的系统二中，业务保护的具体过程与上述图4的KMF作为独立的功能实体的业务保护过程类似(实施例一到实施例十一)，只不过KMF是SCF的一个内部功能模块，不需要在实施例中的SCF到KMF获取密钥的步骤，其它功能实体与KMF的交互改为与SCF的交互即可。以下举例子说明一下。
实施例十二
图18为本发明实施例实现媒体内容安全的实施例十二的流程图，可以看出，该流程图和实施例三的流程图相比，只是不需要SCF到KMF获取密钥，而SCF具有KMF对密钥进行管理的功能，直接将密钥发送给UE，这样节省了步骤。应用该实施例时，架构中的S1接口是必选的接口。
在该实施例中，UE可以预先与SCF之间产生共享用户密钥，如可以采用GBA方式产生，然后使用共享密钥来保护SCF传递给UE的密钥信息。产生共享密钥过程可以在接收到UE的密钥请求之前或之后进行。
步骤1801、UE进行业务建立或者业务切换(LTV的频道切换)的会话过程。
在本步骤中，会话过程与密钥请求过程没有必然的先后顺序。
步骤1802、SCF可以向UE发送一个密钥获取指示信息，指示UE发起密钥获取请求，该步骤为可选。
步骤1803、UE通过S1接口向SCF发送密钥请求消息，携带用户标识，业务/内容标识信息或者密钥标识信息。
步骤1804、SCF向UE发送响应消息，携带密钥。
步骤1805、UE获取保护的媒体流，并利用得到密钥解开媒体流，进行观看。
对于KMF集成到SCF中的情况，以上的KMF为独立的功能实体的各个实施例都可以类似本实施例处理。
图19为本发明实施例提供的在IMS系统中实现IPTV媒体内容安全的系统三示意图，如图所示，在现有基于IMS网络实现IPTV业务的系统中引入了KMF功能模块，且集成到MF进行业务保护。也就是说，MF具有KMF对密钥进行管理的功能。
这时，具有KMF对密钥进行管理功能的MF就可以将密钥和/或相关参数提供给需要的功能实体。MF还可以产生或从其它功能实体中获取密钥和/或相关参数，MF还可以对密钥和/或相关参数进行更新。
这里，需要的功能实体可以为UE、SCF等功能实体，相关参数包括密钥对应的密钥标识、安全算法、密钥有效期等参数的一个或者多个的组合。
由于KMF集成到了MF中，所以图4所述的MF和KMF之间的K5接口也就不存在或变为内部接口，MF和SCF之间的L1接口在现有的功能外，还具有给UE传输密钥以及密钥所对应的相关参数功能；IMS Core和MF之间的L2接口在现有的功能外，还具有给MF传输密钥以及密钥所对应的相关参数功能，SCF和UE之间的L3接口传输密钥以及密钥所对应的相关参数功能。
在图19中，这些接口并不全是必选的，根据传输密钥或/和密钥对应的相关参数的所经过的途径不同，所选取的接口也不相同。如果在MF和SCF之间的L1接口传输，则MF和SCF之间的L1接口存在，其他的接口可以存在或不存在；如果在IMS Core和MF之间的L2接口传输，则IMS Core和MF之间的L2接口必须存在，其他的接口可以存在或不存在。
在图19所示的系统三中，业务保护的具体过程与上述图4的KMF作为独立的功能实体的业务保护过程类似(实施例一到实施例十一)，只不过KMF是MF的一个内部功能模块，不需要在实施例中的MF到KMF获取密钥的步骤，其它功能实体与KMF的交互改为与MF的交互即可。举例说明一下。
实施例十三
图20为本发明实施例实现媒体内容安全的实施例十三的流程图，如图所示，该流程图和实施例五的流程图相比，MF不需要到KMF获取密钥，而MF具有KMF管理密钥的功能，直接将密钥通过IMS Core和SCF发送给UE即可。该实施例可以应用在CoD业务保护中，M通过IMS Core返回给UE密钥。结合图19所示的系统，应用该实施例时，L2为必选接口。其具体步骤为:
步骤2001、UE通过IMS Core向SCF发起业务请求消息，如INVITE消息，其中携带用户标识，业务或者内容标识信息。
步骤2002、SCF通过IMS Core向MF发送业务请求消息，其中携带用户标识，业务或者内容标识信息。
步骤2003、MF通过IMS Core向SCF发送业务响应消息(如200OK消息)，携带业务或者内容标识对应的密钥。
步骤2004、SCF通过IMS Core将业务响应消息发送给UE。
步骤2005、UE采用得到的密钥解开媒体流，并进行观看。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是三层密钥的不同，可以是KEK，或者是TEK。
对于KMF集成到MF中的情况，以上的KMF为独立的功能实体的各个实施例都可以类似本实施例处理。
对于以上所有的UE获取密钥的实施例来说，如果网络侧提前获取了用户需要的对应的密钥信息，例如网络侧得知用户切换到一个新的加密的频道，则网络侧可以在UE没有主动发起请求的时候向UE主动发送该业务或者内容对应的密钥，也就是说，UE发送密钥请求消息不是一定需要的。具体的过程和使用的参数和UE主动请求的实施例类似。
本发明实施例还提供一种KMF的结构示意图，如图21所示，包括:密钥分发单元2101以及密钥信息服务功能单元2102，其中，
密钥分发单元2101，用于将密钥或/和密钥的相关参数发送给UE或其他功能实体；
密钥信息服务功能单元2102，用于向密钥分发单元2101提供密钥或/和密钥的相关参数，该密钥或/和密钥的相关参数由该单元自身生成，也可以从其他的地方获取。
本发明实施例还提供一种在MF和KMF之间传输密钥的系统示意图，如图22所示，在图中，KMF将密钥通过M1发送给MF，或者通过M2、SCF、Core IMS发给MF。这个图中的MF做业务保护的加密处理工作，对于LTV中TEK使用组播下发的情况，MF还需要将TEK组播下发给UE。
其中的接口M1：用来直接传递密钥；接口M2：经过SCF传递密钥。M1和M2接口不需要同时存在的，根据方案不同选用不同的接口。
架构一：架构选用M1为必选接口，M2接口可选的接口；架构二：架构选用M2为必选接口，M1接口为可选的接口。
基于架构一的方案：
方案一：对于UE和MF之间直接使用TEK进行媒体内容的保护的情况。适用于LTV和CoD业务。由KMF产生TEK，以KMF主动发送给MF或者MF到KMF主动请求密钥的方式，发送给MF。MF使用TEK加密媒体内容。
方案二：对于UE和MF之间直接使用TEK进行媒体内容的保护的情况。适用于LTV和CoD业务。MF产生TEK，MF使用TEK加密媒体内容。以MF主动发送给KMF或者KMF到MF请求密钥的方式，将TEK发送给KMF。
方案三：对于MF将直接用于保护媒体的密钥TEK采用组播的方式下发给UE的情况，TEK需要使用一个密钥进行保护，这里叫做KEK。适用于LTV业务和COD业务。可以是KMF产生KEK，MF产生TEK；KMF主动发送KEK给MF或者MF到KMF主动请求KEK的方式将KEK发送给MF，MF使用KEK加密TEK，组播下发给UE。
方案四：对于MF将直接用于保护媒体的密钥TEK采用组播的方式下发给UE的情况，TEK需要使用一个密钥进行保护，这里叫做KEK。适用于LTV业务和COD业务。KMF产生KEK和TEK；KMF主动发送KEK和TEK给MF或者MF到KMF主动请求KEK和TEK。
架构二使用M2接口传递密钥，具体流程类似架构一的流程，只是KMF与MF之间的密钥传递的路径是KMF-M2-SCF-Core IMS-MF。
此外，以上实施例所述的IPTV媒体安全的系统还可以包括内容加密实体，用于加密媒体内容。
其中，所述内容加密实体CEF，用于生成媒体保护密钥TEK，并将所述TEK发送给所述密钥管理功能实体KMF；
所述密钥管理功能实体KMF，用于利用密钥加密密钥KEK对所述媒体保护密钥进行加密，并将加密后的媒体保护密钥发送给所述内容加密实体。
或者，所述内容加密实体，用于生成媒体保护密钥，并向所述密钥管理功能实体发送密钥请求消息，请求密钥加密密钥KEK；利用所述密钥加密密钥对所述媒体保护密钥进行加密；
所述密钥管理功能实体，用于向所述内容加密实体提供密钥加密密钥。
或者，所述内容加密实体，用于向所述密钥管理功能实体发送密钥请求消息；
所述密钥管理功能实体，用于生成密钥加密密钥以及媒体保护密钥，并根据所述密钥请求消息，利用密钥加密密钥对所述媒体保护密钥进行加密；并将加密后的媒体保护密钥以及未加密的媒体保护密钥发送给所述内容加密实体。
或者，所述内容加密实体，用于向所述密钥管理功能实体发送密钥请求消息；利用密钥加密密钥对所述媒体保护密钥进行加密；
所述密钥管理功能实体，用于生成密钥加密密钥以及媒体保护密钥，并将所述密钥加密密钥以及媒体保护密钥发送给所述内容加密实体。
下面，分别结合图23-图27描述一下上述各系统的工作过程图。
如图23所示，KMF和CEF之间使用直接的接口N1传递以下信息的一种或几种：SEK、TEK、SEK加密的TEK。
实施例十四
CEF产生TEK，如图24所示，包括以下步骤：
步骤2401，CEF产生媒体保护密钥TEK。
步骤2402，CEF向KMF发送密钥请求消息，其中携带内容标识和/或业务标识信息和媒体保护密钥TEK。
步骤2403，KMF收到密钥请求消息后，使用对应的密钥加密密钥SEK加密TEK。
如果CEF仅仅将产生的TEK上报给KMF，不需要SEK加密的TEK，则本步骤可选。
步骤2404，KMF向CEF发送响应消息，其中携带SEK加密的TEK。
如果步骤2403没有，则本步骤中KMF也不发送SEK加密的TEK参数。
后续处理可以为：内容加密实体CEF将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体发送给用户设备。
如果CEF仅仅将生成的TEK上报给KMF，则KMF后续负责将该TEK发送给用户终端。
实施例十五
CEF产生TEK，并取得KMF发送的SEK，如图25所示，包括以下步骤：
步骤2501，CEF向KMF发送密钥请求消息，请求SEK，其中携带内容标识和/或业务标识信息；
步骤2502，KMF收到密钥请求消息，将对应的SEK发送给CEF；
步骤2503，CEF使用返回的SEK加密TEK。
后续处理可以为：内容加密实体CEF将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体发送给用户设备。
实施例十六
KMF产生TEK和SEK，如图26所示，包括以下步骤：
步骤2601，CEF向KMF发送密钥请求消息，其中携带内容标识和/或业务标识信息。
步骤2602，KMF收到密钥请求消息后，使用内容标识和/或业务标识信息对应的SEK加密对应的TEK。
步骤2603，KMF将SEK加密的TEK、未加密的TEK发送给CEF。
后续处理可以为：内容加密实体CEF使用TEK加密媒体。并将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体发送给用户设备。
实施例十七
CEF获取KMF发送的SEK和TEK，如图27所示，包括以下步骤：
步骤2701，CEF向KMF发送密钥请求消息，其中携带内容标识和/或业务标识信息；
步骤2702，KMF收到密钥请求消息后，将对应的SEK和TEK发送给CEF；
步骤2703，CEF使用返回的SEK加密TEK。
后续处理可以为：内容加密实体CEF使用TEK加密媒体。并将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体发送给用户设备。
具体的，CEF可以为一个独立的功能实体，也可以与KMF合设为一个功能实体，也可以跟MF合设为一个功能实体。合设的情况下，CEF作为一个功能模块，与合设实体的交互也就成为了内部处理。图28中，CEF和MF实体间使用N2接口传递SEK加密的TEK等信息。
本发明实施例内容加密实体可以为如图29-图32任一图示的结构。
如图29所示，本发明实施例内容加密媒体包括：密钥生成单元2901，用于生成媒体保护密钥；密钥收发单元2902，用于将所述媒体保护密钥发送给密钥管理功能实体。其中，所述密钥收发单元2902还用于接收由所述密钥管理功能实体发送的加密后的媒体保护密钥。
如图30所示，本发明实施例内容加密媒体包括：密钥生成单元3001，用于生成媒体保护密钥；消息发送单元3002，用于向所述密钥管理功能实体发送密钥请求消息，请求密钥加密密钥；密钥收发单元3003，用于接收由所述密钥管理功能实体发送的密钥加密密钥；加密操作单元3004，用于利用所述密钥加密密钥对所述媒体保护密钥进行加密。
如图31所示，本发明实施例内容加密实体包括：消息发送单元3101，用于向密钥管理功能实体发送密钥请求消息；密钥收发单元3102，用于接收由所述密钥管理功能实体发送的加密后的媒体保护密钥以及未加密的媒体保护密钥。
如图32所示，本发明实施例内容加密实体包括：消息发送单元3201，用于向密钥管理功能实体发送密钥请求消息；密钥收发单元3202，用于接收由所述密钥管理功能实体发送的密钥加密密钥以及媒体保护密钥；加密操作单元3203，用于利用所述密钥加密密钥对所述媒体保护密钥进行加密。
以上的所有实施例，如果采用的是两层密钥模型的系统，即采用用户密钥SUK和媒体加密密钥TEK，KMF通过以上的CEF和KMF的交互，使得KMF获得TEK，并且将加密的媒体部署到MF上，具体的可以是CEF加密媒体并将加密后的媒体发送给MF。UE通过上述的从KMF获取到SUK加密的TEK实施例得到TEK，然后再使用TEK解密MF发送的加密的媒体。
以上的所有实施例，如果采用的是三层密钥模型的系统，即采用用户密钥SUK、媒体加密密钥TEK和密钥加密密钥KEK。具体的步骤可以是CEF使用TEK加密媒体，并将加密后的媒体发送给MF。对于KEK加密的TEK发送给UE的方式：可以采用CEF将KEK加密后的TEK发送给MF，再由MF通过组播的媒体通道发送给UE；或者CEF将CEF上报给KMF后，KMF使用KEK加密TEK，再由KMF将KEK加密后的TEK通过组播的媒体通道发送给UE。UE通过上述的与KMF获取密钥的实施例获取到SUK加密的KEK，再通过组播通道获得KEK加密的TEK和TEK加密的媒体，然后使用KEK解密得到TEK，再使用TEK解密加密的媒体。
对于CEF是KMF或者MF的内部模块的情况，以上的交互就变成了内部处理。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本发明的具体实施方式只是起示范作用，并不用以限制本发明的保护范围。

Claims (34)

1.一种实现IPTV媒体安全的系统，包括IMS核心网IMS Core，其特征在于，所述系统还包括：用户设备UE、业务控制功能实体SCF、媒体功能实体MF，还包括密钥管理功能实体KMF，其中，
所述密钥管理功能实体，用于向用户设备提供密钥；
所述业务控制功能实体，用于提供对IPTV业务的服务控制；
所述媒体功能实体，用于向用户设备发送加密的媒体；
所述用户设备，用于接收由媒体功能实体发送的加密的媒体，并使用接收到的密钥得到未加密的媒体。
2.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述密钥管理功能实体通过与所述用户设备之间的K2接口，向所述用户设备提供密钥。
3.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述用户设备向所述密钥管理功能实体发送密钥请求消息，在所述密钥请求消息中包括业务标识、内容标识或者密钥标识信息；
所述密钥管理功能实体在接收到所述密钥请求消息后，通过与所述用户设备之间的K2接口，向所述用户设备发送与所述业务标识、内容标识或者密钥标识信息对应的密钥。
4.根据权利要求2或3所述的实现IPTV媒体安全的系统，其特征在于，
所述密钥管理功能实体将密钥发送给所述用户设备之前，向业务控制功能实体或者用户数据功能获取该用户设备的业务授权信息，并确定所述用户设备有权获取所述密钥。
5.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述业务控制功能实体通过与所述密钥管理功能实体之间的K1接口获取密钥；
所述业务控制功能实体通过与所述用户设备之间的K3接口发送所述密钥。
6.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述用户设备向所述业务控制功能实体发送密钥请求消息，在所述密钥请求消息中包括业务标识或内容标识信息；
所述业务控制功能实体通过与所述密钥管理功能实体之间的K1接口向所述密钥管理功能实体获取与所述业务标识或内容标识对应的密钥；
在收到所述密钥后，所述业务控制功能实体通过与所述用户设备之间的K3接口，将所述密钥发送给所述用户设备。
7.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述业务控制功能实体通过与所述密钥管理功能实体之间的K1接口，由所述密钥管理功能实体获取密钥；
所述业务控制功能实体通过IMS Core，将所述密钥发送给所述用户设备。
8.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述用户设备通过IMS Core向业务控制功能实体发送请求消息，在所述密钥请求消息中包括业务标识或内容标识信息；
所述业务控制功能实体通过与密钥管理功能实体之间的K1接口，向所述密钥管理功能实体获取与所述业务标识或内容标识对应的密钥；
所述业务控制功能实体通过IMS Core，将所述密钥发送给所述用户设备。
9.根据权利要求8所述的实现IPTV媒体安全的系统，其特征在于，
在所述请求消息中包括GBA临时用户标识信息，所述业务控制功能实体将所述GBA临时用户标识信息发送给所述密钥管理功能实体；
所述密钥管理功能实体使用所述GBA临时用户标识信息得到用户密钥，并使用所述用户密钥加密所述请求消息请求的密钥，然后将加密后的所述请求消息请求的密钥发送给所述业务控制功能实体。
10.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
所述媒体功能实体通过与所述密钥管理功能实体之间的K5接口，向所述密钥管理功能实体获取密钥；或者所述媒体功能实体通过与IMS Core之间的Y2接口、IMS Core、与所述密钥管理功能实体之间的接口K4接口，向所述密钥管理功能实体获取所述密钥；
所述媒体功能实体通过IMS Core向所述用户设备发送所述密钥。
11.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
用户设备通过IMS Core向业务控制功能实体发送请求消息，在所述请求消息中携带业务或内容标识信息；
所述业务控制功能实体通过IMS Core向媒体功能实体发送请求消息；
所述媒体功能实体向所述密钥管理功能实体获取与所述业务或内容标识信息对应的密钥，并向所述业务控制功能实体发送响应消息，在所述响应消息中携带所述密钥；
所述业务控制功能实体通过IMS Core向所述用户设备发送响应消息，其中携带所述密钥。
12.根据权利要求11所述的实现IPTV媒体安全的系统，其特征在于，
所述媒体功能实体通过与所述密钥管理功能实体之间的K5接口向所述密钥管理功能实体获取所述密钥；或者，
所述媒体功能实体通过与IMS Core之间的Y2接口、IMS Core与所述密钥管理功能实体之间的接口K4接口，向所述密钥管理功能实体获取所述密钥。
13.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
用户设备向业务控制功能实体SCF订阅当前业务/内容或任一业务/内容对应的密钥；
所述业务控制功能实体SCF通过与所述密钥管理功能实体之间的K1接口，由所述密钥管理功能实体获取相应的密钥后，通过IMS Core将所述密钥发送给用户设备。
14.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，
用户设备向密钥管理功能实体KMF订阅当前业务/内容或任一业务/内容对应的密钥；
所述密钥管理功能实体KMF在获取到当前业务/内容或任一业务/内容密钥后，通过与IMS Core之间的K4接口将所述密钥发送给用户设备。
15.根据权利要求1，2，3，5-14任一权利要求所述的实现IPTV媒体安全的系统，其特征在于，所述密钥是密钥加密密钥KEK，所述密钥加密密钥KEK用来加密媒体保护密钥TEK，所述媒体保护密钥TEK用来直接加密媒体。
16.根据权利要求15所述的实现IPTV媒体安全的系统，其特征在于，其中所述媒体保护密钥TEK是由所述密钥管理功能实体或媒体功能实体发送给用户设备的。
17.根据权利要求11-14任一权利要求所述的实现IPTV媒体安全的系统，其特征在于，所述密钥是媒体保护密钥TEK，所述媒体保护密钥TEK用来直接加密媒体。
18.根据权利要求1，2，3，5-14任一权利要求所述的实现IPTV媒体安全的系统，其特征在于，所述系统还包括：
内容加密实体，用于加密媒体内容。
19.根据权利要求18所述的实现IPTV媒体安全的系统，其特征在于，
所述内容加密实体，还用于生成媒体保护密钥TEK，并将所述媒体保护密钥TEK发送给所述密钥管理功能实体，由所述密钥管理功能实体将所述媒体保护密钥TEK发送给用户设备。
20.根据权利要求18所述的实现IPTV媒体安全的系统，其特征在于，
所述内容加密实体，用于接收由所述密钥管理功能实体发送的媒体保护密钥TEK，并使用所述媒体保护密钥TEK加密媒体；
所述密钥管理功能实体，用于生成媒体保护密钥TEK，并将所述媒体保护密钥TEK发送给内容加密实体。
21.根据权利要求18所述的实现IPTV媒体安全的系统，其特征在于，
所述内容加密实体，用于生成媒体保护密钥TEK，并将所述媒体保护密钥TEK发送给所述密钥管理功能实体；
所述密钥管理功能实体，用于利用密钥加密密钥KEK对所述媒体保护密钥TEK进行加密，并将加密后的媒体保护密钥TEK发送给所述内容加密实体，以使所述内容加密实体将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体，并由所述媒体功能实体发送给用户设备。
22.根据权利要求18所述的实现IPTV媒体安全的系统，其特征在于，
所述内容加密实体，用于生成媒体保护密钥TEK，并向所述密钥管理功能实体发送密钥请求消息，请求密钥加密密钥KEK；利用所述密钥加密密钥KEK对所述媒体保护密钥TEK进行加密，所述内容加密实体将所述加密的TEK发送给用户设备，或者将加密的TEK交给媒体功能实体，并由所述媒体功能实体发送给用户设备；
所述密钥管理功能实体，用于向所述内容加密实体提供密钥加密密钥KEK。
23.根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，所述密钥管理功能实体是所述业务控制功能实体中或所述媒体功能实体中的一个逻辑功能模块。
24.一种实现IPTV媒体安全的方法，其特征在于，所述方法包括如下步骤：
用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥；
所述用户设备UE接收媒体功能实体MF发送的加密的媒体；
所述用户设备UE使用所述密钥得到解密的媒体。
25.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
所述密钥管理功能实体接收由用户设备发送的密钥请求消息，在所述密钥请求消息中携带业务标识、内容标识或者密钥标识信息；
所述密钥管理功能实体将与所述业务标识、内容标识或者密钥标识信息所对应的密钥发送给用户设备。
26.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
所述用户设备向所述业务控制功能实体发送请求消息，在所述请求消息中包括业务标识或内容标识信息；
所述业务控制功能实体通过与所述密钥管理功能实体之间的K1接口获取密钥，由所述密钥管理功能实体获取相应的密钥；
在收到所述密钥后，所述业务控制功能实体通过与所述用户设备之间K3接口，将所述密钥发送给所述用户设备。
27.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
所述用户设备通过IMS Core向业务控制功能实体发送请求消息；
所述业务控制功能实体由所述密钥管理功能实体获取对应的密钥；
所述业务控制功能实体通过IMS Core，将所述密钥发送给所述用户设备。
28.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
用户设备通过IMS Core向业务控制功能实体发送请求消息，在所述请求消息中携带业务标识或内容标识信息；
所述业务控制功能实体通过IMS Core向媒体功能实体发送请求消息；
所述媒体功能实体向所述密钥管理功能实体获取与所述业务或内容标识信息对应的密钥，并向所述业务控制功能实体发送响应消息，在所述响应消息中携带所述密钥；
所述业务控制功能实体通过IMS Core向所述用户设备发送响应消息；其中携带所述密钥。
29.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
用户设备向业务控制功能实体SCF订阅当前业务/内容或任一业务/内容对应的密钥；
所述业务控制功能实体SCF通过与所述密钥管理功能实体之间的K1接口，由所述密钥管理功能实体获取相应的密钥后，通过IMS Core将所述密钥发送给用户设备。
30.根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体为：
用户设备向密钥管理功能实体KMF订阅当前业务/内容或任一业务/内容对应的密钥；
所述密钥管理功能实体KMF在获取到当前业务/内容或任一业务/内容密钥后，通过与IMS Core之间的K4接口将所述密钥发送给用户设备。
31.一种密钥管理功能实体，其特征在于，包括：密钥分发单元以及密钥信息服务功能单元；
密钥信息服务功能单元，用于向所述密钥分发单元提供媒体业务安全相关的密钥；
密钥分发单元，用于将所述媒体业务安全相关的密钥发送给用户设备。
32.一种内容加密实体，其特征在于，包括：
密钥生成单元，用于生成媒体保护密钥；
密钥收发单元，用于将所述媒体保护密钥发送给密钥管理功能实体。
33.根据权利要求32所述的内容加密实体，其特征在于，
所述密钥收发单元，还接收由所述密钥管理功能实体发送的加密后的媒体保护密钥。
34.一种内容加密实体，其特征在于，包括：
密钥生成单元，用于生成媒体保护密钥；
消息发送单元，用于向所述密钥管理功能实体发送密钥请求消息，请求密钥加密密钥KEK；
密钥收发单元，用于接收由所述密钥管理功能实体发送的密钥加密密钥KEK；
加密操作单元，用于利用所述密钥加密密钥KEK对所述媒体保护密钥进行加密。
CNA2008102104870A 2007-08-17 2008-08-15 实现iptv媒体内容安全的系统、方法及设备 Pending CN101369886A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNA2008102104870A CN101369886A (zh) 2007-08-17 2008-08-15 实现iptv媒体内容安全的系统、方法及设备

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200710146735 2007-08-17
CN200710146735.5 2007-08-17
CNA2008102104870A CN101369886A (zh) 2007-08-17 2008-08-15 实现iptv媒体内容安全的系统、方法及设备

Publications (1)

Publication Number Publication Date
CN101369886A true CN101369886A (zh) 2009-02-18

Family

ID=40377855

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2008102104870A Pending CN101369886A (zh) 2007-08-17 2008-08-15 实现iptv媒体内容安全的系统、方法及设备

Country Status (2)

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

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009106007A1 (zh) * 2008-02-27 2009-09-03 华为技术有限公司 一种实现iptv组播业务媒体安全的方法、系统及设备
WO2010145160A1 (zh) * 2009-06-30 2010-12-23 中兴通讯股份有限公司 一种媒体点播业务的实现方法
CN101998384A (zh) * 2009-08-18 2011-03-30 中国移动通信集团公司 一种加密传输媒体流的方法、加密服务器和移动终端
CN102273172A (zh) * 2009-05-18 2011-12-07 爱立信电话股份有限公司 用于在机顶盒中实现ims功能性的方法
CN102546574A (zh) * 2010-12-24 2012-07-04 中国移动通信集团公司 基于ip多媒体子系统的流媒体点播方法和装置
CN101510825B (zh) * 2009-02-25 2014-04-30 中兴通讯股份有限公司 一种管理消息的保护方法及系统
CN105656621A (zh) * 2014-11-12 2016-06-08 江苏威盾网络科技有限公司 一种密码设备安全管理方法
CN110431882A (zh) * 2017-03-20 2019-11-08 高通股份有限公司 无线通信系统中的用户平面重定位技术
CN112118206A (zh) * 2019-06-19 2020-12-22 贵州白山云科技股份有限公司 一种解密方法、装置、系统、介质及设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100459697C (zh) * 2005-04-05 2009-02-04 华为技术有限公司 一种iptv系统、加密数字节目的发布、收看方法
US20070140299A1 (en) * 2005-12-15 2007-06-21 Hofmann Markus A Method and network for providing service blending to a subscriber
CN100518292C (zh) * 2006-10-27 2009-07-22 华为技术有限公司 一种获取epg的方法及iptv业务系统

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009106007A1 (zh) * 2008-02-27 2009-09-03 华为技术有限公司 一种实现iptv组播业务媒体安全的方法、系统及设备
CN101510825B (zh) * 2009-02-25 2014-04-30 中兴通讯股份有限公司 一种管理消息的保护方法及系统
CN102273172A (zh) * 2009-05-18 2011-12-07 爱立信电话股份有限公司 用于在机顶盒中实现ims功能性的方法
CN102273172B (zh) * 2009-05-18 2016-06-01 爱立信电话股份有限公司 用于在机顶盒中实现ims功能性的方法
WO2010145160A1 (zh) * 2009-06-30 2010-12-23 中兴通讯股份有限公司 一种媒体点播业务的实现方法
CN101729535B (zh) * 2009-06-30 2013-03-20 中兴通讯股份有限公司 一种媒体点播业务的实现方法
CN101998384A (zh) * 2009-08-18 2011-03-30 中国移动通信集团公司 一种加密传输媒体流的方法、加密服务器和移动终端
CN101998384B (zh) * 2009-08-18 2014-03-26 中国移动通信集团公司 一种加密传输媒体流的方法、加密服务器和移动终端
CN102546574B (zh) * 2010-12-24 2014-10-08 中国移动通信集团公司 基于ip多媒体子系统的流媒体点播方法和装置
CN102546574A (zh) * 2010-12-24 2012-07-04 中国移动通信集团公司 基于ip多媒体子系统的流媒体点播方法和装置
CN105656621A (zh) * 2014-11-12 2016-06-08 江苏威盾网络科技有限公司 一种密码设备安全管理方法
CN110431882A (zh) * 2017-03-20 2019-11-08 高通股份有限公司 无线通信系统中的用户平面重定位技术
CN110431882B (zh) * 2017-03-20 2021-11-19 高通股份有限公司 无线通信系统中的用户平面重定位技术
US11490436B2 (en) 2017-03-20 2022-11-01 Qualcomm Incorporated User plane relocation techniques in wireless communication systems
CN112118206A (zh) * 2019-06-19 2020-12-22 贵州白山云科技股份有限公司 一种解密方法、装置、系统、介质及设备
WO2020253662A1 (zh) * 2019-06-19 2020-12-24 贵州白山云科技股份有限公司 一种解密方法、装置、系统、介质及设备
CN112118206B (zh) * 2019-06-19 2022-04-12 贵州白山云科技股份有限公司 一种解密方法、装置、系统、介质及设备

Also Published As

Publication number Publication date
WO2009024071A1 (fr) 2009-02-26

Similar Documents

Publication Publication Date Title
CN101369886A (zh) 实现iptv媒体内容安全的系统、方法及设备
EP2461539B1 (en) Control word protection
US20090180614A1 (en) Content protection of internet protocol (ip)-based television and video content delivered over an ip multimedia subsystem (ims)-based network
JP5106845B2 (ja) スクランブルされたコンテンツデータオブジェクトをデスクランブルする方法
CN101076109B (zh) 数字电视双向ca系统和基于该系统的节目订购/取消方法
US20060069645A1 (en) Method and apparatus for providing secured content distribution
US20030140257A1 (en) Encryption, authentication, and key management for multimedia content pre-encryption
US8645680B2 (en) Sending media data via an intermediate node
CN102724568A (zh) 认证凭证
EP2532155A1 (en) Method to manage members of at least one group of decoders having access to audio/video data
CN101150395A (zh) 一种加密授权管理系统的双重分组的四层加密方法
CN1946018B (zh) 一种媒体流的加密及解密方法
CN106803980B (zh) 加密控制字的保护方法、硬件安全模块、主芯片和终端
CN101562520B (zh) 业务密钥分发方法及系统、密钥分发方法
CN102917252B (zh) Iptv节目流内容保护系统及方法
CN101202883B (zh) 一种iptv系统的数字版权管理系统
CN101505400B (zh) 一种双向机顶盒及其认证方法、条件接收系统和认证系统
CN101505462B (zh) 一种移动多媒体广播条件接收的鉴权方法及系统
CN100521771C (zh) 一种融合互联网和有线电视网络环境下的有条件接收系统
US20120011368A1 (en) Method and system for transmitting delay media information in ip multimedia subsystem
CN103546767A (zh) 多媒体业务的内容保护方法和系统
CN100544429C (zh) 一种手机电视业务内容保护方法
KR100916228B1 (ko) 페이 퍼 뷰 및 서비스 기반 방송 가입자를 위한 ｓｅｋ와ｐｅｋ의 관리 방법 및 그 통신 시스템
CN101521570B (zh) 一种实现iptv组播业务媒体安全的方法、系统及设备
Proserpio et al. Achieving IPTV service portability through delegation

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Open date: 20090218