CN101232368A - 一种分配媒体流密钥的方法和多媒体子系统 - Google Patents

一种分配媒体流密钥的方法和多媒体子系统 Download PDF

Info

Publication number
CN101232368A
CN101232368A CNA2007100027165A CN200710002716A CN101232368A CN 101232368 A CN101232368 A CN 101232368A CN A2007100027165 A CNA2007100027165 A CN A2007100027165A CN 200710002716 A CN200710002716 A CN 200710002716A CN 101232368 A CN101232368 A CN 101232368A
Authority
CN
China
Prior art keywords
calling
key
application server
called
terminal
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
CNA2007100027165A
Other languages
English (en)
Other versions
CN101232368B (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.)
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 CN2007100027165A priority Critical patent/CN101232368B/zh
Priority to PCT/CN2008/070148 priority patent/WO2008089698A1/zh
Priority to EP08700805A priority patent/EP2124379B1/en
Priority to AT08700805T priority patent/ATE519289T1/de
Publication of CN101232368A publication Critical patent/CN101232368A/zh
Priority to US12/508,025 priority patent/US8204229B2/en
Application granted granted Critical
Publication of CN101232368B publication Critical patent/CN101232368B/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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

本发明提供一种分配媒体流密钥的方法和多媒体子系统，具体为：预先设置生成密钥的安全应用服务器，当主叫终端发起呼叫时，安全应用服务器根据呼叫请求消息判断主叫终端所属域与被叫终端所属域是否已签署密钥分发协议，如果已经签署，安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的同一个密钥分配给主叫终端和被叫终端；如果没有签署，安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥分配给自身所在一侧的终端。应用本发明方案，主叫终端和被叫终端自身并不生成密钥，而是由安全应用服务器生成密钥，可以大大降低端到端媒体流密钥协商的复杂度，便于媒体流加密业务的推广。

Description

一种分配媒体流密钥的方法和多媒体子系统
技术领域
本发明涉及媒体流加密技术，特别是涉及一种分配媒体流密钥的方法多媒体子系统。
背景技术
媒体流一般基于实时传输协议(RTP，Real-time Transport Protocol)进行传输，这里的所述的媒体流为音频媒体流、视频媒体流等。但由于RTP协议本身并不涉及安全问题，使媒体流在传输过程中存在泄密、被攻击等安全隐患。
为了加强媒体流在传输过程中的安全性，目前已提出多种生成和分配密钥的方法，即密钥协商方法。之后，终端可以利用分配的密钥实现媒体流的传输，达到安全传输媒体流的目的。
在现有技术中，密钥协商方法中有两种典型方法：一种是多媒体因特网密钥(MIKEY)公钥模式，另一种是MIKEY DH模式。
其中，MIKEY公钥模式的基本思想是：由主叫终端生成密钥和信封密钥，所述密钥用信封密钥进行加密，信封密钥再利用被叫终端证书的公钥进行加密，然后将加密后的密钥通过MIKEY协议发送到被叫终端，被叫终端解密后获得密钥，完成密钥协商过程。
在MIKEY公钥模式中，为了保障密钥协商过程的安全、顺利地进行，要求主叫终端和被叫终端之间进行时钟同步，并具备公钥基础设施(PKI)系统的支持。而实际应用中，实现时钟同步以及PKI系统支持比较复杂，不利于密钥协商的实现。比如：在电话会议中，存在多个需要传输媒体流的终端。如果要对多个终端的媒体流加密，则需要将多个终端进行时钟同步，这大大增加了密钥协商的困难。又比如：主叫终端和被叫终端为普通的移动终端，而由于移动终端数量大，将很难完成PKI系统中证书管理等工作，无法顺利进行密钥协商。
MIKEY DH模式的基本思想是：在主叫终端和被叫终端分别生成DH值，再利用MIKEY协议交换彼此的DH值，然后根据双方的DH值产生密钥。
MIKEY DH模式也需要进行时钟同步，而且实现MIKEY DH模式非常复杂，计算量大，对终端性能要求高，不利于密钥协商的实现。
另外，实际应用中，运营商为了安全机构满足合法监听的要求，需要获得媒体流中的密钥。而现有技术中，只有参与交互的终端才可以获得密钥，这里所述参与交互的终端可能为主叫和被叫两个终端，也可能为多个终端，任何参与交互之外的第三方都无法获得密钥，即无法满足合法监听的要求。
发明内容
有鉴于此，本发明的主要目的在于提供一种分配媒体流密钥的方法和多媒体子系统，可以在保证链路安全的条件下，避免时钟同步、PKI支持、证书管理等过程，减少生成密钥的复杂度，便于媒体流加密业务的推广。
为了达到上述第一个目的，本发明提出的技术方案为：
一种分配媒体流密钥的方法，预先设置生成密钥的安全应用服务器，当主叫终端发起呼叫时，该方法包括：
A、安全应用服务器根据呼叫请求消息判断主叫终端所属域与被叫终端所属域是否已签署密钥分发协议，如果已经签署，执行步骤B后退出本流程；否则执行步骤C；
B、安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的同一个密钥分配给主叫终端和被叫终端；
C、安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥分配给自身所在一侧的终端。
为了达到上述第二个目的，本发明提出的技术方案为：
一种多媒体子系统，至少包括主叫终端和被叫终端，该系统还包括：
安全应用服务器，用于根据主叫终端所属域与被叫终端所属域的签约情况确定加密方式，根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥发送给终端。
综上所述，本发明提出的一种分配媒体流密钥的方法和多媒体系统，由于主叫终端和被叫终端自身并不生成密钥，而是安全应用服务器生成密钥的，无需进行时钟同步，也无需PKI体系的支持，可以大大降低媒体流密钥协商的复杂度，便于媒体流加密业务的推广。
附图说明
图1是本发明的流程图；
图2是方法实施例一的消息流示意图；
图3是方法实施例二的消息流示意图；
图4是方法实施例三的消息流示意图；
图5是方法实施例四的消息流示意图；
图6是方法实施例五的消息流示意图；
图7是本发明系统基本结构示意图；
图8是系统实施例的基本结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。
本发明的基本思想是：根据主叫终端所属域和被叫终端所属域签署密钥分发协议的情况确定加密方式，如果签署了协议，就采用端到端加密协商方式获取相应的密钥，如果没有签署协议，就利用分段加密方式获取相应的密钥。
根据主叫侧开通加密业务的情况，可以将本发明分为两种类型，一种是主加侧将加密业务作为基本业务的类型，另一种是主叫侧将加密业务作为增值业务的类型。
对于主叫侧将加密业务作为基本业务的情况下，不管是采用端到端加密协商方法，还是采用分段加密方式，主叫侧安全应用服务器都将生成密钥，其方法可以如图1所示。
预先设置生成密钥的安全应用服务器，当主叫终端发起呼叫时，终端设备获取媒体流密钥的方法包括以下步骤：
步骤101：安全应用服务器根据呼叫请求消息判断主叫终端所属域与被叫终端所属域是否已签署密钥分发协议，如果已经签署，执行步骤102后退出本流程；否则执行步骤103；
呼叫请求消息可以携带有用户标识，安全应用服务器根据用户标识可以查询主叫终端运营商与被叫终端运营商签署密钥分发协议的相关信息。比如：如果签署了协议，可事先将签署密钥分发协议的相关信息设置为“已签署”，否则，设置为“未签署”。
步骤102：安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的同一个密钥分配给主叫终端和被叫终端；
本步骤是利用端到端加密协商方式获得相应的密钥，即：主叫终端和被叫终端在呼叫过程中协商生成密钥的加密能力信息，安全应用服务器根据双方协商确定的加密能力信息生成密钥，再将生成的密钥分别发送给主叫终端和被叫终端。在实现时，该方法可以具体为：
b1、被叫终端接收来自主叫终端的呼叫请求消息，所述呼叫请求消息携带有主叫终端的加密能力信息；
b2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，再返回携带有生成密钥的加密能力信息的呼叫响应消息；
b3、主叫侧安全应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥发送给主叫终端；
b4、主叫终端再向被叫终端发送呼叫相关消息，在发送所述呼叫相关消息的过程中，主叫侧安全应用服务器将生成的密钥携带于所述呼叫相关消息发送给被叫终端。
利用上述端到端加密协商方式后，主叫终端和被叫终端都可以获取密钥，在此后整个传输过程中，可以利用获取的密钥对媒体流进行加密传输。
步骤103：安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥分配给自身所在一侧的终端。
本步骤是利用分段加密方式获取相应的密钥，即：主叫侧和被叫侧分别生成各自的密钥，其实现方法可以为：
c1、主叫侧安全应用服务器记录来自主叫终端呼叫请求消息中的主叫终端加密能力信息；
c2、被叫终端在接收到呼叫请求后，返回携带有自身加密能力信息的呼叫响应消息，被叫侧安全应用服务器从呼叫响应消息中获取并记录被叫终端的加密能力信息；
c3、主叫侧安全应用服务器将根据主叫终端加密能力信息生成的密钥发送给主叫终端，并下发给主叫侧媒体流承载设备；
c4、被叫侧安全应用服务器将根据被叫终端加密能力信息生成的密钥发送给被叫终端，并将生成的密钥下发给被叫侧媒体流承载设备。
在利用分段加密协商的方式中，主叫终端、主叫侧媒体流承载设备、被叫侧媒体流承载设备和被叫终端都获取了密钥，在此后的媒体流传输过程中，主叫终端和主叫侧媒体流承载设备之间将传输经过加密的媒体流，被叫侧媒体流承载设备和被叫终端之间也将传输经过加密的媒体流，而主叫侧媒体流承载设备和被叫侧媒体流承载设备之间将传输明文的媒体流。
这里所述分段加密方式获取相应的密钥的方法是在被叫侧将加密业务作为基本业务的情况下的方法。如果被叫侧将加密业务作为增值业务，则在被叫终端接收呼叫请求之前，该方法还可以进一步包括：
被叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端是否已经签约，如果已经签约，则继续执行，即执行上述c2～c4的步骤；否则，执行步骤X；
所述步骤X为：在被叫终端返回呼叫响应消息过程中，主叫侧安全应用服务器将根据主叫终端加密能力信息生成的密钥发送给主叫终端，并下发给主叫侧媒体流承载设备。
这里，在步骤X中，由于只有主叫终端和主叫侧媒体流获取了密钥，在此后的媒体流传输过程中，只有主叫侧对媒体流进行加密，而被叫侧对媒体流进行明文传输。
上述是主叫侧将加密作为基本业务的情况，如果主叫侧将加密作为增值业务，并且在被叫侧将加密业务作为基本业务的情况下，可以在步骤101检查签署分发密钥协议之前，该方法进一步包括：
主叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则继续执行步骤101；否则，执行步骤Y；
所述步骤Y为：
y1、被叫终端接收来自主叫终端的呼叫请求消息，所述呼叫请求消息携带有主叫终端的加密能力信息；
y2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，返回携带有生成密钥的加密能力信息的呼叫响应消息；
y3、被叫侧安全应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥发送给主叫终端；
y4、主叫终端再向被叫终端返回呼叫相关消息，被叫侧安全应用服务器通过所述呼叫相关消息将生成的密钥发送给被叫终端。
这里，由于主叫终端和被叫终端都获取了密钥，在此后整个传输过程中，可以利用获取的密钥对媒体流进行加密传输。与主叫侧将加密业务作为基本业务不同的是，这里所述的端到端加密所利用的密钥是由被叫侧安全应用服务器生成的。
当然，步骤y1所述被叫终端接收到呼叫响应消息之前，主叫侧安全应用服务器还可以先根据呼叫请求消息判断出主叫终端所属域与被叫终端所属域已签署密钥分发协议，之后，呼叫请求消息才被发送给被叫终端。
如果被叫侧将加密业务作为增值业务，那么，在步骤y1所述被叫终端接收到呼叫请求消息之前，该方法还可以包括：被叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端已经签约。如果判断出被叫终端没有签约，也就是说，主叫侧和被叫侧都不支持加密业务，那么，主叫终端和被叫终端将不会获取密钥，并将按照现有技术实现呼叫流程。
不管主叫侧将加密业务作为基本业务，还是作为增值业务，这里所述的呼叫请求消息都是携带有加密能力信息的呼叫请求消息，即主叫终端主动要求进行加密。
实际应用中，主叫终端可以不支持加密或者不要求加密，发出的呼叫请求消息为不带加密能力信息的呼叫请求消息。在这种情况下，就可以先判断呼叫请求消息是否携带有加密能力信息，如果有，再继续执行；如果没有，则执行步骤Z；
所述步骤Z为：
z1、被叫终端接收到呼叫请求消息后，返回携带有加密能力信息的呼叫响应消息；
z2、被叫侧安全应用服务器从呼叫响应消息中获得并记录被叫终端的加密能力信息；
z3、当主叫终端接收到呼叫响应消息后，再向被叫终端发送呼叫相关消息，在发送的过程中，被叫侧安全应用服务器将根据加密能力信息生成的密钥通过呼叫相关消息发送给被叫终端，并下发给被叫侧媒体流承载设备。
由于只有被叫终端和被叫侧媒体流承载设备获取了密钥，在此后的媒体流传输过程中，只有被叫侧利用获取的密钥对媒体流进行加密传输，而主叫侧对媒体流进行明文传输。
这里，由于主叫终端发送的是不包含加密能力信息的呼叫请求，还可以在所述被叫终端接收到呼叫请求消息之前，由被叫侧安全应用服务器将事先保存的加密能力信息插入呼叫请求消息；这样，被叫终端返回呼叫响应消息之前，被叫终端就可以根据呼叫请求消息中的加密能力信息和自身加密能力信息，确定生成密钥的加密能力信息，并将确定生成密钥的加密能力信息添加到呼叫响应消息中。
另外，这里所述步骤Z是被叫侧将加密业务作为基本业务的情况。如果将加密业务作为增值业务，被叫终端接收到呼叫请求消息之前，被叫侧安全应用服务器还可以先查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端已经签约。当然，如果判断出被叫终端没有签约，则可以直接执行现有的呼叫流程，主叫终端和被叫终端都不会获取密钥。
实际应用中，所述呼叫流程中主叫终端和被叫终端之间交互的消息可以包括获取密钥状态标识，如果主叫终端/被叫终端没有获取密钥，则将发送给被叫终端/主叫终端消息中的获取密钥状态标识设置为未获取密钥标识；否则，设置为已获取密钥标识。通过获取密钥状态标识可以使呼叫双方将自身获取密钥的情况通知给对方。
实际应用中，本发明所述的安全应用服务器可以为IP多媒体子系统的应用服务器(IMS-AS)，可以为呼叫会话控制功能实体(CSCF)中的功能模块，也可以为第三方服务器。
如果安全应用服务器为IMS-AS，呼叫请求消息是主叫终端经过主叫侧IMS-AS和被叫侧IMS-AS发送给被叫终端的，那么路由呼叫请求消息的方法具体为：
主叫终端将呼叫请求消息发送给主叫侧S-CSCF；主叫侧S-CSCF根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧安全应用服务器；主叫侧安全应用服务器将呼叫请求消息通过主叫侧S-CSCF发送给被叫侧S-CSCF；被叫侧S-CSCF根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧安全应用服务器；被叫侧安全应用服务器再将呼叫请求消息转发给被叫终端。
为了更好地说明本发明方案，下面用较佳实施例进行详细描述。
方法实施例一
本实施例中，主叫侧和被叫侧都将加密业务作为基本业务，并且，主叫侧所属运营商和被叫侧所属运营商之间已经签署了分发密钥协议；所述安全应用服务器为IMS-AS，分为主叫侧IMS-AS和被叫侧IMS-AS，并由主叫侧IMS-AS生成密钥。
图2是本实施例的消息流示意图。如图2所示，本实施例包括以下步骤：
步骤201：主叫终端发起呼叫，将呼叫请求消息发送给主叫侧S-CSCF；
这里所述的呼叫请求消息就是会话初始协议(SIP)中的INVITE消息，可以采用四种方法将主叫终端的加密能力信息承载在INVITE消息中：第一种方法是承载在INVITE消息的会话描述协议(SDP)中；第二种方法是承载在INVITE消息中SIP主叫属性接收协商(Accept-contact)头域中；第三种方法是承载在INVITE消息中SIP的扩展协商域中；第四种方法是承载在INVITE消息中征求意见稿(RFC 4568)标准所定义的字段中。
这里所述的加密能力信息也可以称为加密能力声明，可以包括SRTP支持、加密算法的支持、密钥长度的支持等信息。前三种承载方式可以参见本申请人另一专利申请，此处不再赘述。
对于第四种承载方式，可以将加密能力信息承载到SDP的a字段中。另外，呼叫请求消息中还可以携带关于加密的安全前提，安全前提中可以包括指定加密方式的标识。在这种情况下，第四种承载方式的格式可以为：
m＝video 51372 RTP/SAVP 31
a＝curr:sec e2e none
a＝des:sec mandatory e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_80
inline:
a＝crypto:2 AES_CM_128_HMAC_SHA1_32
inline:
m＝audio 49170 RTP/SAVP 0
a＝curr:sec e2e none
a＝des:sec mandatory e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_32
inline:
a＝crypto:2 AES_CM_128_HMAC_SHA1_80
inline:
这里包括关于视频流和音频流的两个加密能力声明和安全前提，以关于视频流的为例，其中，“a＝curr:sec e2e none”和“a＝des:sec mandatory e2e sendrecv”就是安全前提，表示主叫终端期望强制的端到端接收和发送两个方面的媒体流加密，同时指出当前主叫终端还没有实现与媒体流加密有关的前提。另外，“inline”字段表示用于承载密钥。如果主叫终端还没有获取密钥，“inline”字段应该为空；如果网络侧生成了密钥并需要发送给主叫终端，那么，就可以将生成的密钥承载于返回主叫终端的消息中的“inline”字段中，主叫终端可以从“inline”字段中获取密钥。
实际应用中，由于存在被叫终端可能不支持加密的情况，为了保证呼叫能够成功，也可以在呼叫请求消息中包括不含加密信息的声明，即在上述声明后增加以下两个声明：
m＝video 51372 RTP/AVP 31
m＝audio 49170 RTP/AVP 0
这样，如果对方不支持加密，则可以按照现有技术完成呼叫过程。
步骤202～步骤203：主叫侧S-CSCF根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给主叫侧IMS-AS。
本实施例中，由于主叫侧将加密业务作为基本业务，那么这里所述的过滤准则可以是事先为用户提供的缺省过滤准则，其格式可以如表一所示：
表一
这样，就可以将呼叫请求消息触发给主叫侧IMS-AS处理，并且，在此后的呼叫过程中，主叫侧IMS-AS将处于呼叫的信令链路中，即所有与呼叫相关的消息都将经过主叫侧IMS-AS。
步骤204～步骤206：主叫侧IMS-AS判断出主叫终端所属域与被叫终端所属域已签署密钥分发协议，并将呼叫请求消息通过主叫侧S-CSCF发送给被叫侧S-CSCF。
如果呼叫请求消息中还携带有包括安全前提，并在安全前提中包括端到端加密标识，主叫侧IMS-AS根据呼叫请求就可以判断出这里一个要求端到端加密的呼叫请求消息。另外，由于本实施例由主叫侧IMS-AS生成密钥，为了将生成密钥的情况通知给被叫侧IMS-AS，主叫侧IMS-AS还可以将主叫侧生成密钥标识插入呼叫请求消息。
步骤207～步骤210：被叫侧S-CSCF根据事先获得的过滤准则，对接收到的呼叫请求消息进行过滤处理，并将携带有加密能力信息的呼叫请求消息转发给被叫侧IMS-AS，再通过被叫侧S-CSCF转发给被叫终端。
与主叫侧相似，本实施例中，被叫侧也是将加密业务作为基本业务，这里所述的过滤准则可以是事先为用户提供的缺省过滤准则，其格式如表二所示：
Figure A20071000271600181
表二
这样，就可以将呼叫请求消息触发给被叫侧IMS-AS处理，并且，在此后的呼叫过程中，被叫侧IMS-AS将处于呼叫的信令链路中，即所有与呼叫相关的消息都将经过被叫侧IMS-AS。
如果呼叫请求消息包括加密方式和生成密钥侧标识，被叫侧S-CSCF从呼叫请求消息就可以判断出该呼叫要求端到端加密方式，并且由主叫侧IMS-AS生成密钥。
步骤211～步骤216：被叫终端根据呼叫请求消息中主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，再向主叫侧IMS-AS返回携带有生成密钥的加密能力信息的呼叫响应消息。
本实施例中，被叫终端可以返回：
m＝video 31337 RTP/SAVP 31
a＝curr:sec e2e none
a＝des:sec mandatory e2e sendrecv
a＝conf:sec e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_80 CALLER-ALLOC-KEY
inline:
m＝audio 31399 RTP/SAVP 0
a＝curr:sec e2e none
a＝des:sec mandatory e2e sendrecv
a＝conf:sec e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_32 CALLER-ALLOC-KEY
inline:
在呼叫请求消息中包括有加密能力信息的和没有加密能力信息的两种呼叫请求的情况下，如果被叫终端不支持加密，将返回4xx错误消息，或者针对没有加密能力信息的呼叫请求返回呼叫响应消息，即实现普通的呼叫。
步骤217～步骤220：主叫侧IMS-AS根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥返回给主叫终端。
如果消息中包括安全前提，当主叫终端从呼叫响应消息中获取密钥后，还可以更改安全前提，同时向被叫终端发送确认信息。比如：
m＝video 51372 RTP/SAVP 31
a＝curr:sec e2e sendrecv
a＝des:sec mandatory e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_80 CALLER-ALLOC-KEY
inline:
m＝audio 49170 RTP/SAVP 0
a＝curr:sec e2e sendrecv
a＝des:sec mandatory e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_32 CALLER-ALLOC-KEY
inline:
其中，第二行和第七行粗体字部分就是更改后的前提。
步骤221～步骤229：主叫终端向被叫终端发送呼叫相关消息，在发送的过程中，主叫侧IMS-AS将生成的密钥携带于所述呼叫相关消息发送给被叫终端。
这里所述呼叫相关消息可以为确认消息(PRACK)或更新信息消息(UPDATE)等消息。
本实施例中，主叫侧IMS-AS可以由以下方式将密钥携带于消息中，即承载在inline字段中。比如：
m＝video 51372 RTP/SAVP 31
a＝curr:sec e2e sendrecv
a＝des:sec mandatory e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_80 CALLER-ALLOC-KEY
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj
m＝audio 49170 RTP/SAVP 0
a＝curr:sec e2e sendrecv
a＝des:sec mandatory e2e sendrecv
a＝conf:sec e2e sendrecv
a＝crypto:1 AES_CM_128_HMAC_SHA1_32 CALLER-ALLOC-KEY
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
其中，第五行和第十一行粗体就是携带的密钥。
当然，主叫终端和被叫终端之间还需要完成呼叫的其他过程，比如：当接收到PRACK消息后，被叫终端还需要向主叫终端返回200OK消息，呼叫流程的具体情况可以参见现有技术，此处不再赘述。
本实施例中的安全应用服务器是以IMS-AS为例进行说明的，实际应用中，安全应用服务器也可以是S-CSCF中的功能模块，或者为第三方服务器。在这种情况下，呼叫信令链路可以与现有技术中的信令链路相同，实现端到端加密的方法与本实施例相似，其区别在于：如果是S-CSCF中的功能模块，检查主叫终端所属域和被叫终端所属域是否签署协议、将主叫侧密钥生成侧标识插入呼叫请求消息、生成密钥等都可以直接由主叫侧S-CSCF完成；如果是第三方服务器，第三方服务器可以只负责生成密钥，检查主叫终端所属域和被叫终端所属域是否签署协议、将主叫侧密钥生成侧标识插入呼叫请求消息等可以由S-CSCF完成；或者，检查主叫终端所属域和被叫终端所属域是否签署协议、将主叫侧密钥生成侧标识插入呼叫请求消息、生成密钥等全部由第三方服务器完成，不管是哪种方法，都需要S-CSCF和第三方服务器之间确定交互的协议，所述交互的协议可以由应用本发明方案的用户自行确定。
方法实施例二
本实施例中，主叫侧和被叫侧都将加密业务作为基本业务，但主叫终端所属域和被叫终端所属域之间没有签署密钥分发协议；本实施例中，安全应用服务器为S-CSCF中的功能模块，即安全应用单元，但为了更好地说明流程，仍然将S-CSCF和安全应用单元分开叙述。
图3是本实施例的消息流示意图。如图3所示，本实施例包括以下步骤：
步骤301～步骤303与实施例一的步骤201～步骤203相似，其区别仅仅在于，主叫侧S-CSCF将呼叫请求消息发送给自身的安全应用单元处理。
步骤304～步骤306：主叫侧安全应用单元判断出主叫终端所属域与被叫终端所属域没有签署密钥分发协议，记录下呼叫请求消息中的主叫终端的加密能力信息后，再将呼叫请求消息发送给被叫侧S-CSCF。
与实施例一相似，如果呼叫请求消息中还携带有包括安全前提，并在安全前提中包括端到端加密标识，主叫侧安全应用单元根据呼叫请求就可以判断出这里一个要求端到端加密的呼叫请求消息。但由于主叫终端所属域与被叫终端所属域没有签署密钥分发协议，主叫侧安全应用单元则可以确定采用分段加密的方式。为了将加密方式通知给被叫侧，主叫侧安全应用单元还可以将端到端加密标识更改为分段加密标识。此后，被叫侧就可以根据该标识确定该呼叫请求要求进行分段加密。
如果不需要被叫终端的用户获取加密方式已经被更改过，被叫侧还可以将分段加密标识更改为端到端加密标识之后再发送给被叫终端。当然，这种情况下，当被叫终端返回消息时，也需要将其中的端到端加密标识又重新更改为分段加密标识。
实际应用中，在确定为分段加密方式后，如果终端具备解析标志能力，还可以提示用户此次会话不能完全保证通话的安全性。
另外，由于进行分段加密，主叫侧和被叫侧双方无需知道对方的加密能力信息，可以在确定采用分段加密的情况下，将呼叫请求消息中的与加密相关的信息删除。
如果网络侧采用哪种加密方式的情况并不需要报告给主叫终端，那么，在返回消息给主叫终端时，还可以将事先更改过的加密方式重新恢复为端到端加密。
307～步骤310与实施例一中的步骤207～步骤210相似，其区别仅仅在于，被叫侧S-CSCF将呼叫请求消息发送给自身的安全应用单元处理。
步骤311～步骤314：被叫终端在接收到呼叫请求消息后，返回携带有自身加密能力信息的呼叫响应消息，被叫侧安全应用服务器从呼叫响应消息中获取并记录被叫终端的加密能力信息。
步骤315～步骤321：被叫侧S-CSCF继续将呼叫响应消息发送给主叫终端，在发送的过程中，主叫侧安全应用单元将根据主叫终端加密能力信息生成的密钥携带于呼叫响应消息中发送给主叫终端，并下发给主叫侧媒体流承载设备。
本实施例中，主叫侧安全应用单元是在步骤317中根据步骤304记录的主叫终端加密能力信息生成密钥的，但在实际应用中，只要主叫侧安全应用单元获得了主叫终端得加密能力信息，任何时候都可以生成密钥，并不一定在步骤317生成。
另外，本实施例中，所述媒体流承载设备可以为MP。当主叫侧安全应用单元需要将生成的密钥下发给MP时，该方法为：
主叫侧安全应用单元通过主叫侧S-CSCF将携带有密钥的呼叫响应消息发送给主叫侧P-CSCF，主叫侧P-CSCF再将携带有密钥的报文发送给主叫侧MP。实际应用中，当主叫侧P-CSCF需要将密钥下发给主叫侧MP时，可以通过资源和接入控制子系统(RACS)将密钥下发给主叫侧MP。
比如：主叫侧P-CSCF发起资源预留过程，在资源预留过程中，主叫侧P-CSCF将生成的密钥发送给主叫侧RACS，主叫侧RACS再将密钥发送给主叫侧MP。当然，主叫侧P-CSCF也可以通过一个独立的下发密钥的过程将密钥发送给主叫侧MP，只要能够将密钥发送给主叫MP即可。
步骤322～步骤328：主叫终端向被叫终端发送呼叫相关消息，并在发送呼叫相关消息的过程中，被叫侧安全应用单元将根据被叫终端加密能力信息生成的密钥携带于呼叫相关消息中发送给被叫终端，并下发给被叫侧媒体流承载设备。
这里，所述呼叫相关消息可以为任何从主叫终端发送给被叫终端的消息，比如UPDATE消息、PRACK消息等。
与主叫侧生成密钥相似，本实施例中，被叫侧安全应用单元是在步骤323时，根据步骤313获取的被叫终端的加密能力信息生成密钥的。实际应用中，只要被叫侧安全应用单元获得的被叫终端的加密能力信息，在之后的任何是否生成密钥都可以，并不一定在步骤324中生成。
本实施例所述被叫侧将密钥下发给被叫侧媒体流承载设备的方法与主叫侧下发密钥给主叫侧媒体流承载设备的方法相似，此处不再赘述。
另外，本实施例是以安全应用单元为S-CSCF中的功能单元为例叙述，如果是P-CSCF中的功能单元，其方法与本实施例相似，只是在P-CSCF中生成密钥后，由P-CSCF将密钥发送给终端，并直接下发给媒体流承载设备即可，至于具体流程此处则不再详细描述。
方法实施三
本实施例中，主叫侧将加密业务作为基本业务，而被叫侧将加密作为增值业务，并且被叫终端未签约该加密业务，主叫终端所属域与被叫终端所属域之间没有签署分发密钥协议；本实施例中，安全应用服务器为IMS-AS。
图4是本实施例的消息流示意图。如图4所示，本实施例包括以下步骤：
步骤401～步骤410与实施例二中步骤301～步骤310相似，其区别在于，当被叫侧IMS-AS接收到呼叫请求消息时，还将查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端没有签约加密业务。
由于被叫终端没有签约加密业务，被叫侧将不会为被叫终端生成密钥。在这种情况下，被叫侧IMS-AS也可以将自身从信令链路中删除，此后的呼叫流程中的消息将不再经过被叫侧IMS-AS；或者被叫侧IMS-AS也可以不将自身从信令链路中删除，但只是转发消息的作用。
步骤411～步骤417：被叫终端向主叫终端返回呼叫响应消息，在返回呼叫响应消息过程中，主叫侧安全应用服务器将根据主叫终端加密能力信息生成的密钥发送给主叫终端，并下发给主叫侧媒体流承载设备。
此后主叫终端和被叫终端还需要完成呼叫流程中的其他部分，但被叫侧不会生成密钥，也不会将密钥发送给被叫终端和被叫侧媒体流承载设备，被叫侧部分的呼叫流程可以与现有技术相同。至于主叫侧如何将密钥下发给媒体流承载设备与实施例二相同，此处也不再赘述。
当呼叫流程结束后，只有主叫终端和主叫侧媒体流承载设备获得了密钥，媒体流在主叫终端和主叫侧媒体流承载设备是加密传输的，而在被叫侧是明文传输。
方法实施例四
本实施例中，主叫侧和被叫侧都将加密业务作为增值业务，主叫终端没有签约加密业务，而被叫终端签约了加密业务；主叫终端所属域和被叫终端所属域之间已经签署了密钥分发协议。
图5是本实施例的消息流示意图。如图5所示，本实施例包括以下步骤：
步骤501～步骤503与实施例一中的步骤201～步骤203相同，此处不再详细描述。
步骤504～步骤506：主叫侧IMS-AS查询事先设置的加密业务签约信息，根据用户标识判断出主叫终端没有签约，判断出主叫终端所属域与被叫终端所属域已签署密钥分发协议，再并将呼叫请求消息通过主叫侧S-CSCF发送给被叫侧S-CSCF。
与实施例一相似，如果呼叫请求消息中携带有安全前提，所属安全前提中包括端到端加密标识，主叫侧IMS-AS根据呼叫请求就可以判断出这是一个要求端到端加密的呼叫请求消息。由于主叫终端没有签约业务，主叫侧将不会为主叫终端生成密钥，为了将此情况通知给被叫侧，主叫侧IMS-AS可以将被叫侧生成密钥标识插入呼叫请求消息。
步骤507～步骤510与实施例一中的步骤207～步骤210相似，其区别在于，当被叫侧IMS-AS接收到呼叫请求消息后，将查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端已经签约。
当然，如果呼叫请求消息还包括安全前提等信息，主叫侧IMS-AS还可以根据呼叫请求消息确定加密方式为端到端加密，并且密钥由被叫侧安全应用服务器生成。
实际应用中，如果被叫侧IMS-AS判断出被叫终端没有签约加密业务，则可以将自身从链路中删除，并将无密钥生成标识插入消息中。此后，当主叫侧IMS-AS从呼叫响应消息中获取无密钥生成标识，就可以也将自身从信令链路中删除。
步骤511～步骤513：被叫终端根据呼叫请求消息中主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，再向被叫侧IMS-AS返回携带有生成密钥的加密能力信息的呼叫响应消息。
步骤514：被叫侧IMS-AS根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥携带于呼叫响应消息中。
步骤515～步骤520与实施例一中步骤214～步骤220相似，其区别在于，当主叫侧IMS-AS接收到呼叫响应消息时，不会再生成密钥，而是直接转发出去即可。
步骤521～步骤529与实施例一步骤221～步骤229相似，其区别在于，当主叫侧IMS-AS接收到呼叫相关消息时，将不会将密钥携带于呼叫相关消息中，而是后续过程中，由被叫侧将密钥携带于呼叫相关消息中发送给被叫终端。
方法实施例五
本实施例中，主叫终端发起的呼叫请求消息不携带加密能力信息，即不要求加密；实际应用中，终端可以为用户提供“加密”、“不加密”、“自动协商是否加密”等选项，终端根据用户的选择决定是否生成携带有加密声明的呼叫请求消息。
本实施例中，被叫侧将加密业务作为增值业务，并且被叫终端已经签约该加密业务；本实施例中，安全应用服务器为S-CSCF中的一个功能单元，并且为了叙述简便，在示意图不单独表示安全应用服务器。
图6是本实施例的消息流示意图。如图6所示，本实施例包括以下步骤：
步骤601～步骤603：主叫终端将呼叫请求消息发送给主叫侧S-CSCF，主叫侧S-CSCF直接将呼叫请求消息转发给被叫侧S-CSCF；
步骤604～步骤606：被叫侧S-CSCF将加密能力信息插入呼叫请求消息，再转发给被叫终端。
步骤607：被叫终端根据呼叫请求消息中的加密能力信息和自身加密能力信息，确定生成密钥的加密能力信息，并将确定生成密钥的加密能力信息添加到呼叫响应消息中。
步骤608～步骤609：被叫终端将呼叫请求消息返回给被叫侧S-CSCF，被叫侧S-CSCF中的安全应用单元根据呼叫响应消息中的加密能力信息生成密钥。
步骤610～步骤612：被叫侧S-CSCF继续向主叫终端返回呼叫响应消息。
实际应用中，被叫侧S-CSCF还可以将之前插入的加密能力信息删除，向主叫终端返回的是一条普通的呼叫响应消息。
步骤613～步骤：主叫终端向被叫终端发送呼叫相关消息，在发送的过程中，被叫侧S-CSCF将生成的密钥携带于呼叫相关消息中发送给被叫终端，并下发给媒体流承载设备。
针对本发明提出的方法，本发明还提出一种多媒体子系统。
图7是本发明所述的系统基本结构示意图，该系统至少包括主叫终端701、安全应用服务器702、被叫终端703。其中，所述安全应用服务器702用于根据主叫终端所属域与被叫终端所属域的签约情况确定加密方式，根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥发送给终端。
另外，本发明所述的安全应用服务器702可以为IMS-AS，或者为CSCF的功能模块，或者为第三方服务器。
系统实施例一
图8是本发明系统实施例一的基本结构图。如图8所示，由于呼叫过程中同时涉及主叫侧和被叫侧，安全应用服务器702可以为主叫侧安全应用服务器和被叫侧安全应用服务器，本实施例还包括：主叫终端701、主叫侧S-CSCF704、被叫侧S-CSCF705、被叫终端703。
其中，主叫终端701用于发起呼叫，并从呼叫流程中获取从主叫侧安全应用服务器或被叫侧安全应用服务器返回的密钥；
安全应用服务器702生成密钥并将密钥发送给终端；
主叫侧S-CSCF704和被叫侧S-CSCF转发呼叫流程中的消息，并将携带有加密能力信息的呼叫请求消息发送给对应的安全应用服务器。
实际应用中，系统中还包括主叫侧P-CSCF706、被叫侧P-CSCF707、主叫侧媒体流承载设备708、被叫侧媒体流承载设备709。其中，
主叫侧P-CSCF706用于转发呼叫消息，并将获得的密钥发送给主叫侧媒体流承载设备708；被叫侧P-CSCF706用于转发呼叫消息，并将获得的密钥发送给被叫侧媒体流承载设备709。
实际应用中，安全应用服务器702可以为S-CSCF中的功能模块，或者为P-CSCF中的功能模块，或者为IMS-AS，或者为第三方服务器。
当然，图8仅仅是一个系统基本结构图，每一个实体的功能与终端获取密钥的方式相关，此处不再赘述。
本发明是以含有IMS的网络，并且在IMS网络中信令链路可以提供安全保障的情况为例进行说明的。实际应用中，还可以将本发明方法应用于其他类型的网络中，如：基于软交换的下一代网络，其方法与本发明类似，此处不再一一列举。
应用本发明方案，主叫终端和被叫终端自身不生成密钥，而是由安全应用服务器生成密钥，无需进行时钟同步，也无需PKI体系的支持，可以大大降低媒体流密钥协商的复杂度，便于媒体流加密业务的推广。进一步地，如果采用端到端加密，可以从安全应用服务器中获取密钥，从而满足合法监听的实际需求；如果采用分段加密，由于主叫侧媒体流承载设备和被叫侧媒体流承载设备之间采用明文传输，也可以满足合法监听的实际需求。
综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种分配媒体流密钥的方法，其特征在于，预先设置生成密钥的安全应用服务器，当主叫终端发起呼叫时，该方法包括：
A、安全应用服务器根据呼叫请求消息判断主叫终端所属域与被叫终端所属域是否已签署密钥分发协议，如果已经签署，执行步骤B后退出本流程；否则执行步骤C；
B、安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的同一个密钥分配给主叫终端和被叫终端；
C、安全应用服务器根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥分配给自身所在一侧的终端。
2.根据权利要求1所述的方法，其特征在于，步骤B所述安全应用服务器为主叫侧安全应用服务器，所述步骤B具体为：
b1、被叫终端接收主叫终端的呼叫请求消息，所述呼叫请求消息携带有主叫终端的加密能力信息；
b2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，再返回携带有生成密钥的加密能力信息的呼叫响应消息；
b3、主叫侧安全应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥发送给主叫终端；
b4、主叫终端再向被叫终端发送呼叫相关消息，主叫侧安全应用服务器将生成的密钥携带于所述呼叫相关消息发送给被叫终端。
3.根据权利要求2所述的方法，其特征在于，所述呼叫请求消息中携带有端到端加密标识，在步骤b1所述被叫终端接收到呼叫请求消息之前，该方法进一步包括：
主叫侧安全应用服务器将主叫侧生成密钥标识携带于呼叫请求消息中，被叫侧安全应用服务器根据所述呼叫请求消息确定加密方式为端到端加密，并确定密钥由主叫侧安全应用服务器生成。
4.根据权利要求1所述的方法，其特征在于，步骤C所述安全应用服务器为主叫侧安全应用服务器和被叫侧安全应用服务器，所述步骤C具体为：
c1、主叫侧安全应用服务器记录来自主叫终端呼叫请求消息中的主叫终端加密能力信息；
c2、被叫终端在接收到呼叫请求后，返回携带有自身加密能力信息的呼叫响应消息，被叫侧安全应用服务器从呼叫响应消息中获取并记录被叫终端的加密能力信息；
c3、主叫侧安全应用服务器将根据主叫终端加密能力信息生成的密钥发送给主叫终端，并下发给主叫侧媒体流承载设备；
c4、被叫侧安全应用服务器将根据被叫终端加密能力信息生成的密钥发送给被叫终端，并将生成的密钥下发给被叫侧媒体流承载设备。
5.根据权利要求4所述的方法，其特征在于，所述媒体流承载设备为媒体代理MP，步骤c3所述主叫侧安全应用服务器将生成的密钥下发给主叫侧MP的方法为：
主叫侧安全应用服务器将生成的密钥通过主叫侧呼叫会话控制功能实体CSCF发送给主叫侧MP；
步骤c4所述被叫侧安全应用服务器将密钥下发给被叫侧MP的方法为：
被叫侧安全应用服务器将生成的密钥通过被叫侧CSCF将密钥发送给被叫侧MP。
6.根据权利要求4所述的方法，其特征在于，所述被叫终端接收到呼叫请求之前，该方法进一步包括：
被叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端是否已经签约，如果已经签约，则继续执行；否则，执行步骤X；
所述步骤X具体为：
在被叫终端返回呼叫响应消息过程中，主叫侧安全应用服务器将根据主叫终端加密能力信息生成的密钥发送给主叫终端，并下发给主叫侧媒体流承载设备。
7.根据权利要求4所述的方法，其特征在于，所述呼叫请求消息携带有端到端加密标识，步骤c1进一步包括：主叫侧安全应用服务器将端到端加密标识更改为分段加密标识；
步骤c2所述被叫终端接收呼叫请求之前，该方法进一步包括：被叫侧安全应用服务器根据呼叫请求消息确定加密方式为分段加密。
8.根据权利要求7所述的方法，其特征在于，所述呼叫响应消息携带有分段加密标识，所述步骤c3进一步包括：
主叫侧安全应用服务器将分段加密标识恢复为端到端加密标识。
9.根据权利要求1所述的方法，其特征在于，所述步骤A进一步包括：
主叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断主叫终端是否已经签约，如果已经签约，则继续执行；否则，执行步骤Y；
所述步骤Y为：
y1、被叫终端接收来自主叫终端的呼叫请求消息，所述呼叫请求消息携带有主叫终端的加密能力信息；
y2、被叫终端根据主叫终端的加密能力信息和自身的加密能力信息，确定生成密钥的加密能力信息，返回携带有生成密钥的加密能力信息的呼叫响应消息；
y3、被叫侧安全应用服务器根据呼叫响应消息中的加密能力信息生成密钥，并将生成的密钥发送给主叫终端；
y4、主叫终端再向被叫终端返回呼叫相关消息，被叫侧安全应用服务器通过所述呼叫相关消息将生成的密钥发送给被叫终端。
10.根据权利要求9所述的方法，其特征在于，步骤y1所述被叫终端接收到呼叫响应消息之前，该方法进一步包括：
主叫侧安全应用服务器根据呼叫请求消息判断出主叫终端所属域与被叫终端所属域已签署密钥分发协议。
11.根据权利要求9所述的方法，其特征在于，所述呼叫请求消息携带有端到端加密标识，步骤y1所述被叫终端接收到呼叫请求消息之前，该方法进一步包括：
主叫侧安全应用服务器将被叫侧生成密钥标识携带于呼叫请求消息中，被叫侧安全应用服务器根据呼叫请求消息确定加密方式为端到端加密，并且密钥由被叫侧安全应用服务器生成。
12.根据权利要求9所述的方法，其特征在于，步骤y1所述被叫终端接收到呼叫请求消息之前，该方法进一步包括：
被叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端已经签约。
13.根据权利要求9所述的方法，其特征在于，所述主叫侧安全应用服务器查询加密业务签约信息之前，该方法进一步包括：
主叫侧安全应用服务器判断呼叫请求消息是否包含加密能力信息，如果有，则继续执行；否则，执行步骤Z；
所述步骤Z为：
z1、被叫终端接收到呼叫请求消息后，返回携带有加密能力信息的呼叫响应消息；
z2、被叫侧安全应用服务器从呼叫响应消息中获得并记录被叫终端的加密能力信息；
z3、当主叫终端接收到呼叫响应消息后，再向被叫终端发送呼叫相关消息，在发送的过程中，被叫侧安全应用服务器将根据加密能力信息生成的密钥通过呼叫相关消息发送给被叫终端，并下发给被叫侧媒体流承载设备。
14.根据权利要求13所述的方法，其特征在于，步骤z1所述被叫终端接收到呼叫请求消息之前，该方法进一步包括：被叫侧安全应用服务器将加密能力信息插入呼叫请求消息；
步骤z1所述被叫终端返回呼叫响应消息之前，该方法进一步包括：被叫终端根据呼叫请求消息中的加密能力信息和自身加密能力信息，确定生成密钥的加密能力信息，并将确定生成密钥的加密能力信息添加到呼叫响应消息中。
15.根据权利要求13所述的方法，其特征在于，步骤z1被叫终端接收到呼叫请求消息之前，该方法进一步包括：
被叫侧安全应用服务器查询事先设置的加密业务签约信息，根据用户标识判断出被叫终端已经签约。
16.根据权利要求1所述的方法，其特征在于，所述呼叫流程中主叫终端和被叫终端之间交互的消息包括获取密钥状态标识，该方法进一步包括：
如果主叫终端/被叫终端没有获取密钥，则将发送给被叫终端/主叫终端消息中的获取密钥状态标识设置为未获取密钥标识；否则，设置为已获取密钥标识。
17.一种多媒体子系统，至少包括主叫终端和被叫终端，其特征在于，该系统还包括：
安全应用服务器，用于根据主叫终端所属域与被叫终端所属域的签约情况确定加密方式，根据在呼叫过程中获得的加密能力信息生成密钥，并将生成的密钥发送给终端。
18.根据权利要求17所述的系统，其特征在于，所述安全应用服务器为多媒体子系统应用服务器IMS-AS，或者为呼叫会话控制功能实体CSCF的功能模块，或者为第三方服务器。
CN2007100027165A 2007-01-23 2007-01-23 一种分配媒体流密钥的方法和多媒体子系统 Expired - Fee Related CN101232368B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN2007100027165A CN101232368B (zh) 2007-01-23 2007-01-23 一种分配媒体流密钥的方法和多媒体子系统
PCT/CN2008/070148 WO2008089698A1 (fr) 2007-01-23 2008-01-21 Procédé et système permettant de distribuer des clés secrètes du flux multimédia
EP08700805A EP2124379B1 (en) 2007-01-23 2008-01-21 A method and system for distributing secret keys of media stream
AT08700805T ATE519289T1 (de) 2007-01-23 2008-01-21 Verfahren und system zum verteilen von geheimschlüsseln eines medienstroms
US12/508,025 US8204229B2 (en) 2007-01-23 2009-07-23 Method and system for distributing key of media stream

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2007100027165A CN101232368B (zh) 2007-01-23 2007-01-23 一种分配媒体流密钥的方法和多媒体子系统

Publications (2)

Publication Number Publication Date
CN101232368A true CN101232368A (zh) 2008-07-30
CN101232368B CN101232368B (zh) 2011-06-01

Family

ID=39644138

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007100027165A Expired - Fee Related CN101232368B (zh) 2007-01-23 2007-01-23 一种分配媒体流密钥的方法和多媒体子系统

Country Status (5)

Country Link
US (1) US8204229B2 (zh)
EP (1) EP2124379B1 (zh)
CN (1) CN101232368B (zh)
AT (1) ATE519289T1 (zh)
WO (1) WO2008089698A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011131051A1 (zh) * 2010-04-19 2011-10-27 中兴通讯股份有限公司 一种安全通信协商方法和装置
CN103139769A (zh) * 2011-11-30 2013-06-05 大唐联诚信息系统技术有限公司 一种无线通信方法及网络子系统
CN104468634A (zh) * 2014-12-31 2015-03-25 大唐移动通信设备有限公司 一种呼叫建立方法、终端和安全as
CN104753869A (zh) * 2013-12-30 2015-07-01 北京大唐高鸿软件技术有限公司 基于sip协议的通话加密方法
CN109076631A (zh) * 2016-04-25 2018-12-21 株式会社Ntt都科摩 交换机以及通信方法
CN109462480A (zh) * 2018-11-08 2019-03-12 南京控维通信科技有限公司 基于rsa与aes的卫星通信系统加密方法
CN111404865A (zh) * 2019-01-02 2020-07-10 中国移动通信有限公司研究院 Ims系统加密通话方法、网络设备、终端及系统
CN114258018A (zh) * 2021-11-12 2022-03-29 中国南方电网有限责任公司 密钥管理方法、装置、计算机设备及存储介质
CN115022024A (zh) * 2022-05-31 2022-09-06 中国电信股份有限公司 用于加密通话的方法及装置、存储介质及电子设备

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100100134A (ko) * 2009-03-05 2010-09-15 한국전자통신연구원 네트워크 로봇 서비스를 위한 보안 서비스 방법 및 장치
CN101729249B (zh) * 2009-12-21 2011-11-30 西安西电捷通无线网络通信股份有限公司 用户终端之间安全连接的建立方法及系统
WO2013104071A1 (en) 2012-01-12 2013-07-18 Research In Motion Limited System and method of lawful access to secure communications
CA2860866C (en) 2012-01-12 2020-06-23 Blackberry Limited System and method of lawful access to secure communications
CA2860990C (en) 2012-01-12 2020-06-16 Blackberry Limited System and method of lawful access to secure communications
US10033992B1 (en) 2014-09-09 2018-07-24 Google Llc Generating a 3D video of an event using crowd sourced data
EP3351002A1 (en) * 2015-10-14 2018-07-25 ARRIS Enterprises LLC High definition secure playback with downloadable drm for android platforms
CN118694527A (zh) * 2024-08-28 2024-09-24 中电信量子信息科技集团有限公司 信息保护方法、通信方法、网络设备、通信系统和存储介质

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001026322A2 (en) * 1999-10-05 2001-04-12 Nortel Networks Limited Key exchange for a network architecture
FI20001512A (fi) * 2000-06-26 2001-12-27 Nokia Corp Salaamattoman käyttäjäliikenteen kontrollointi
US8046581B2 (en) * 2002-03-04 2011-10-25 Telespree Communications Method and apparatus for secure immediate wireless access in a telecommunications network
US7792527B2 (en) * 2002-11-08 2010-09-07 Ntt Docomo, Inc. Wireless network handoff key
EP1665855B1 (en) * 2003-09-12 2007-11-07 NTT DoCoMo INC. Seamless handover in heterogeneous network
WO2005078988A1 (en) * 2004-02-11 2005-08-25 Telefonaktiebolaget Lm Ericsson (Publ) Key management for network elements
US7546459B2 (en) * 2004-03-10 2009-06-09 Telefonaktiebolaget L M Ericsson (Publ) GSM-like and UMTS-like authentication in a CDMA2000 network environment
CN100512103C (zh) * 2004-04-07 2009-07-08 华为技术有限公司 一种端到端加密通信的密钥分发方法
CN1985495A (zh) * 2004-07-15 2007-06-20 皇家飞利浦电子股份有限公司 用于无线网络的安全系统
US7464267B2 (en) * 2004-11-01 2008-12-09 Innomedia Pte Ltd. System and method for secure transmission of RTP packets
CN100574185C (zh) 2005-01-07 2009-12-23 华为技术有限公司 在ip多媒体业务子系统网络中保障媒体流安全性的方法
CN100466805C (zh) * 2005-02-05 2009-03-04 华为技术有限公司 一种端到端加密语音通信的方法
JP4715239B2 (ja) * 2005-03-04 2011-07-06 沖電気工業株式会社 無線アクセス装置、無線アクセス方法及び無線ネットワーク
US20090282238A1 (en) * 2005-05-16 2009-11-12 Guillaume Bichot Secure handoff in a wireless local area network
US7986940B2 (en) * 2007-07-05 2011-07-26 Azurewave Technologies, Inc. Automatic wireless network linking method with security configuration and device thereof

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011131051A1 (zh) * 2010-04-19 2011-10-27 中兴通讯股份有限公司 一种安全通信协商方法和装置
CN103139769A (zh) * 2011-11-30 2013-06-05 大唐联诚信息系统技术有限公司 一种无线通信方法及网络子系统
CN103139769B (zh) * 2011-11-30 2016-05-11 大唐联诚信息系统技术有限公司 一种无线通信方法及网络子系统
CN104753869A (zh) * 2013-12-30 2015-07-01 北京大唐高鸿软件技术有限公司 基于sip协议的通话加密方法
CN104468634A (zh) * 2014-12-31 2015-03-25 大唐移动通信设备有限公司 一种呼叫建立方法、终端和安全as
CN104468634B (zh) * 2014-12-31 2018-11-30 大唐移动通信设备有限公司 一种呼叫建立方法、终端和安全as
CN109076631A (zh) * 2016-04-25 2018-12-21 株式会社Ntt都科摩 交换机以及通信方法
US11350287B2 (en) 2016-04-25 2022-05-31 Ntt Docomo, Inc. Switch and communication method
CN109462480A (zh) * 2018-11-08 2019-03-12 南京控维通信科技有限公司 基于rsa与aes的卫星通信系统加密方法
CN109462480B (zh) * 2018-11-08 2021-06-11 南京控维通信科技有限公司 基于rsa与aes的卫星通信系统加密方法
CN111404865A (zh) * 2019-01-02 2020-07-10 中国移动通信有限公司研究院 Ims系统加密通话方法、网络设备、终端及系统
CN114258018A (zh) * 2021-11-12 2022-03-29 中国南方电网有限责任公司 密钥管理方法、装置、计算机设备及存储介质
CN114258018B (zh) * 2021-11-12 2024-04-09 中国南方电网有限责任公司 密钥管理方法、装置、计算机设备及存储介质
CN115022024A (zh) * 2022-05-31 2022-09-06 中国电信股份有限公司 用于加密通话的方法及装置、存储介质及电子设备
CN115022024B (zh) * 2022-05-31 2023-09-29 中国电信股份有限公司 用于加密通话的方法及装置、存储介质及电子设备

Also Published As

Publication number Publication date
US20090279705A1 (en) 2009-11-12
WO2008089698A1 (fr) 2008-07-31
EP2124379A1 (en) 2009-11-25
EP2124379B1 (en) 2011-08-03
US8204229B2 (en) 2012-06-19
EP2124379A4 (en) 2010-07-28
CN101232368B (zh) 2011-06-01
ATE519289T1 (de) 2011-08-15

Similar Documents

Publication Publication Date Title
CN101232368B (zh) 一种分配媒体流密钥的方法和多媒体子系统
KR101367038B1 (ko) 키 교환 시스템 및 시스템 조작 방법
EP2426852B1 (en) Method and system for implementing secure forking calling session in ip multi-media subsystem
CN101379802B (zh) 在媒体服务器和用户设备之间以加密方式传输媒体数据的方法和装置
CN101175074A (zh) 一种实现端到端媒体流密钥协商的方法和系统
CN104683098B (zh) 一种保密通信业务的实现方法、设备及系统
CN101420413A (zh) 会话密钥协商方法、网络系统、认证服务器及网络设备
CN101222320B (zh) 一种媒体流安全上下文协商的方法、系统和装置
CN1983921B (zh) 一种端到端媒体流安全的实现方法及系统
CN101227272A (zh) 一种获取媒体流保护密钥的方法和系统
CN107872462B (zh) 视频会议呼叫方法及装置
CN108833943A (zh) 码流的加密协商方法、装置及会议终端
CN111404865A (zh) Ims系统加密通话方法、网络设备、终端及系统
CN115589292A (zh) 实现端到端VoIP一话多密的加密通话方法及系统
CN101222612A (zh) 一种安全传输媒体流的方法和系统
CN102025485B (zh) 密钥协商的方法、密钥管理服务器及终端
CN115589288B (zh) 基于量子密钥预充注实现端到端VoIP加密通信方法
US11218515B2 (en) Media protection within the core network of an IMS network
EP2266251B1 (en) Efficient multiparty key exchange
CN100583733C (zh) 实现媒体流安全的方法及通信系统
CN105763571A (zh) 基于sip的非对称语音加密
WO2012174843A1 (zh) 一种实现端到端安全的密钥协商方法及系统
Sankar et al. Implementation and integration of efficient ECDH key exchanging mechanism in software based VoIP network
WO2008083620A1 (fr) Procédé, système et appareil pour une négociation de contexte de sécurité de flux multimédia

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

Termination date: 20220123