一种组播会话安全策略的分发方法及组播装置的制作方法

专利名称：一种组播会话安全策略的分发方法及组播装置的制作方法
技术领域：
本发明涉及计算机与通信技术领域，尤其涉及一种组播会话安全策略的分 发方法及组播装置。
背景技术：
实时传输协i义(Real-time Transport Protocol, RTP)是一个网纟各传l俞协i义， 它是由互if关网工程项目组(Internet Engineering Task Force, IETF )的多々某体传 输小组在于1996年公布的。RTP协议详细说明了互联网上音频和3见频的标准 数据包格式，是网际协议(Internet Protocol, IP)电话产业的技术基础。安全 的实时传输协议(Secure RTP ， SRTP )是RTP协议的一个子集，用于为RTP 协议提供私密性和完整性保护。SRTP协议本身并不具备算法和密码参数的协 商功能，通常这项功能采用信令协议和其他的密钥管理协议承担。根据最新的 研究成果，在点对点的RTP会话中，以数据才艮传输层安全性(Datagram Transport Layer Security, DTLS )为基础的带内密钥协商受到很大程度的认可。这里， 带内定义为RTP会话数据的传送通道；带外定义为非RTP会话数据的传送通 道，包括信令通道，超文本传输协议(Hyper Text Transfer Protocol, HTTP)传 送通道等。
现有技术提供的密钥协商的方案中，协商功能由信令通道承载，采用信令 通道承载SRTP的安全策略。SRTP组播会话发送方利用会话发布协议(Session Announcement Protocol, SAP )或者会"i舌启动十力4义(Session Initiation Protocol, SIP)逐个邀请SRTP组播会话接收方建立组播SRTP会话，在信令协议中携带会 话描述协议(Session Description Protocol, SDP)描述符，具体描述SRTP的安 全策略。在实现本发明过程中，发明人发现现有技术中至少存在如下问题 首先，这种方案继承了点到点信令方案的问题，存在内容早到的缺陷。内 容早到主要是由于密钥流和实时数据流不同步产生的，在实际应用过程中，实 时数据流和密钥流采用不同的传送路径，且采用不同的服务质量(Quality of Service, QoS )策略，因而传送时延不能准确的确定，很可能出现加密内容数据 早于安全策略更新确认数据到达。由于密钥还没有被装载到SRTP协议栈，导 致先到的加密数据流不能正常解密还原。不但会造成数据中断，影响用户体验 质量，也会产生潜在的安全漏洞。
其次，这种方案与具体的实现方案相关。解决组播SRTP会话，例如组播会 议场景等，通常各SRTP组播会话接收方通过互联网组管理协议(Internet Group Management Protocol, IGMP)加入组播组，接收组播数据。此时，带外方式 的信令协商不是组播系统必须的功能，基于带外信令方式的密钥协商受限于具 体的实现方式。
最后，这种方案在复杂多终端系统的情况下，会出现信任终端不明确的问 题。实际应用中，被叫终端(SRTP组播会话接收方)可能会被SIP代理服务 器转接到其他终端(SRTP组播会话接收方)或者多个终端(SRTP组播会话接 收方)上，这些被转接的终端(SRTP组播会话接收方)可能没有加入组播RTP 会话的权利，却可以通过SIP携带的密钥，侦听加密的组播SRTP会话。
因此，现有技术中的密钥协商方案，不能满足组播SRTP会话安全策略的 安全协商要求，存在着诸如内容早到、受限于组播RTP会话的具体建立方式以 及存在信任终端不明确等问题。

发明内容
本发明实施例提供一种组播会话安全策略的分发方法及组播装置，用以解 决现有技术中的密钥协商方案不能满足组播SRTP会话安全策略的安全协商要 求的问题。
一种组播会话安全策略的分发方法，该方法包括
安全实时传输组播会话发送方与安全实时传输组播会话接收方建立数据 报传输层安全性会话后，接收安全实时传输组播会话接收方发送的安全策略请 求数据，根据安全策略构建安全策略回应数据，将安全策略回应数据与组播会 话的安全实时传输协议数据复用后，发送给安全实时传输组播会话接收方。
第一密钥下拉单元，用于建立数据报传输层安全性会话，接收安全策略请 求数据，根据安全策略构建安全策略回应数据并发送；
第 一传输单元，用于发送组播会话的安全实时传输协议数据；
第一复用/解复用单元，用于进行安全策略回应数据与安全实时传输协议数 据的复用并发送；
其中，所述第一复用/解复用单元还用于进行安全策略请求数据与所述安全 实时传输协议数据的解复用。
一种组插4妄收装置，所述装置包括
第二密钥下拉单元，用于建立数据报传输层安全性会话，发送安全策略请 求数据；
第二传输单元，用于将组播会话的安全实时传输协议数据发送给所述第二 复用/解复用单元；
第二复用/解复用单元，用于执行安全策略请求数据与安全实时传输协议数 据的复用并发送；
其中，所述第二复用/解复用单元还用于对接收的包含有安全策略回应数据 与安全实时传输协议数据的复用数据进行解复用；所述第二密钥下拉单元还用 于接收所述安全策略回应数据；所述第二传输单元还用于根据安全策略回应数 据解密接收到的所述组播会话的安全实时传输协议数据。
一种组播装置，所述装置包括
密钥管理单元，用于存储安全策略；
密钥下拉单元，用于建立数据报传输层安全性会话，发送/接收安全策略请求数据；接收/构建安全策略回应数据；
复用/解复用单元，用于执行安全策略请求数据/安全策略回应数据与组播 会话的安全实时传输协议数据的复用与解复用；
传输单元，用于发送/接收安全实时传输协议数据；以及根据安全策略解密 接收到的安全实时传输协议数据；
其中，所述密钥下拉单元接收到安全策略回应数据后，发送给所述密钥管 理单元存储；所述密钥下拉单元从所述密钥管理单元获取构建安全策略回应数 据的安全策略。
本发明实施例通过SRTP组播会话接收方加入组播组，开始SRTP组播会 话；SRTP组播会话接收方与SRTP组播会话发送方开始DTLS握手，建立DTLS 会话；SRTP组播会话接收方与SRTP组播会话发送方进行安全策略的下拉过 程；SRTP组播会话接收方安装安全策略。SRTP组播会话发送方在安全策略过 期或安全策略存在泄密风险的情况下，可以启动安全策略推送过程，更新安全 策略，下发新的安全策略。本发明实施例解决了现有技术的密钥协商方案不能 满足组播SRTP会话安全策略的安全协商要求的问题，并且，由于采用了带内 的方式完成安全策略的协商，可以很好的解决内容早到问题；由于安全策略直 接传递给组播SRTP的接收端，不存在信任终端不明确的问题；由于采用标准 的DTLS协议以及RTP协议，因而本发明实现方式与具体的组播RTP会话建 立方式无关；同时，安全策略的带内传输方式可以很好解决防火墙穿越的问题。


图1为本发明实施例中SRTP组播会话接收方与SRTP组播会话发送方的
结构示意图2为本发明实施例中组播数据信道实现结构图3为本发明实施例中多密钥服务器的信道结构示意图4为本发明实施例中组播会话安全策略的分发方法流程图5为本发明实施例中组播会话安全策略的分发装置的结构示意图； 图6为本发明实施例中组播会话安全策略的分发装置中密钥管理单元的结 构示意图7为本发明实施例中组播会话安全策略的分发装置中密钥下拉单元的结 构示意图8为本发明实施例中组播会话安全策略的分发装置中密钥推送单元的结 构示意图。
具体实施例方式
本发明实施例基于两个基本设备SRTP组播会话发送方和SRTP组播会话 接收方。 一个组播系统中可以存在多个SRTP组播会话接收方，本发明实施例 中以组播系统中仅存在一个SRTP组播会话接收方为例。SRTP组播会话发送方 和SRTP组播会话接收方之间建立组播RTP会话。为了保证所建立的RTP会话的 私密性和完整性，组播RTP会话采用SRTP协议作为安全传输层。SRTP协议本 身并不提供密钥协商的功能，本发明实施例提供一种带内的方式将组播RTP会 话所需的安全策略安全的分发给SRTP组播会话接收方。同时为了增强安全策 略前向安全性和后向安全性，本发明实施例提供一种安全策略的安全更新机 制。
特别的，安全策略包含三个部分内容，具体包括内容密钥(ContentKey, CK)、密钥加密密钥(Key Encryption Key, KEK)和SRTP会话信息。其中， CK用于为SRTP协议栈提供主密钥，相应的SRTP协议栈可以根据CK和SRTP会 话信息生成流量密钥。流量密钥策略通常包括加密密钥、完整性密钥等。KEK 为安全策略更新数据提供私密性和完整性保护，在安全策略中是可选的，当安 全策略推送模块无需更新的情况下，KEK密钥可以省略。RTP会话信息包含序 列数、序列号循环次数等信息，用于同CK一起生成SRTP的流量密钥，为RTP 会话建立完整性和私密性保护。
在具体的实现过程中，本发明实施例利用RTP数据信道(由源端口和目的
端口对确定)传送单播数据和组播数据。如图1所示，为SRTP组播会话发送 方与SRTP组播会话接收方的基本结构示意图。图1中，SRTP组播会话发送 方的IP地址为192.168.100.100，本地端口为9998; SRTP组纟番会话接收方的 IP地址为192.168.100.200,本地端口为9999。组4番;也址为224.16.16.17, 发送到端口 9999。在SRTP组播会话发送方9998端口和SRTP组播会话接收 方9999端口同时存在单向组播信道和双向单播信道。
在实际的应用中，组播信道用于下发組播SRTP会话数据和安全策略更新 的推(PUSH)数据，双向单播信道用于传送RTP会话复用数据(如RTCP数 据，逆向点到点的RTP会话数据等)和组播策略协商的下拉(PULL)交互数 据，如图2所示，为本发明实施例提供的組播信道实现结构，其中，实线表示 组播信道，虚线表示单播信道。
在大规模组网应用等场景下，存在组密钥管理和组播密钥管理服务器分离 的情况，这时存在两种解决方案带外注册带内推送(PUSH)方案和独立复 用/解复用单元方案。如图3所示，为本实施例提供的多密钥服务器的信道结构 示意图，其中，实线表示组播信道，虚线表示单播信道。SRTP组播会话接收 方向密钥管理服务器发出注册请求，利用私有协议建立点对点的数据信道，将 密钥服务器中存储的安全策略PULL到SRTP组播会话接收方，并加以存储， 用以解密SRTP组播会话发送方发送的组播数据。SRTP组播会话发送方和密 钥服务器采用私有协议进行数据交互，获取安全策略更新数据，并PUSH给 SRTP组播会话接收方，PUSH的安全策略更新数据以带内的方式由组播信道 发送给SRTP组播会话接收方。
在采用独立复用/解复用单元方案中，复用/解复用单元采用独立的设备， 解复用后的数据直接上传给SRTP组播会话接收方中相关的密钥管理单元和 SRTP组播会话发送方的RTP传输单元，从而实现安全策略的带内协商。
特别的，带外注册带内PUSH方案和独立复用/解复用单元方案均支持多密钥服务器的负载分担功能。
下面结合各个附图对本发明实施例技术方案的主要实现原理、具体实施方 式及其对应能够达到的有益效果进行详细的阐述。
如图4所示，本发明实施例的主要实现原理流程如下 步骤IO， SRTP组播会话接收方加入組播组，开始组播SRTP会话。 特别的，这个过程需要SRTP组播会话接收方预先了解组播RTP会话的端口 和地址信息。通常组播RTP的管理者采用带外的方式告知SRTP组播会话接收 方，例如，釆用Web门户通告或采用信令协议邀请SRTP组播会话接收方加入。 步骤20， SRTP组播会话接收方与SRTP组播会话发送方开始DTLS握手，建 立DTLS会话。
特别的，这个过程中釆用标准的DTLS协议，只是在实现方式中，SRTP组 播会话接收方与SRTP组播会话发送方交互的数据与RTP数据进行复用后， 一同
进行传输。
实际上，建立SRTP组播会话接收方与SRTP组播会话发送方之间的DTLS 会话，旨在利用现有的DTLS协议中记录层(Record)为即将传送的SRTP组播 会话接收方与SRTP组播会话发送方之间的PULL数据进行私密性和完整性方 面的保护。现有技术中，标准的DTLS协议中的记录层的作用就包括为上层数 据提供安全保护，因而，此处不再对DTLS协议中的记录层的作用做进一步的 赘述。
步骤30, SRTP组播会话接收方与SRTP组播会话发送方进行安全策略的 PULL过程，SRTP组播会话接收方向SRTP组播会话发送方请求安全策略，SRTP 组播会话发送方将安全策略与安全实时传输协议数据复用后， 一同发送给 SRTP组播会话接收方。
特别的，本实施例以及下述的各实施例中，复用是一个常规技术术语，通
常的复用过程就是将多种不同的网络协议数据或其它数据绑定到系统已经开 放的同 一个端口上进行发送或接收；不同的网络协议tt据或其它数据可以通过
数据包中的包头标志位进行区分，从而实现复用数据的解复用。
PULL过程就是SRTP组播会话接收方向SRTP组播会话发送方请求安全策 略的过程。由SRTP组播会话接收方发起PULL过程，向SRTP组播会话发送方请 求安全策略。安全策略请求数据由DTLS协议的记录层保护传送，保证安全策 略请求数据传送的安全。SRTP组播会话发送方收到SRTP组播会话接收方的安 全策略的请求，从本地提取存储的安全策略，构建安全策略回应数据，同样在 DTLS记录层的保护下传送给SRTP组播会话接收方。SRTP组播会话接收方解密 安全策略回应数据，并存储安全策略。
特别的，安全策略包含三个部分内容，具体包括CK、 KEK和RTP会话 信息。其中，CK用于为RTP会话提供主密钥，相应的SRTP组播会话接收方可 以根据CK和SRTP会话信息生成流量密钥，通常的流量密钥包括加密密钥、完 整性密钥等。KEK为安全策略更新数据提供私密性和完整性保护，在安全策略 中是可选的。SRTP会话信息包含序列数、序列号循环次数等，用于和CK一同 生成流量密钥，进而为RTP会话建立完整性和私密性保护。
步骤40, SRTP组播会话接收方安装安全策略。
安装安全策略的过程具体包括装载CK以及相应的RTP会话信息，生成流 量密钥，用以解密通过SRTP协议传输的组播RTP会话数据，输出媒体数据。
特别的，当SRTP组播会话发送方发现安全策略中的CK过期或者CK不 再安全，SRTP组播会话发送方更新安全策略并向SRTP组播会话接收方下发 更新后的安全策略更新数据，为了保障下发的安全策略更新数据的安全性和完 整性，利用KEK对下发的安全策略更新数据进行保护，这个过程就是PUSH 过程。PUSH数据包含安全策略更新数据，用于更新SRTP组播会话接收方的 CK。 PUSH数据包中还可以包含KEK的更新数据，用于同时更新SRTP纽播 会话接收方的KEK数据。PUSH过程是由SRTP组播会话发送方主动发起，采 用組播信道下发，强制更新SRTP组播会话接收方的安全策略。
特别的，上述的安全策略协商过程，可以在组播RTP会话数据发送之前进
行，也可以在组播RTP会话数据过程中进行，并与组播RTP会话数据进行复 用，使用相同的信道进行传输。信道复用的过程中，采用SRTP协议保护的组 播RTP会话数据、采用DTLS协议保护的安全策略请求数据与安全策略回应数 据以及采用KEK保护的安全策略更新数据，经过复用后，在共同的信道中传 输。SRTP组播会话接收方接收到复用的数据后，经过解复用的过程，分别解 密出相应的组播RTP会话数据、安全策略回应数据以及安全策略更新数据，并 进4亍相应的处理。
上述实施例中，采用带内的方式完成安全策略的协商，解决了现有技术的 密钥协商方案不能满足组播SRTP会话安全策略的安全协商要求的问题，并且， 本发明实现方式与具体的组播RTP会话建立方式无关，可以很好的解决内容早 到问题。由于安全策略直接传递给组播SRTP的接收端，不存在信任终端不明 确的问题。同时安全策略的带内传输方式可以很好解决防火墙穿越的问题。
本领域普通技术人员可以理解，实现上述实施例方法中的全部或部分步 骤，是可以通过程序指令相关的硬件来完成的。所述的程序可以存储于计算机 可读取存储介质中，该程序在执行时，包括如下步骤
SRTP组播会话接收方与SRTP组播会话发送方建立DTLS会话后，SRTP 组播会话接收方向SRTP组播会话发送方请求安全策略，接收SRTP组播会话 发送方将安全策略与SRTP协议数据复用后发送的安全策略；
SRTP组播会话接收方安装安全策略。
所述的存储介质，包括ROM/RAM、磁碟、光盘等。
相应地，本发明实施例还提供了一种组播装置，如图5所示，该装置包括 密钥管理单元100、密钥下拉单元200、密钥推送单元300、复用/解复用单元 400以及传输单元500，具体如下
密钥管理单元IOO，用于存储和管理安全策略。
特别的，SRTP组播会话接收方中的密钥管理单元IOO(第二密钥管理单元) 与SRTP组播会话发送方中的密钥管理单元100 (第一密钥管理单元)都用于
存储和管理安全策略。
特别的，这里的安全策略包括CK、 KEK以及RTP会话信息。CK用于 生成RTP会话主密钥，根据CK生成RTP会话的密钥策略；KEK用于为安全 策略更新数据提供私密性和完整性保护；RTP会话信息，用于匹配需要加密的 RTP会话，以及连同CK一同生成相关的RTP会话的密钥策略等。
特别的，为了尽量节省安全策略的存储空间，减少DTLS协商带来的接入 延时，本发明实施例采用CK到RTP会话主密钥的映射机制，即相关的多个 RTP会话采用相同的安全策略。举例来说，在音频传输过程中的左右声道的传 输，需要分别建立不同的RTP会话，由于这两个RTP会话具有很高的相关性， 因而可以采用相同的安全策略，也就是采用相同的RTP会话主密钥。相关RTP 会话复用主要包括三种情况RTCP和RTP复用端口 、对称RTP会话以及多媒 体RTP会话。这三种情况中，虽然存在不同的RTP会话，但是会话间的相关 性密切，可以采用相同的CK或RTP会话的主密钥。由于采用相同的安全策略 会对RTP会话的安全性有所降低，因而具体的实现策略和组播组的策略相关， 映射关系必须坚持RTP会话高相关性的原则，防止内容密钥的泄露。
密钥下拉单元200,用于运行标准的DTLS协议，建立DTLS会话，发送安全 策略请求数据；接收安全策略回应数据，并向密钥管理单元100发送接收的安 全策略回应数据。
在处理安全策略的PULL过程中，SRTP组播会话接收方中的密钥下拉单元 200 (第二密钥下拉单元)首先发起安全策略请求数据；SRTP组播会话发送方 中的密钥下拉单元200 (第一密钥下拉单元)从SRTP组播会话发送方中的密钥 管理单元IOO (第一密钥管理单元)提取安全策略，向SRTP组播会话接收方发 送安全策略回应数据；SRTP组播会话接收方中的密钥下拉单元200 (第二密钥 下拉单元)接收到安全策略回应数据数据后，将相应的安全策略安装到SRTP 组播会话接收方中的密钥管理单元IOO (第二密钥管理单元)中。
整个PULL过程发生在SRTP组播会话发送方和单个SRTP组播会话接收方之间，为点到点的交互。PULL过程作为DTLS的上层应用，整个交互过程 受到DTLS的记录层保护。PULL过程中的安全策略由SRTP组^"会话发送方 的密钥管理单元100(第一密钥管理单元)提供，分三部分构成，具体包括CK、 KEK和RTP会话信 息o
密钥推送单元300，用于在CK过期或者CK出现泄密风险时，进行安全 策略更新与推送，更新并发送安全策略更新数据；接收安全策略更新数据并发 送给密钥管理单元100进行安全策略更新。
特别的，当SRTP组播会话接收方的CK过期，或CK出现泄密风险的时 候，SRTP组播会话发送方中的密钥推送单元300 (第一密钥推送单元)更新 安全策略，生成安全策略更新数据，并发送给SRTP组^燔会话接收方。为了保 障新的CK传输过程中的安全性与完整性，需要使用KEK参数对PUSH过程 中的CK进行加密。PUSH数据包中还可以包含KEK的更新数据，用于同时更 新SRTP组播会话接收方的KEK数据。新的CK数据、KEK数据以及相应的 密码学算法，均是从SRTP组播会话发送方的密钥管理单元100 (第一密钥管 理单元)获取。
SRTP组播会话接收方中的密钥推送单元300 (第二密钥推送单元)接收到 安全策略更新数据后，存储到相应的密钥管理单元100 (第二密钥管理单元) 中。
复用/解复用单元400,用于完成采用SRTP协议保护的组播RTP会话数据， 采用DTLS协议保护的安全策略请求数据与回应，以及采用KEK保护的安全策 略更新数据的复用与解复用。
特别的，SRTP组播会话接收方中的复用/解复用单元400 (第二复用/解复 用单元)与SRTP组播会话发送方中的复用/解复用单元400 (第一复用/解复用 单元)之间建立数据传输信道，用于传输组播RTP会话数据、安全策略请求数 据与回应以及安全策略更新数据复用后的复用数据。
特别的，本实施例中，在密钥协商过程中的所有数据交互，均需要经过复
用/解复用单元400的复用与解复用。并且，为了实现与现有技术的兼容性，本 实施例可以采用的二次复用的机制来区分RTP数据、密钥数据以及其它相关协
议数据。
以解复用的处理流程为例，首先利用SRTP协议的版本号字段进行解复用 接收到的复用数据中的数据头标志位译文(Version) =0的数据，属于其它相关 协议数据，这部分数据送交相关才莫块进行处理；数据头标志位Version-l的数据 为密钥数据，需要进行二次解复用处理；数据头标志位Version-2的数据为RTP 数据，直接送交传输单元500处理。数据头标志位Version4的数据进一步进行 二次解复用，利用相应的标志位区分出安全策略请求数据与回应数据以及安全 策略更新数据。安全策略请求数据与回应数据直接送交密钥下拉单元200处理； 安全策略更新数据送交密钥推送单元300处。发送复用数据的复用流程和上述 解复用流程相反，此处不再详述。
传输单元500，用于通过标准的SRTP协议传输RTP会话数据；根据从密 钥管理单元IOO获取的安全策略，解密接收到的安全实时传输协议数据；在安 全策略更新的PUSH过程中，緩存新的CK密钥。
特别的，SRTP组播会话接收方中的传输单元500 (第二传输单元)用于从 密钥管理单元ioo (第二密钥管理单元)获取的安全策略，解密接收到的安全 实时传输协议数据，并且在安全策略更新的PUSH过程中，緩存新的CK密钥。 SRTP组播会话发送方中的传输单元500 (第一传输单元)用于与SRTP组播会 话接收方中的传输单元500 (第二传输单元)通过标准的SRTP协议建立RTP 会话信道，完成RTP组播会话数据的发送。
较佳地，如图6所示，上述实施例中的密钥管理单元100,进一步包括内 容密钥子单元101、密钥加密子单元102以及会话信息子单元103，其中
内容密钥子单元101,用于储存实时传输协议的安全策略中的内容密钥， 在SRTP组播会话接收方中，内容密钥子单元101还用于向传输单元500装载 安全策略中的内容密钥；
密钥加密子单元102,用于在安全策略更新过程中，存储KEK以及KEK 生成需要的相关参数，这些参数用于密钥推送单元300在密钥推送过程中，对 新生成的CK数据进行KEK加密/解密；
会话信息子单元103,用于存储RTP会话信息，在SRTP组播会话接收方 中，会话信息子单元103还用于向传输单元500装载CK。
较佳地，如图7所示，上述实施例中的密钥下拉单元200,进一步包括密 钥下拉子单元201和安全传输子单元202，其中
密钥下拉子单元201，用于安全策略的PULL过程。在SRTP组播会话接收 方中，密钥下拉子单元201用于发起安全策略请求数据，并接收安全策略回应 数据；在SRTP组播会话发送方中，密钥下拉子单元201用于接收安全策略请求 数据，从密钥管理单元100获取安全策略，构建并发送安全策略回应数据；
安全传输子单元202，用于运行标准的DTLS协议，在SRTP组播会话接 收方和SRTP组播会话发送方建立DTLS会话，利用DTLS的记录层保护密钥 下拉子单元201所发送的安全策略请求数据与安全策略回应数据的私密性和完 整性。
较佳地，如图8所示，上述实施例中的密钥推送单元300,进一步包括密 钥推送子单元301和密钥加密子单元302，其中
密钥推送子单元301,在SRTP组播会话发送方中，用于更新并发送安全 策略更新数据；在SRTP组播会话接收方中，用于接收安全策略更新数据并发 送给密钥管理单元100进行安全策略更新；安全策略更新数据包括更新后的 CK, RTP会话以及可选的KEK(用于更新SRTP组播会话接收方的密钥加密)。 安全策略更新所需的CK、 RTP会话信息以及可选的KEK由密钥管理单元100 提供。
密钥加密子单元302，用于从密钥管理单元100获取密钥加密密钥，对组 策更新数据加密/解密，具体密码参数(例如加密算法、加密密钥、完整性保 护算法，完整性保护密钥)由密钥管理单元IOO提供。
本发明实施例提供了安全策略的带内协商功能。可以解决带外方式安全策 略协商的诸多问题，如需要实现架构支持，内容和密钥不同步，信任终端不
明确，不利于防火墙穿越等。同时本发明实施例复用DTLS的代码，扩展点到 点DTLS+SRTP组播方案，降低系统的实现难度，更容易集成到资源有限的手 持移动设备中。
本发明实施例具有广泛的应用场景，例如，内容分发网络(Content Delivery Network, CDN)和大型多J 某体组4番会议(Multimedia Multicast Conference, MMC)。
CDN网络是建立在内容分发技术上的网络框架，利用放置在网络边缘节点 的緩存服务器，通过负载均衡算法实现资源的就近分配和就近访问。CDN网络 能够有效提高多媒体信息响应的速度，降低用户的接入延时。
如果CDN网络采用组播RTP协议作为多媒体的传输协议，则CDN中的核心 服务器将成为组播源，边缘节点将成为组播接收点，SRTP协议用于保护RTP 会话数据在传输过程中的安全性，本发明实施例用于提供RTP会话数据的安全 策略，为内容分发网络提供内容的加密保护和完整性保护，防止多媒体信息在 内容分发过程的盗看和插播。
在MMC应用场景中，会议的参与者数量可以很大(最大可以支持到百万 用户)，因而可以采用本发明实施例提供的组播方式作为RTP的承载协议，用 户可以通过加入特定的组播组，加入对应的组播会议。本发明实施例所提供的 方法及组播装置可以为组播信息的传送提供内容的加密保护和完整性保护，防 止会议内容在内容分发过程的各种安全性问题。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发
明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及 其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1.一种组播会话安全策略的分发方法，其特征在于，该方法包括安全实时传输组播会话发送方与安全实时传输组播会话接收方建立数据报传输层安全性会话后，接收安全实时传输组播会话接收方发送的安全策略请求数据，根据安全策略构建安全策略回应数据，将安全策略回应数据与组播会话的安全实时传输协议数据复用后，发送给安全实时传输组播会话接收方。
2、 如权利要求1所述的方法，其特征在于，所述安全策略请求数据由数 据报传输层安全性协议的记录层保护发送；所述安全策略回应数据，由数据报传输层安全性协议的记录层保护后，再 与所述组播会话的安全实时传输协议数据复用。
3、 如权利要求1所述的方法，其特征在于，该方法还包括当所述安全 实时传输组播会话发送方发现所述安全策略过期或者不再安全时，安全实时传 输组播会话发送方构建所述安全策略更新数据，利用组播信道发送给安全实时 传输组播会话接收方。
4、 如权利要求3所述的方法，其特征在于，所述利用组播信道发送给安 全实时传输组播会话接收方的步骤之前，该方法还包括对所述安全策略更新 数据进行加密。
5、 如权利要求3所述的方法，其特征在于，所述利用组播信道发送给安 全实时传输组播会话接收方的步骤之前，该方法还包括将所述安全策略更新 数据、安全实时传输协议数据与安全策略回应数据进行复用。
6、 一种组播发送装置，其特征在于，该装置包括第一密钥下拉单元，用于建立数据报传输层安全性会话，接收安全策略请 求数据，根据安全策略构建安全策略回应数据并发送；第一传输单元，用于发送组播会话的安全实时传输协议数据；第一复用/解复用单元，用于进行安全策略回应数据与安全实时传输协议数 据的复用并发送； 其中，所述第一复用/解复用单元还用于进行安全策略请求数据与所述安全 实时传输协议数据的解复用。
7、 如权利要求6所述的装置，其特征在于，所述装置进一步包括 第一密钥管理单元，用于存储安全策略；所述第一密钥下拉单元还用于从所述第一密钥管理单元获取构建安全策 略回应数据的安全策略。
8、 如权利要求7所述的装置，其特征在于，所述装置进一步包括 第一密钥推送单元，用于在安全策略中的内容密钥过期或者出现泄密风险时，更新并发送安全策略更新数据；所述第 一复用/解复用单元，还用于进行所述安全策略回应数据与安全实时 传输协议数据以及安全策略更新数据的复用并发送。
9、 如权利要求8所述的装置，其特征在于，所述第一密钥推送单元进一 步包括第一密钥推送子单元，用于从所述第一密钥管理单元获取安全策略更新数 据，更新并发送所述安全策略更新数据；第一密钥加密子单元，用于从所述第一密钥管理单元获取内容密钥加密密 钥，对所述安全策略更新数据加密。
10、 如权利要求8所述的装置，其特征在于，所述第一密钥管理单元进一 步包括第 一 内容密钥子单元，用于存储实时传输协议的安全策略中的内容密钥； 第一密钥加密密钥子单元，用于在安全策略更新过程中，存储内容密钥加 密密钥；第一会话信息子单元，用于存储安全实时传输协议会话信息。
11、 如权利要求6、 7或8所述的装置，其特征在于，所述第一密钥下拉 单元进一步包括第一密钥下拉子单元，用于接收安全策略请求数据，构建并发送安全策略回应lt据；第一安全传输子单元，用于利用数据报传输层安全性协议的记录层保护所 述第一密钥下拉子单元所发送的安全策略回应数据的私密性和完整性。
12、 一种组插4妄收装置，其特征在于，该装置包括第二密钥下拉单元，用于建立数据报传输层安全性会话，发送安全策略请 求数据；第二传输单元，用于将组播会话的安全实时传输协议数据发送给所述第二 复用/解复用单元；第二复用/解复用单元，用于执行安全策略请求数据与安全实时传输协议数 据的复用并发送；其中，所述第二复用/解复用单元还用于对接收的包含有安全策略回应数据 与安全实时传输协议数据的复用数据进行解复用；所述第二密钥下拉单元还用 于接收所述安全策略回应数据；所述第二传输单元还用于#^居安全策略回应数 据解密接收到的所述组播会话的安全实时传输协议数据。
13、 如权利要求12所述的装置，其特征在于，所述装置进一步包括 第二密钥管理单元，用于存储安全策略；所述第二密钥下拉单元接收到安全策略回应数据后，发送给所述第二密钥 管理单元存储。
14、 如权利要求13所述的装置，其特征在于，所述第二密钥管理单元进 一步包括第二内容密钥子单元，用于存储实时传输协议的安全策略中的内容密钥，并向所述第二传输单元装载安全策略中的内容密钥；第二密钥加密密钥子单元，用于存储接收到的内容密钥加密密钥； 第二会话信息子单元，用于存储安全实时传输协议会话信息，并向所述第二传输单元装载安全实时传输协议会话信息。
15、 如权利要求13所述的装置，其特征在于，所述装置进一步包括 第二密钥推送单元，用于接收安全策略更新数据并发送给所述第二密钥管理单元进行安全策略更新；所述第二复用/解复用单元还用于执行所述安全策略回应数据与安全实时 传输协议数据以及安全策略更新数据的解复用。
16、 如权利要求12~ 15任一所述的装置，其特征在于，所述密钥下拉单 元进一步包括第二密钥下拉子单元，用于发起安全策略请求数据；第二安全传输子单元，用于利用数据报传输层安全性协议的记录层保护所 述第二密钥下拉子单元所发送的安全策略请求数据的私密性和完整性；其中，所述第二密钥下拉子单元，还用于接收安全策略回应数据。
17、 一种组播装置，其特征在于，该装置包括 密钥管理单元，用于存储安全策略；密钥下拉单元，用于建立数据报传输层安全性会话，发送/接收安全策略请 求数据；接收/构建安全策略回应数据；复用/解复用单元，用于执行安全策略请求数据/安全策略回应数据与组播 会话的安全实时传输协议数据的复用与解复用；传输单元，用于发送/接收安全实时传输协议数据；以及根据安全策略解密 接收到的安全实时传输协议数据；其中，所述密钥下拉单元接收到安全策略回应数据后，发送给所述密钥管 理单元存储；所述密钥下拉单元从所述密钥管理单元获取构建安全策略回应数 据的安全策略。
18、 如权利要求17所述的装置，其特征在于，所述装置进一步包括 密钥推送单元，用于在安全策略中的内容密钥过期或者出现泄密风险时，更新并发送安全策略更新数据；所述复用/解复用单元，用于执行所述安全策略请求数据/安全策略回应数 据与安全实时传输协议数据以及安全策略更新数据的复用与解复用；其中，密钥推送单元还用于接收安全策略更新数据并发送给所述密钥管理 单元进行安全策略更新。
全文摘要
本发明公开了一种组播会话安全策略的分发方法及组播装置，通过SRTP组播会话接收方加入组播组，开始SRTP组播会话；SRTP组播会话接收方与SRTP组播会话发送方开始DTLS握手，建立DTLS会话；SRTP组播会话接收方与SRTP组播会话发送方进行安全策略的下拉过程；SRTP组播会话接收方安装安全策略。SRTP组播会话发送方在安全策略过期或安全策略存在泄密风险的情况下，可以启动安全策略推送过程，更新安全策略，下发新的安全策略。本发明实施例采用带内的方式完成安全策略的协商，解决了现有技术的密钥协商方案不能满足组播SRTP会话安全策略的安全协商要求的问题。
文档编号H04L12/18GK101370004SQ200710138750
公开日2009年2月18日 申请日期2007年8月16日 优先权日2007年8月16日
发明者旭 陈 申请人:华为技术有限公司