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

专利名称：实现iptv媒体内容安全的系统、方法及设备的制作方法
技术领域：
本发明涉及通信^l支术领域，特别涉及一种实现IPTV々某体内容安全的系统、 方法及设备。
背景技术：
頂S Core (IMS核心网)又称Core頂S,是叠加在分组域网络之上，由呼 叫控制功能(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)网络上传输多i某体，包括视频、音频和 数据等媒体内容。该业务实质上是在IMS网络架构下提供IPTV业务，充分利 用頂S网络中已有的会话控制、计费等机制来为用户设备(UE，User Equipment) 提供TV业务。IPTV媒体流业务典型实例是线性电视(LTV， Linear Television) 业务(又叫组播业务BC， Broadcast Service)和内容点播业务(CoD， Content on Demand )。其中，LTV业务为将媒体内容采用组播方式发送给UE的业务，CoD 业务为单播业务。
图1为现有技术基于頂S网络的IPTV业务的业务功能架构一示意图，该 架构是TISPAN标准组织提出的，其中
IPTV媒体功能实体(MF， IPTV Media Function)负责媒体内容的交付给 UE。 IPTV Media Function从功能角度可以分解为i某体功能实体(MCF， Media Control Function)和媒体交付功負g实体(MDF, Media Delivery Function )。
MDF通常为一些^;某体分发力良务器，在MCF的控制下向UE发送媒体流。
IPTV业务控制功能实体(SCF, Service Control Functions )用于处理从 UE发出的IPTV业务请求，提供IPTV的业务控制。
用户签约服务功能实体(UPSF， User Profile Serving Function),用于 存储UE的签约信息；
业务选4奪功能实体(SSF, Service Selection Function),用于给UE提 供可浏览和选^^的业务菜单信息；
传输功能(Transport Functions )，用于传输IPTV中的MF交付给UE的 媒体内容。图2为现有技术基于IMS网络的IPTV业务的业务功能架构二示意 图，该架构是国际电信联盟(ITU-T)标准组织提出的，包括UE、 IPTV应用服 务功能实体(applications )、业务用户签约功能实体(Service user profile function )、 IMS Core、内容交<寸功能实体(Content delivery function)以 及传输层(Transport Stratum),其中
Content delivery function,用于为UE提供々某体内容分发服务，该实体 的功能和图1中的MF的功能类似；
IPTV应用服务功能实体(applications),用于处理从UE发出的IPTV业 务请求，提供IPTV的业务控制，该实体的功能和图1中的SCF类似；
Service user profile function,用于存4诸UE的业务签约4言息，该实体 的功能和图1中的UPSF类似；
Transport Stratum, 用于传输Content delivery function分发给UE 的i某体内容，该实体的功能和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， Ent i t lement Control Message ) 中发送给UE， SK通过授权管理消息(EMM, Entitlement Management Message ) 发送给UE，且SK在传送前需要经过用户个人密钥进行加密处理，这个发送媒 体内容过程如图3所示，UE接收到后，先釆用存储在自身的用户个人分配密钥 解密SK，再用SK解密CW,再用CW解扰媒体内容。
对于现有的CA系统是应用于传统的广播电视系统的媒体加密技术，采用的
是加扰解扰技术，密钥是采用TS封装的格式，不能直接应用在目前的IPTV系统
决的问题。

发明内容
第一方面，本发明实施例提供一种实现媒体安全保护的系统，该系统能够 实现IPTV媒体内容的保护。
一种实现IPTV媒体安全的系统，包括用户设备UE、业务控制功能实体 SCF、 IMS核心网IMS Core、 i某体功能实体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为本发明实施例实现i某体内容安全实施例八的流程图； 图14为本发明实施例实现媒体内容安全实施例九的流程图； 图15为本发明实施例实现媒体内容安全实施例十的流程图； 图16为本发明实施例实现媒体内容安全实施例十一的流程图17为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的
系统二示意图18为本发明实施例实现i某体内容安全实施例十二的流程图； 图19为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的 系统三示意图20为本发明实施媒体内容安全实施例十三的流程图； 图21为本发明实施例提供的KMF结构示意图22为本发明实施例提供一种在MF和KMF之间传输密钥的系统示意图2 3是本发明实施例中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， Content Encryption Function),用来对内容进行加密等处理。CEF是逻辑功能模块， 具体实现时，可以作为一个独立的功能实体存在；也可以MF或者其它的功能 实体的内部逻辑功能单元。
在IPTV业务中，为了对媒体内容进行安全保护，需要使用各种密钥进行 保护，以下针对各种可能使用的密钥的功能进行详细说明。"/"表示"或"的 意思。
媒体保护密钥(TEK， Traffic Encryption Key )，或者称作内容加密密钥， 用于直接对媒体流或内容进行机密性保护或者完整性保护。
业务保护密钥(SEK, Service Encryption Key )，用于对应一个或多个组 播业务、或一个或多个组播业务频道的密钥，可以用来保护TEK在媒体层面的 安全传输(机密性或/和完整性保护)，也可以用来保护业务相关的安全信息， 例如加密算法或密钥有效期等参数，也可以用来保护一个J 某体流内容的节目保 护密钥(PEK)的安全保护。
节目保护密钥(PEK, Program Encryption Key )，可以对应一个或多个频 道中的媒体内容进行安全保护的密钥，可以用来保护TEK在媒体层面的安全传 输，也可以用来保护业务相关的安全信息，例如加密算法或密钥有效期等参数。
业务组密钥(SGK， Service Group Key),用来保护TEK在媒体层面的安 全传输。对于同一 LTV业务的UE进行分组，每组分配一个组密钥SGK,使用 SGK加密的TEK媒体流发送给该组中的UE。同时，所有接收同一媒体内容的UE 可以接收到相同保护的媒体流，各组可以异步的进行SGK的更新。各组的SGK 进行各自更新，可以做到新加入组的UE无法接收以前发送的媒体流，离开组 的UE也无法接收以后发送的媒体流，这样可以减少TEK更新影响的范围。另 外，对于不同级别的UE可能有不同的接收J 某体流权限，这时，可以按照不同
级别UE的权限进行分组，每一个组对应一个SGK来保护TEK的安全下发。
在本发明实施例中， 一般SEK、 PEK或SGK用于对TEK的保护，为了下文 的叙述简便，通称为业务密钥SEK或者密钥加密密钥(KEK， Key Encryption Key )。 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(代 表组播业务)保护和C0D (代表单播业务)保护，以下以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还可以对密钥和/或相关参数进 4亍更新。
这里，需要的功能实体可以为UE、 MF、 SCF等功能实体，相关参数包括密 钥对应的密钥标识、安全算法、密钥有效期等参数的一个或者多个的组合。
为了将KMF引入到基于頂S网络实现IPTV业务的架构中，本发明实施例 在该架构中增加了 一些接口 ，包括KMF和SCF之间的Kl接口 ； KMF和UE之 间的K2接口 ； KMF和IMS Core之间的K4接口 ； SCF和UE之间的K3接口 ； KMF 和MF之间的K5接口 。这些接口主要用于在通过接口连接的两个功能实体之间 传输密钥或/和密钥对应的相关参数。
在图4中，这些接口在具体实现的架构中并不全都是必选的，根据发送密 钥或/和密钥对应的相关参数的所采用的方案不同，如果只在KMF和UE传输， 则K2接口是必须的，其他接口可选；如果在KMF经SCF到UE之间传输，则Kl
和K3接口是必须的，其他接口可选；如果KMF和SCF之间传输，则Kl接口是 必须的，其他接口可选；如果KMF和MF之间传输密钥，则K5接口是必须的， 其他接口可选；如果KMF直接经IMS Core传输密钥，则K4接口是必须的，其 他接口可选。举一个例子说明一下，例如，具体实现中采用在KMF和SCF之间 直接传输密钥或/和密钥对应的相关参数，则可以釆用图5所示的系统架构图， 在图中，可以看出，Kl接口是必须存在的，其他的接口可以存在也可以没有。
以下的各个实施例中以HTTP协议实现的例子只是举HTTP为例进行说明， 具体实现中也可以采用其它协议实现，例如，使用XML的格式或者使用MIKEY 来携带和发送密钥。以下具体说明采用图4提供的系统是如何实现媒体内容安 全的。
实施例一
该实施例可以应用在LTV业务保护或CoD业务保护中，主要是UE和KMF
直接进行交互，应用该实施例时，K2接口就是必须的接口。在实施例一中，图
4所示系统中各设备之间的连接如图5所示。
在该实施例中，UE可以预先与KMF之间产生共享用户密钥，例如，采用引
导架构(GBA， Generic Bootstrapping Architecture)方式产生，然后使用
共享密钥来保护KMF传递给UE的密钥信息。产生共享密钥过程可以在接收到
UE的密钥请求之前或之后进行。
图6为本发明实施例实现i某体内容安全实施例一的流程图，其具体步骤为 步骤601、 UE进行业务建立或者业务切换(LTV的频道切换)的会话过程。 在本步骤中，会话过程与密钥请求过程没有必然的先后顺序。 步骤602、 KMF向UE发送一个密钥获取指示信息，指示UE发起密钥获取
请求，该步骤为可选。
在本步骤中，只有在KMF使用该方式通知UE密钥需要获取的情况才是必
选的。如果UE通过其它的途径得知密钥需要获取，例如，IMS网络侧采用Notify (通知)进行通知需要密钥获取，或者通过检查媒体流中的指示密钥需要获取
的标识(密钥标识)，或者UE发起该业务前就明确知道需要获取密钥，则该指 示消息可以不发送。
步骤6 0 3 、 UE通过K2接口直接向KMF发送密钥请求消息，例如HTTP请求 消息，携带用户标识，业务/内容标识信息或者密钥标识信息。
步骤604、 KMF向SCF或UPF获取该用户的业务授权信息，对用户的请求 进行授权。如果KMF本身具有授权能力，则该步骤可选。
步骤605、 KMF通过K2接口向UE发送响应消息，其中携带密钥，或者还 包括密钥的相关参数。
在本步骤中，密钥为请求消息中所携带的业务/内容或密钥标识信息对应
的密钥、或者还包括密钥的相关参数。
步骤606、 UE利用得到的密钥解开加密的媒体内容，进行观看。 业务/内容或者业务/内容包标识可釆用URI或者頂S中的PSI的形式进行
携带。以下的各个实施例中釆用的业务/内容或者业务/内容包标识类似，不再
重复描述。
对于组播的业务(例如LTV业务)来说，本实施例的密钥可以按照如下的 方式使用密钥模型是三层密钥模型，步骤605中下发的密钥是KEK, KEK使 用SUK来进行加密保护，在媒体层面，KEK加密TEK通过组播下发给UE， UE 首先使用SUK解密出来KEK，再使用KEK解密出来TEK，最后使用TEK解密加 密的媒体流。
对于单播的业务(例如CoD业务)来说，本实施例的密钥可以按照上述的 组播三层密钥的下发方式类似的使用，不同之处在于，媒体面下发的密钥不是 使用组播的方式下发，而是使用单播的方式下发。或者使用二层密钥的模型， 步骤605中下发的密钥是TEK， TEK使用SUK来进行加密保护，在J 某体层面不 需要再下发密钥给UE，UE首先使用SUK解密出来TEK，再使用TEK解密媒体流。
步骤605的响应消息具体的可以是直接对应请求的响应消息，例如请求为 HTTP请求，响应为对应的200消息；也可以是单独发送的消息，例如，使用单
独的UPD消息来携带MIKEY格式的密钥。
实施例二
该实施例可以应用在LTV业务保护或CoD业务保护中，主要是UE和KMF 通过IMS Core直接进行交互，应用该实施例时，采用的架构是Kl接口就是为 必须选的接口的架构。
图7为本发明实施例实现+某体内容安全的实施例二的流程图，其具体步骤
为
步骤701、 UE通过IMS Core向SCF发送业务请求，携带用户标识以及业
务或者内容的标识信息。
步骤702、 SCF通过頂S Core向MF发送业务请求，携带用户标识以及业 务或者内容的标识信息，MF通过IMS Core向SCF返回业务响应消息。
本步骤对于LTV业务请求时不需要。
步骤703、 SCF生成业务授权令牌(Token),并通过IMS Core向UE返回 业务响应消息，携带业务授权Token,还可能携带获取密钥地址信息，如IP 地址或URL或IMS中的PSI。
步骤704、 UE向KMF发送密钥请求消息，其中携带用户标识、以及业务或 者内容标识，以及业务4受权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
接口和Kl接口就是必选的接口 。
在该实施例中，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发送响应消息，携带对应的密钥。
步骤8Q6、 UE获取加密的媒体流，并利用得到密钥解开媒体流，进行观看。
在本发明实施例中，图8还可以进行密钥更新过程，更新后的密钥可由UE
主动向SCF获取，或SCF向UE主动发送密钥。
对于SCF向KMF获取密钥的方法，可以是SCF向KMF发起一个密钥获取请 求消息，携带获取的业务/内容标识信息或者密钥标识信息，KMF向SCF返回该 业务/内容标识或者密钥标识对应的密钥，或者还包括算法、有效期等信息。 SCF也可以保存这些信息，以便后续其它UE进行业务请求时直接从本地查找得 到。具体使用的协议可以4吏用Diameter协议，MIKEY协议，或者HTTP协议、 SIP协议、S0AP、 XML等协议或方式来获取。以下各个实施例中的SCF或者MF 获取密钥的方法都类似，不再重复描述。
实施例四
该实施例可以应用在CoD业务保护中，SCF从KMF获取业务保护密钥发送 给MF,并通过頂S Core返回给UE,结合图4所示的系统，应用该实施例时， 架构中Kl为必选接口。
步骤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发送业务响应消息，比如200 OK消息等。
步骤905、 SCF将密钥等信息添加到业务响应消息中,并通过IMSCore向 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发送业务响应消息(如，200 OK消息)，
携带业务或者内容标识对应的密钥。
步骤1Q05、 SCF通过IMS Core将业务响应消息发送给UE。 步骤1006、 UE采用得到的密钥解开加密的J^某体流，并进行观看。 这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是
三层密钥的不同，可以是KEK,或者是TEK。 实施例六
该实施例可以应用在CoD业务保护中，由SCF向KMF获取业务密钥后通过 IMS Core返回给UE。结合图4所示的系统，应用该实施例时，Kl接口为必选 接口。
图11为本发明实施例实现媒体内容安全实施例六的流程图，其具体步骤
为
步骤1101、 UE通过頂S Core向SCF发起业务请求消息(如，INVITE),
其中携带用户标识，业务或者内容标识信息。
步骤1102、 SCF通过IMS Core向MF发送业务请求消息。 步骤1103、 MF通过IMS Core向SCF发送业务响应消息，如200 OK消息。 步骤1104、 SCF向KMF获取该业务或者内容标识对应的密钥。 步骤1105、 SCF通过IMS Core向UE发送业务响应消息，携带业务或者内
容标识对应的密钥。
说明此处SCF发送的业务响应信息中携带的参数也可以不是密钥，而是
一个获取密钥的地址信息，例如IP地址或URL或IMS中的PSI等标识信息。
此时，步骤1104便不需要。
步骤1106、 UE采用得到的密钥解开i某体流，并进行观看。 这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是
三层密钥的不同，可以是KEK,或者是TEK。 实施例七
该实施例可以应用到LTV或者CoD业务中，SCF向KMF获耳又密钥后通过IMS 会话过程返回给UE。结合图4所示的系统，应用该实施例时，Kl接口为必选 接口。
图12为本发明实施例实现媒体内容安全的实施例七的流程图，其具体步 骤为
步骤1201、 UE通过IMS Core向SCF发起密钥请求消息，如INVITE消息，
其中携带用户标识，业务或者内容的标识信息。
步骤1202、 SCF向KMF获取该业务或者内容标识对应的密钥。 步骤1203、 SCF通过IMS Core向UE发送业务响应消息，携带业务或者内
容标识对应的密钥。
说明此处SCF发送的业务响应信息中携带的参数也可以不是密钥，而是 一个获取密钥的地址信息，例如IP地址或URL或IMS中的PSI等标识信息。 此时，步骤12Q2可以不需要。
步骤12(M、 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 (RFC 3261 )协 议中的订阅(Subscribe)方式从SCF订阅密钥且订阅的为当前业务的密钥。 结合图4所示的系统，应用该实施例时，Kl接口为必选接口 。
图13为本发明实施例实现媒体内容安全的实施例八的流程图，其具体步 骤为
步骤1301、 UE通过IMS Core向SCF发送Subscribe消息，订阅事件为当 前的IPTV业务的密钥，携带用户标识、以及业务或内容标识等信息。
步骤1302、 SCF通过IMS Core向UE返回200 0K消息，表示订阅成功。 步骤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返回200 OK消息。
步骤1308、 UE根据接收到的密钥解开媒体流并进行观看。
密钥更新时，由SCF通过Notify向UE传递更新后的密钥信息，UE回复
200 OK消息即可。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是 三层密钥的不同，可以是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所示的 系统，应用该实施例时，Kl接口为必选接口。
图14为本发明实施例实现媒体内容安全的实施例九的流程图，其具体步 骤为
步骤1401、 UE进行IPTV业务会话建立过程或者频道切换过程。 在本步骤中，会话建立过程或者频道切换过程和密钥订阅的过程没有先后
顺序要求，也可以先不进行会话建立过程，而先进行订阅密钥的过程。
步骤1術、UE通过IMS Core向SCF发送Subscribe消息，订阅一个或者
多个业务或内容标识对应的密钥事件包，消息中携带用户标识、以及业务或内
容标识等信息。
步骤1403、 SCF通过IMS Core向UE返回200 0K消息，表示已经订阅成功。
步骤1404、 SCF从KMF获取对应UE请求的业务标识或者内容标识对应的 密钥。
步骤1405、 SCF通过IMS Core向UE发送Notify消息，其中携带对应UE 订阅的密钥。
步骤1406、 UE通过IMS Core向SCF返回200 OK消息。 步骤1407、 UE采用步骤1405得到的密钥解开保护的媒体流，并进行观看。 密钥更新时，由SCF通过Notify向UE传递更新后的密钥信息，UE回复 200 0K消息即可。在本实施例中，还可以重新发起对新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发送Subscr ibe消息，订阅当前的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返回200 OK消息。 步骤1507、 UE根据接收到的密钥解开媒体流并进行观看。 密钥更新时，由KMF通过Notify向UE传递更新后的密钥信息，UE回复 200 OK消息即可。
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返回200 OK消息，表示已经订阅成功。
步骤1604、 SCF通过IMS Core向UE发送Notify消息，其中携带对应UE 请求的密钥。
步骤1605、 UE通过IMS Core向SCF返回200 OK消息。 步骤1606、 UE采用步骤4得到的密钥解开保护的媒体流，并进行观看。 密钥更新时，由KMF通过Notify向UE传递更新后的密钥信息，UE回复 200 OK消息即可。
在本实施例中，还可以重新发起对新IPTV业务包中某一频道密钥订阅过 程和基本LTV业务会话更改流程(与基本LTV业务会话初始流程类似，在这个 过程中，需要进行频道切换过程，这时，需要采用图16所述的方法重新进行 订阅的过程。
UE还可以采用Subscr ibe方式向MF订阅密钥且订阅的为某个业务的密钥，
结合图4所示的系统，K5接口为必选接口 ，即UE向MF进行订阅，MF通过K5 接口向KMF获取密钥。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是 三层密钥的不同，可以是KEK，或者是TEK。
对于使用GBA建立SUK的情况，这里的Subscribe i青求消息中还可以携带 GBA临时用户标识信息B-TID,以便KMF根据B-TID得到对应的SUK,并使用 SUK保护需要下发的密钥。具体的B-TID可以使用请求消息中的XML对应的元 素来携带。
图17为本发明实施例提供的在IMS系统中实现保证IPTV媒体内容安全的 系统二示意图，在现有基于IMS网络实现IPTV业务的系统中引入了 KMF功能 模块，且将KMF集成到SCF中进行业务保护，也就是说，SCF具有KMF对密钥 进行管理的功能。
这时，具有腿F对密钥进行管理功能的SCF就可以将密钥和/或相关参数 提供给需要的功能实体。SCF还可以产生或从其它功能实体中获取密钥和/或相 关参数，SCF还可以对密钥和/或相关参数进行更新。
这里，需要的功能实体可以为UE、 MF等功能实体，相关参数包括密钥对 应的密钥标识、安全算法、密钥有效期等参数的一个或者多个的组合。
由于KMF集成到了 SCF中，所以图4所述的SCF和KMF之间的Kl接口也 就不存在或变为内部接口 ， SCF和UE之间的Sl接口还具有给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接口是必选的4妻口 。
在该实施例中，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之间的Ll接口在现有的功能外，还具有给 UE传输密钥以及密钥所对应的相关参数功能；頂S Core和MF之间的L2接口 在现有的功能外，还具有给MF传输密钥以及密钥所对应的相关参数功能，SCF 和UE之间的L3接口传输密钥以及密钥所对应的相关参数功能。
在图19中，这些接口并不全是必选的，根据传输密钥或/和密钥对应的相 关参数的所经过的途径不同，所选取的接口也不相同。如果在MF和SCF之间 的Ll接口传输，则MF和SCF之间的Ll接口存在，其他的接口可以存在或不 存在；如果在IMS Core和MF之间的L2接口传输，则IMS Core和MF之间的 L2接口必须存在，其他的接口可以存在或不存在。
在图19所示的系统三中，业务保护的具体过程与上述图4的KMF作为独 立的功能实体的业务保护过程类似(实施例一到实施例十一)，只不过KMF是 MF的一个内部功能模块，不需要在实施例中的MF到KMF获取密钥的步骤，其 它功能实体与KMF的交互改为与MF的交互即可。举例说明一下。
实施例十三
图2Q为本发明实施例实现^某体内容安全的实施例十三的流程图，如图所 示，该流程图和实施例五的流程图相比，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发送业务响应消息(如200 OK消息)， 携带业务或者内容标识对应的密钥。
步骤2004、 SCF通过IMS Core将业务响应消息发送给UE。
步骤2005、 UE釆用得到的密钥解开纟某体流，并进行观看。
这里下发的密钥具体的类似实施例一中的密钥，根据选择的二层密钥还是 三层密钥的不同，可以是KEK，或者是TEK。
对于KMF集成到MF中的情况，以上的KMF为独立的功能实体的各个实施 例都可以类似本实施例处理。
对于以上所有的UE获取密钥的实施例来说，如果网络侧提前获取了用户 需要的对应的密钥信息，例如网络侧得知用户切换到一个新的加密的频道，则 网络侧可以在UE没有主动发起请求的时候向UE主动发送该业务或者内容对应 的密钥，也就是说，UE发送密钥请求消息不是一定需要的。具体的过程和使用 的参数和UE主动请求的实施例类似。
本发明实施例还4是供一种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传递密钥。Ml和 M2接口不需要同时存在的，根据方案不同选用不同的接口 。
架构一架构选用M1为必选接口， M2接口可选的^妻口；架构二架构选 用M2为必选接口， Ml接口为可选的接口。
基于架构一的方案
方案一对于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业务 和C0D业务。可以是KMF产生KEK， MF产生TEK; KMF主动发送KEK给MF或者 MF到KMF主动请求KEK的方式将KEK发送给MF， MF使用KEK加密TEK，组播 下发给UE。
方案四对于MF将直接用于保护媒体的密钥TEK釆用组播的方式下发给 UE的情况，TEK需要使用一个密钥进行保护，这里叫做KEK。适用于LTV业务 和CQD业务。KMF产生KEK和TEK; KMF主动发送KEK和TEK给MF或者MF到 KMF主动请求KEK和TEK。
架构二使用M2接口传递密钥，具体流程类似架构一的流程，只是KMF与 MF之间的密铜4专递的3各径是KMF _ M2 — SCF _ Core IMS — MF。
此外，以上实施例所述的IPTV媒体安全的系统还可以包括内容加密实体， 用于加密媒体内容。
其中，所述内容加密实体CEF,用于生成J 某体保护密钥TEK,并将所述TEK
发送给所述密钥管理功能实体KMF;
所述密钥管理功能实体KMF，用于利用密钥加密密钥KEK对所述媒体保护 密钥进行加密，并将加密后的^ 某体保护密钥发送给所述内容加密实体。
或者，所述内容加密实体，用于生成媒体保护密钥，并向所述密钥管理功 能实体发送密钥请求消息，请求密钥加密密钥KEK;利用所述密钥加密密钥对 所述媒体保护密钥进行加密；
所述密钥管理功能实体，用于向所述内容加密实体提供密钥加密密钥。
或者，所述内容加密实体，用于向所述密钥管理功能实体发送密钥请求消
自
所述密钥管理功能实体，用于生成密钥加密密钥以及媒体保护密钥，并根 据所述密钥请求消息，利用密钥加密密钥对所述媒体保护密钥进行加密；并将 加密后的媒体保护密钥以及未加密的媒体保护密钥发送给所述内容加密实体。
或者，所述内容加密实体，用于向所述密钥管理功能实体发送密钥请求消 息；利用密钥加密密钥对所述纟某体保护密钥进行加密；
所述密钥管理功能实体，用于生成密钥加密密钥以及i某体保护密钥，并将 所述密钥加密密钥以及J 某体保护密钥发送给所述内容加密实体。
下面，分别结合图23-图27描述一下上述各系统的工作过程图。
如图2 3所示，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， CEF1吏用返回的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所示，本发明实施例内容加密i某体包括密钥生成单元2901,用 于生成媒体保护密钥；密钥收发单元2902，用于将所述J 某体保护密钥发送给密 钥管理功能实体。其中，所述密钥收发单元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通过组播的J 某体通 道发送给UE;或者CEF将CEF上报给KMF后，KMF使用KEK加密TEK，再由KMF 将KEK加密后的TEK通过组播的J 某体通道发送给UE。 UE通过上述的与KMF获 取密钥的实施例获取到SUK加密的KEK，再通过组播通道获得KEK加密的TEK 和TEK加密的媒体，然后使用KEK解密得到TEK，再使用TEK解密加密的媒体。
对于CEF是KMF或者MF的内部模块的情况，以上的交互就变成了内部处理。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，
是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于 一计算
机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。
其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory,
ROM)或随机存储记忆体(Random Access Memory)等。
以上是对本发明具体实施例的说明，在具体的实施过程中可对本发明的方
法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本发明
的具体实施方式
只是起示范作用，并不用以限制本发明的保护范围。
权利要求
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媒体安全的系统，其特征在于， 所述业务控制功能实体通过与所述密钥管理功能实体之间的Kl接口获取密钥；所述业务控制功能实体通过与所述用户设备之间的K3接口发送所述密钥。
6、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于， 所述用户设备向所述业务控制功能实体发送密钥请求消息，在所述密钥请求消息中包括业务标识或内容标识信息；所述业务控制功能实体通过与所述密钥管理功能实体之间的Kl接口向所 述密钥管理功能实体获取与所述业务标识或内容标识对应的密钥；在收到所述密钥后，所述业务控制功能实体通过与所述用户设备之间的K3 接口 ，将所述密钥发送给所述用户设备。
7、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于， 所述业务控制功能实体通过与所述密钥管理功能实体之间的Kl接口，由所述密钥管理功能实体获取密钥；所述业务控制功能实体通过IMS Core,将所述密钥发送给所述用户设备。
8、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于， 所述用户设备通过IMS Core向业务控制功能实体发送请求消息，在所述密钥请求消息中包括业务标识或内容标识信息；所述业务控制功能实体通过与密钥管理功能实体之间的Kl接口，向所述 密钥管理功能实体获取与所述业务标识或内容标识对应的密钥；所述业务控制功能实体通过IMS Core,将所述密钥发送给所述用户设备。
9、 根据权利要求8所述的实现IPTV媒体安全的系统，其特征在于， 在所述请求消息中包括GBA临时用户标识信息，所述业务控制功能实体将所述GBA临时用户标识信息发送给所述密钥管理功能实体；所述密钥管理功能实体使用所述GBA临时用户标识信息得到用户密钥，并 使用所述用户密钥加密所述请求消息请求的密钥，然后将加密后的所述请求消 息请求的密钥发送给所述业务控制功能实体。
10、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于， 所述媒体功能实体通过与所述密钥管理功能实体之间的K5接口，向所述密钥管理功能实体获取密钥；或者所述媒体功能实体通过与IMS Core之间的 Y2接口、頂S Core、与所述密钥管理功能实体之间的接口 K4接口 ，向所述密 钥管理功能实体获取所述密钥；所述^某体功能实体通过IMS Core向所述用户设备发送所述密钥。
11、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于， 用户设备通过IMS Core向业务控制功能实体发送请求消息，在所述请求消息中携带业务或内容标识信息；所述业务控制功能实体通过IMS Core向媒体功能实体发送请求消息； 所述媒体功能实体向所述密钥管理功能实体获取与所述业务或内容标识信息对应的密钥，并向所述业务控制功能实体发送响应消息，在所述响应消息中携带所述密钥；所述业务控制功能实体通过頂S Core向所述用户设备发送响应消息，其 中携带所述密钥。
12、 根据权利要求11所述的实现IPTV媒体安全的系统，其特征在于， 所述媒体功能实体通过与所述密钥管理功能实体之间的K5接口向所述密钥管理功能实体获取所述密钥；或者，所述媒体功能实体通过与頂S Core之间的Y2接口、 IMS Core与所述密钥 管理功能实体之间的接口 K4接口，向所述密钥管理功能实体获取所述密钥。
13、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，用户设备向业务控制功能实体SCF订阅当前业务/内容或任一业务/内容对 应的密钥；所述业务控制功能实体SCF通过与所述密钥管理功能实体之间的Kl接口 ， 由所述密钥管理功能实体获取相应的密钥后，通过IMS Core将所述密钥发送 给用户设备。
14、 根据权利要求1所述的实现IPTV媒体安全的系统，其特征在于，用户设备向密钥管理功能实体KMF订阅当前业务/内容或任一业务/内容对 应的密钥； 所述密钥管理功能实体KMF在获取到当前业务/内容或任一业务/内容密钥 后，通过与IMS Core之间的K4接口将所述密钥发送给用户设备。
15、 根据权利要求l， 2， 3, 5-14任一权利要求所述的实现IPTV媒体安 全的系统，其特征在于，所述密钥是密钥加密密钥KEK,所述密钥加密密钥KEK 用来加密媒体保护密钥TEK,所述媒体保护密钥TEK用来直接加密媒体。
16、 根据权利要求15所述的实现IPTV媒体安全的系统，其特征在于，其 中所述媒体保护密钥TEK是由所述密钥管理功能实体或媒体功能实体发送给用 户设备的。
17、 根据权利要求11-14任一权利要求所述的实现IPTV媒体安全的系统， 其特征在于，所述密钥是媒体保护密钥TEK，所述媒体保护密钥TEK用来直接 加密媒体。
18、 根据权利要求l， 2, 3, 5-14任一权利要求所述的实现IPTV媒体安 全的系统，其特征在于，所述系统还包括内容加密实体，用于加密i某体内容。
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获得媒体业务安全对应的密钥的步骤具体 为所述用户设备向所述业务控制功能实体发送请求消息，在所述请求消息中 包括业务标识或内容标识信息；所述业务控制功能实体通过与所述密钥管理功能实体之间的Kl接口获取 密钥，由所述密钥管理功能实体获取相应的密钥；在收到所述密钥后，所述业务控制功能实体通过与所述用户设备之间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获得J 某体业务安全对应的密钥的步骤具体 为用户设备向业务控制功能实体SCF订阅当前业务/内容或任一业务/内容对 应的密钥；所述业务控制功能实体SCF通过与所述密钥管理功能实体之间的Kl接口 ， 由所述密钥管理功能实体获取相应的密钥后，通过IMS Core将所述密钥发送 给用户设备。
30、 根据权利要求24所述的实现IPTV媒体安全的方法，其特征在于，所 述用户设备UE从密钥管理功能KMF获得媒体业务安全对应的密钥的步骤具体 为用户设备向密钥管理功能实体KMF订阅当前业务/内容或任一业务/内容对 应的密钥；所述密钥管理功能实体KMF在获取到当前业务/内容或任一业务/内容密钥 后，通过与頂S Core之间的K4接口将所述密钥发送给用户设备。
31、 一种密钥管理功能实体，其特征在于，包括密钥分发单元以及密钥 信息服务功能单元；密钥信息服务功能单元，用于向所述密钥分发单元提供媒体业务安全相关 的密钥；密钥分发单元，用于将所述媒体业务安全相关的密钥发送给用户设备。
32、 一种内容加密实体，其特征在于，包括 密钥生成单元，用于生成々某体保护密钥；密钥收发单元，用于将所述^ 某体保护密钥发送给密钥管理功能实体。
33、 根据权利要求32所述的内容加密实体，其特征在于，所述密钥收发单元，还接收由所述密钥管理功能实体发送的加密后的媒体 保护密钥。
34、 一种内容加密实体，其特征在于，包括 密钥生成单元，用于生成々某体保护密钥；消息发送单元，用于向所述密钥管理功能实体发送密钥请求消息，请求密 钥加密密钥KEK;密钥收发单元，用于接收由所述密钥管理功能实体发送的密钥加密密钥KEK;加密操作单元，用于利用所述密钥加密密钥KEK对所述媒体保护密钥进行 加密。
全文摘要
本发明实施例提供一种实现媒体安全保护的系统、方法及设备，涉及通信技术领域，为能够实现IPTV媒体内容的保护而发明。其中，所述系统包括用户设备UE、业务控制功能实体SCF、IMS核心网IMS Core、媒体功能实体MF，还包括密钥管理功能实体KMF，其中，所述密钥管理功能实体，用于向用户设备提供密钥；所述业务控制功能实体，用于提供对IPTV业务的服务控制；所述媒体功能实体，用于向用户设备发送加密的媒体；所述用户设备，用于接收由媒体功能实体发送的加密的媒体，并使用接收到的密钥得到未加密的媒体。本发明实施例主要应用于IPTV技术中。
文档编号H04N7/167GK101369886SQ20081021048
公开日2009年2月18日 申请日期2008年8月15日 优先权日2007年8月17日
发明者军 严, 张占军, 彭招君, 李金成 申请人:华为技术有限公司