CN101141251B - 通信系统中消息加密签名的方法及系统和设备 - Google Patents
通信系统中消息加密签名的方法及系统和设备 Download PDFInfo
- Publication number
- CN101141251B CN101141251B CN 200610153501 CN200610153501A CN101141251B CN 101141251 B CN101141251 B CN 101141251B CN 200610153501 CN200610153501 CN 200610153501 CN 200610153501 A CN200610153501 A CN 200610153501A CN 101141251 B CN101141251 B CN 101141251B
- Authority
- CN
- China
- Prior art keywords
- message
- content
- terminal
- service equipment
- encryption
- 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.)
- Expired - Fee Related
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/0825—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) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及通信领域,公开了一种通信系统中消息加密签名的方法及系统和设备,使得终端进行加密和签名时的成本、负荷和呼叫时延得以减少。本发明中,终端为待发送的消息生成内容密钥,将所生成的内容密钥发送到公钥服务设备,由公钥服务设备使用需要知道该消息内容的实体的公钥对该内容密钥加密,终端仅使用该内容密钥对该消息的内容加密,之后,将加密后的消息和经公钥加密的内容密钥向对端终端发送。终端在对消息的内容加密之前,将消息的内容发送给公钥服务设备,由公钥服务设备使用其私钥对消息的内容进行签名。
Description
技术领域
本发明涉及通信领域,特别涉及通信系统中信息的加密传输技术。
背景技术
会话初始化协议(Session Initiation Protocol,简称“SIP”)是互联网工程任务组(INTERNET ENGINEERING TASK FORCE,简称“IETF”)制定的多媒体通信系统体系中的核心协议,作为下一代网络(Next GenerationNetwork,简称“NGN”)中的重要协议,主要用于完成多媒体会话控制功能。SIP协议目前被认为是下一代基于网间互联协议(Internet Protocol,简称“IP”)的多媒体通信网络的核心协议之一,而第三代合作伙伴项目(3rdGeneration Partnership Project,简称“3GPP”)也已经确定采用SIP协议作为第三代移动通信(The Third Generation,简称“3G”)全IP阶段的多媒体域会话控制协议。
由于IP网本身的安全性问题以及网络的复杂性,SIP信令作为一种在IP网上传输的信令,其安全性是一个至关重要的问题。SIP信令的安全性问题包括保证信息的机密性和完整性,防止重放攻击和信息欺骗,提供会话中对参与者的鉴别,防止拒绝服务(Deny of Service,简称“DoS”)攻击、应用的安全性等。
将信令进行完全加密将为信令的机密性提供最好的保护,同时还可以保证信息不会被恶意中间媒介修改。然而,在实际应用中,SIP请求和响应不能在端到端的用户之间完全加密,因为在大多数网络体系结构中,信息头域(如Request-URI、Route、和Via),对服务器来说必须是可见的,只有这 样,SIP请求和响应才能够正确地路由。同时,代理服务器需要修改消息的某些参数(如增加Via头域值),因此,SIP用户代理(User agent,简称“UA”)必须开放部分信息给代理服务器。另外,SIP的实体之间(如UA和UA之间)还需要相互鉴别。SIP本身借鉴了超文本传输协议(Hyper Text TransferProtocol,简称“HTTP”)的模型,在安全性上,也重用了HTTP和简单邮件传送协议(Simple Mail Transfer Protocol,简称“SMTP”)的一些安全模型,利用消息头和消息体为多媒体会话提供点到点或端到端的安全机制。
IETF RFC3261中给出了SIP中实现安全性的几种方案:
(1)传输层和网络层安全。两种流行的方案是传输层安全(TransportLayer Security,简称“TLS”)和网际协议安全(Internet Protocol Security,简称“IPSec”)。
(2)SIPS URI方案。SIPS是指安全SIP,这种方案遵循SIP URI的语法格式,但是提供了一些措施使得数据可以安全到达指定的资源。SIPS URI方案中指定了传输层必须是TLS。SIPS URI方案通过逐跳的安全和服务器之间的相互信任模型来保证安全性。SIPS URI表示为:sips:aliceAtlanta.com;transport=tcp。
(3)HTTP Digest认证。HTTP认证提供了挑战(challenge)的能力,依靠401和407响应以及头域运送挑战和信任状。HTTP摘要认证方案不用经过较大的修改就可以应用在SIP中,提供了重放保护和单向认证(在3GPP中,HTTP被扩展为HTTP AKA-Digest(RFC3310),可以提供双向认证)。
(4)安全/多用途Internet邮件扩展(Secure/Multipurpose Internet MailExtensions,简称“S/MIME”)是一种端到端的加密。端到端地将SIP消息完全加密将保证机密性,但是在实际中是不实用的,因为网络中间媒介(如代理服务器)需要读某些消息头域来保证消息正确的路由,如果这些中间媒介被排除在安全框架之外,SIP消息将不能进行正确的路由传送。但是,SIP UA可以通过使用S/MIMES部分加密消息(如仅对部分头域和消息体加密),或者只加密消息体,而避免对用于路由的头域进行加密,可以为部分头域和消息体提供端到端的机密性和完整性以及相互鉴别。同时,S/MIME可以通过SIP消息隧道为SIP头域提供完整性和机密性。
上述的HTTP Digest认证是基于共享密钥的(也称为常规加密);而S/MIME则是一个基于公开密钥加密体系的(以下简称为公钥体系)。
公钥体系的编码学和共享密钥的方法不同,公钥体系是非对称的,它用到了两个不同的密钥,而对称的共享密钥的方法则只使用一个密钥。这并不是指公钥体系加密比共享密钥的方式安全,实际上,任何加密方案的安全程度都依赖于密钥的长度和破译密码所包含的计算工作量。从抗击密码分析的角度讲,无论是常规加密还是公钥体系都没有比对方优越的地方。
同样,公钥体系也不会使常规加密成为一种过时的技术,相反,由于当前公钥加密在计算上的巨大开销,使得在可以预见的将来常规加密并不会被抛弃。公钥加密的发明者之一写到:“大家几乎普遍接受的观点是公开密钥密码编码学的使用仅限于密钥管理和数字签名等应用”。
在SIP网络中,网络实体,如Proxy(代理服务器)或者背靠背用户代理(Back to Back User Agent,简称“B2B UA”),需要获取SIP信令中的信息,但是为了保持安全性,终端可能不希望将SIP信令中的全部信息暴露给所有的中间实体,终端希望可以按照自己的意愿将部分头域信息或者消息体暴露给中间的网络实体。例如在IP多媒体子系统(IP MultimediaSubsystem,简称“IMS”)网络中,终端希望将SIP消息中的会话描述协议(Session Description Protocol,简称“SDP”)信息暴露给代理呼叫会话控制功能(Proxy-Call Session Control Function,简称“P-CSCF”)和服务呼叫会话控制功能(Serving-Call Session Control Function,简称“S-CSCF”),使得P-CSCF可以根据SDP进行资源预留和控制,S-CSCF可以根据SDP提 供业务,同时,SDP信息对I-CSCF或者HSS而言是保密的。
为了解决上述问题,draft-ietf-sip-e2m-sec草案提出了一种进行消息加密/签名的方法,这种方法是基于公钥体系的:
具体地说,终端首先根据不同的需求对不同的头域或者消息体部分,利用终端的私钥进行签名。之后,终端生成一个为信息进行加密的密钥,称之为常规密钥(Content-Encription-Key简称“CEK”),也即内容密钥,通过CEK对头域或者消息体进行加密;然后利用中间实体的公钥对CEK进行加密,将该对此CEK进行加密的密钥称为(key-encription-key,简称“KEK”)。最后,终端将加密后的信息组织为S/MIME格式进行传输。
通过该方法,使得密文在传输的过程中,只有那些指定的中间实体可以进行解密并验证数字签名,从而保证了信息的安全。其网络结构示意图如图1所示。
另外,为了减少每次消息的公钥加密过程,草案中同时提出了一种常规密钥重用的机制:
终端通过unprotectedAttrs参数通知中间实体或者对端终端,使用为当前消息内容加密的CEK作为后续消息的KEK;并在每个消息中产生一个新的CEK,这个新的CEK被重用的KEK加密。值得一提的是,此草案中的KEK均是常规加密的密钥,而不是基于公钥体系的公钥。通过这种方式,可以节省公钥加密的耗时过程。
然而,由于上述的方法需要终端进行S/MIME处理并进行加密,存在以下问题:
1.因为终端需要加密,且部分使用常规加密,部分使用公钥加密,可能需要使用特定的芯片,导致终端的成本上升;
2.因为终端的处理能力有限,而且公钥加密本身需要的计算量大,因此 加密过程将导致终端的处理时长增加,进而导致呼叫接续时延增大;特别是当终端需要对多个中间实体或者对端终端暴露不同的信息时,需要对各种信息进行不同的加密或者签名,会导致处理时延急剧增大。
3.因为终端在加密的过程中需要获取中间实体的公钥,公钥的获取方法有:向指定的服务器获取公钥,或向服务器进行订阅(这样当公钥发生变化时可以及时得到通知),无论何种方法都会增加终端的负荷。
发明内容
有鉴于此,本发明的主要目的在于提供一种通信系统中消息加密签名的方法及系统和设备,使得终端进行加密和签名时的成本、负荷和呼叫时延得以减少。
为实现上述目的,本发明提供了一种通信系统中消息加密的方法,终端为待发送的消息生成内容密钥,将所生成的内容密钥发送到公钥服务设备;
所述公钥服务设备使用需要知道该消息内容的实体的公钥对该内容密钥加密,并将加密后的所述内容密钥返回所述终端;
所述终端使用该内容密钥对该消息的内容加密,并将所述加密后的消息和所述经公钥加密的内容密钥向对端终端发送。
其中,所述终端在对所述消息的内容加密之前,将所述消息的内容发送给所述公钥服务设备,所述公钥服务设备使用第一私钥对所述消息的内容进行签名,并将所述签名后的消息返回所述终端;
所述终端使用所述内容密钥加密所述经签名的消息内容。
此外在所述方法中,所述第一私钥是所述公钥服务设备的私钥或所述终端的私钥。
此外在所述方法中,所述终端通过以下方式之一获取所述公钥服务设备 的地址:
在所述终端上固定配置公钥服务设备的地址;
在所述终端获取IP地址时,通过动态主机配置协议通知其所述公钥服务设备的地址;
所述终端是移动终端时,在分组数据协议上下文建立过程中通知所述终端所述公钥服务设备的地址。
此外在所述方法中,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和/或指定头域。
此外在所述方法中,在所述SIP消息中包含用于请求加密或签名的第一头域,所述第一头域包含以下之一或其任意组合:
指示终端请求签名或请求加密的信息;
标识所述消息中请求签名或加密的内容的信息;
指示所述需要知道该消息内容的实体的信息。
此外在所述方法中,在所述SIP消息中包含用于返回加密或签名后内容的第二头域,所述第二头域包含以下之一或其任意组合:
指示所述消息中请求签名或加密的内容的信息;
标识所述消息中经签名或加密后的内容的信息;
指示所述需要知道该消息内容的实体的信息。
此外在所述方法中,在所述SIP消息中包含可选标签,所述公钥服务设备在无能力加密或签名所述消息中的内容时,通过该标签返回失败指示。
此外在所述方法中,所述公钥服务设备从证书服务器获取所述需要知道消息内容的实体的公钥。
此外在所述方法中,所述公钥服务设备通过第一接口与所述证书服务器建立连接,获取所述需要知道消息内容的实体的公钥;
所述第一接口是超文本传输协议接口或SIP接口。
此外在所述方法中,所述终端通过第二接口与所述公钥服务设备之间建立安全连接,并通过所述安全连接与所述公钥服务设备进行信息的交互;
所述第二接口基于安全的连接协议;
所述第二接口是私有接口或SIP接口。
此外在所述方法中,所述公钥服务设备禁止普通维护人员对所述终端和公钥服务设备间的消息进行跟踪,并为所述消息的维护操作设置日志记录。
此外在所述方法中,所述公钥服务设备禁止保存所述终端的内容密钥。
此外在所述方法中,所述需要知道消息内容的实体是消息传递路径中的中间实体或对端终端。
本发明还提供了一种通信系统中消息签名的方法,终端将需要签名的消息内容发送给公钥服务设备;
所述公钥服务设备使用第一私钥对所述消息内容进行签名,并将所述签名后的消息返回所述终端;
其中,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和/或指定头域。
其中,所述第一私钥是所述公钥服务设备的私钥或所述终端的私钥。
此外在所述方法中,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和/或指定头域。
本发明还提供了一种通信系统中消息加密的系统,包含终端和公钥服务设备,所述终端还包含:
生成模块,用于为待发送的消息生成内容密钥;
第一加密模块,用于使用所述生成模块生成的内容密钥对所述消息的内容加密;
第一收发模块,用于将所述生成模块所生成的内容密钥发送到公钥服务设备进行加密,并从所述公钥服务设备接收加密后的内容密钥,将该加密后的内容密钥和所述第一加密模块加密后的消息向对端终端发送;
所述公钥服务设备还包含:
第二收发模块,用于接收来自终端的用于加密终端待发送消息内容的内容密钥;
第二加密模块,用于使用需要知道所述消息内容的实体的公钥对来自所述第二收发模块的内容密钥加密,并指示所述第二收发模块将加密后的所述内容密钥返回所述终端。
其中,所述第一收发模块还用于将所述待发送消息的内容发送给所述公钥服务设备进行签名;
所述公钥服务设备还包含签名模块,用于使用第一私钥对来自所述第一收发模块的消息内容进行签名;
所述第一加密模块使用内容密钥加密的消息内容为所述签名模块签名后的消息内容。
此外在所述系统中,还包含证书服务器,所述第二加密模块从所述证书服务器获取所述需要知道消息内容的实体的公钥。
本发明还提供了一种终端,包含:
生成模块,用于为待发送的消息生成内容密钥;
加密模块,用于使用所述生成模块生成的内容密钥对所述消息的内容加密;
收发模块,用于将所述生成模块所生成的内容密钥发送到公钥服务设备进行加密,并从所述公钥服务设备接收加密后的内容密钥,将该加密后的内容密钥和所述加密模块加密后的消息向对端终端发送。
其中,所述收发模块还用于将所述待发送的消息的内容发送到所述公钥服务设备进行签名;
所述加密模块使用内容密钥加密的消息内容为经签名的消息内容。
本发明还提供了一种公钥服务设备,包含:
收发模块,用于接收来自终端的用于加密终端待发送消息内容的内容密钥;
加密模块,用于使用需要知道所述消息内容的实体的公钥对所述收发模块收到的内容密钥加密,并指示所述收发模块将加密后的内容密钥返回所述终端。
其中,还包含签名模块,用于在所述收发模块接收来自所述终端的待发送消息的内容后,使用第一私钥对所述消息的内容进行签名。
本发明还提供了一种通信系统中消息签名的系统,包含终端和公钥服务设备,所述终端还包含:
第一收发模块,用于将需要签名的消息内容发送给所述公钥服务设备,并从所述公钥服务设备接收签名后的消息内容;
所述公钥服务设备还包含:
第二收发模块,用于接收来自终端的需要签名的消息内容;
签名模块,用于使用第一私钥对所述第二收发模块收到的消息内容进行签名,并指示所述第二收发模块将签名后的消息内容发送给所述终端。
本发明还提供了一种终端,包含:
收发模块,用于将需要签名的消息内容发送给所述公钥服务设备,并从所述公钥服务设备接收签名后的消息内容;
其中,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和/或指定头域。
本发明还提供了一种公钥服务设备,包含:
收发模块,用于接收来自终端的需要签名的消息内容;
签名模块,用于使用第一私钥对所述第二收发模块收到的消息内容进行签名,并指示所述第二收发模块将签名后的消息内容发送给所述终端;
其中,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和/或指定头域。
通过比较可以发现,本发明的技术方案与现有技术的主要区别在于,终端为待发送的消息生成内容密钥,将所生成的内容密钥发送到公钥服务设备,由公钥服务设备使用需要知道该消息内容的实体的公钥对该内容密钥加密,终端仅使用该内容密钥对该消息的内容加密,之后,将加密后的消息和经公钥加密的内容密钥发送给对端终端。通过将计算量十分大的公钥加密操作从终端上分离,转而由专门的公钥服务设备完成此部分功能,使得终端只需进行一些计算量较小的常规加密,大大减少了终端的负担,且终端无需配置公钥体系专门的加密和解密芯片/软件,降低了终端的成本。
终端在对消息的内容加密之前,将消息的内容发送给公钥服务设备,由公钥服务设备使用第一私钥对消息的内容进行签名,使得接收该消息的终端能够确定消息的来源,以双向确保消息传输的安全性。
其中,第一私钥是公钥服务设备的私钥或终端的私钥。如果第一私钥是公钥服务设备的私钥,由于公钥服务设备和终端是在同一个接入域中的,公钥服务设备可以对终端进行认证,因此由认证终端的公钥服务设备进行签名同样能够保证消息来源的安全性,且采用公钥服务设备的私钥进行签名可以确保终端的私钥不被泄密。如果第一私钥是终端的私钥,可以唯一确定消息的来源,在消息来源的安全性上更有保障。
在SIP消息中新增用于请求加密或签名的第一头域,该第一头域包含指示终端请求签名或请求加密的信息、标识消息中请求签名或加密的内容的信息和指示需要知道该消息内容的实体的信息。通过新增第一头域,使得终端能够采用SIP消息通知公钥服务设备对指定的内容进行指定公钥的加密。
在SIP消息中新增用于返回加密或签名后内容的第二头域,该第二头域包含指示消息中请求签名或加密的内容的信息,该信息与用于请求加密的第一头域中的相同,用于进行信息的匹配,还包含标识消息中经签名或加密后的内容的信息和指示需要知道该消息内容的实体的信息,用于返回加密后的内容。
在SIP消息中新增可选标签,使得公钥服务设备在无能力加密或签名消息中的内容时,能够及时通过该标签返回失败指示。
公钥服务设备从证书服务器获取需要知道消息内容的实体的公钥,并且可以向证书服务器订阅实体的证书更新通知,当某个实体的公钥更新时,可以及时得到最新的公钥。
终端与公钥服务设备之间通过安全连接如IPSec等进行信息的交互,以提高消息传输过程中的安全性。
公钥服务设备在一般情况下禁止维护人员对终端和公钥服务设备间的消息进行跟踪,并为消息的维护操作设置日志记录,从而在发生特殊情况必须对消息进行跟踪时,可以通过日志对这些维护操作进行监视,防止终端的消息或密钥被泄漏。
公钥服务设备禁止保存终端的内容密钥,使得公钥服务设备对于密钥和密钥重用过程应该是完全无状态的。
终端和公钥服务设备之间的安全连接与终端和SIP服务器间的安全连接相互独立。使得公钥服务设备在对部分的消息内容或者内容密钥进行加密后,依然无法知道通讯的内容。
附图说明
图1是现有技术中消息加密的网络结构示意图;
图2是本发明通信系统中消息加密的原理图;
图3是根据本发明第一实施方式的通信系统中消息加密的方法中的网络结构示意图;
图4是根据本发明第一实施方式的通信系统中消息加密的方法流程图;
图5是根据本发明第一实施方式的通信系统中消息加密后的解密方法流程图;
图6是根据本发明第三实施方式的通信系统中消息加密的系统结构图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述。
本发明的核心在于,终端为待发送的消息生成内容密钥,将所生成的内容密钥发送到公钥服务设备,由公钥服务设备使用需要知道该消息内容的实体的公钥对该内容密钥加密,终端仅使用该内容密钥对该消息的内容加密,之后,将加密后的消息和经公钥加密的内容密钥发送给对端终端。通过将计算量十分大的公钥加密操作从终端上分离,转而由专门的公钥服务设备完成此部分功能,使得终端只需进行一些计算量较小的常规加密,从而减少终端的负担,降低终端进行加密时成本。
具体地说,如图2所示,在步骤210中,终端在需要为待发送的消息(包括消息的头域或指定的消息体)签名时,将需要签名的消息内容发送给公钥 服务设备。
接着进入步骤220,公钥服务设备收到该消息的内容后,使用第一私钥对其进行签名,并将签名后的消息返回该终端。通过公钥服务设备使用第一私钥对消息的内容进行签名,使得接收该消息的终端能够确定消息的来源,从而与之后的加密操作组合,双向确保消息传输的安全性。其中,该第一私钥可以是公钥服务设备的私钥,或者是终端的私钥。如果第一私钥是公钥服务设备的私钥,由于公钥服务设备和终端是在同一个接入域中的,公钥服务设备可以对终端进行认证,因此由认证终端的公钥服务设备进行签名同样能够保证消息来源的安全性,且采用公钥服务设备的私钥进行签名可以确保终端的私钥不被泄密。如果第一私钥是终端的私钥,可以唯一确定消息的来源,在消息来源的安全性上更有保障。
接着进入步骤230,终端为该消息生成内容密钥,并将该内容密钥发送到公钥服务设备进行加密。
接着进入步骤240,该公钥服务设备收到该内容密钥后,使用需要知道该消息内容的实体的公钥对该内容密钥加密,并将加密后的内容密钥返回该终端。通过将计算量十分大的公钥加密操作从终端上分离,转而由专门的公钥服务设备完成此部分功能,使得终端只需进行一些计算量较小的常规加密,大大减少了终端的负担,且终端无需配置公钥体系专门的加密和解密芯片/软件终端,降低了终端的成本。
接着进入步骤250,该终端使用该内容密钥加密该签名后的消息内容。
接着进入步骤260,终端将其加密后的消息和经过公钥加密的内容密钥向对端终端发送。
下面根据发明原理对本发明第一实施方式进行说明,本发明第一实施方式主要涉及通信系统中消息加密的方法。在本实施方式中,公钥服务设备包含两个接口,第一接口是接口Y,第二接口是接口Z。如图3所示,接口Y 是公钥服务设备与证书服务器之间的接口,该接口可以是HTTP接口或SIP接口;接口Z是终端与公钥服务设备之间的接口,终端通过接口Z与公钥服务设备之间建立安全连接,并通过该安全连接与公钥服务设备进行信息的交互。接口Z是基于安全的连接协议的,如基于IPSec。对于接口Z,可以采用不同的协议来进行信息传递,可以是私有接口或SIP接口。
如果采用SIP接口,由于现有的SIP协议无法传输相关参数,因此需要对SIP协议消息进行扩展如下:
1.新增用于请求加密或签名的第一头域:Security-Helper
此头域在终端向公钥服务设备请求加密或签名时使用,用于标识终端向公钥服务设备请求进行签名还是请求进行加密处理。此头域中包含:
a.指示终端请求签名或请求加密的信息,通过语法中的method参数进行表示。
b.标识消息中请求签名或加密的内容的信息。该信息标识终端请求加密/签名时,希望加密/签名的具体内容是什么。这些加密的内容对公钥服务设备是透明的,这些信息可以通过cid参数来标识,通过cid参数索引到消息体中的相应部分。
c.指示需要知道该消息内容的实体的信息。该信息指示在消息传输的过程中,需要知道该消息内容的实体,包括消息传递路径中的中间实体或对端终端。需要知道该消息内容的实体可以是一个或多个,这些实体的公钥信息通过KeyRef参数表示。
通过该第一头域,使得终端能够采用SIP消息通知公钥服务设备对指定的内容进行指定实体公钥的加密。
扩展后的语法格式为:
Security-Helper=“Security-Helper”HCOLON helper-value*(COMMA
helper-value)
Help-value=method;cid;*(;KeyRef);*(SEMI generic-param)
method-tag=“encrpty”/“sign”/token
cid=“cid”EQUAL sip-clean-msg-id
sip-clean-msg-id=LDQUOT dot-atom“”(dot-atom/host)RDQUOT
dot-atom=atom*(“.”atom)
atom=1*(alphanum/“-”/“!”/“%”/“*”/“_”/“+”/“′”/“`”/“~”)
KeyRef=HostRef|UriRef
HostRef=“hostref”EQUAL host
UriRef=“uriref”EQUAL absoluteURI
2.新增用于返回加密或签名后内容的第二头域:Security-Response
此头域在公钥服务设备返回加密或签名后的内容时使用,用于传递公钥服务设备向终端返回经过加密或签名后的信息。此头域包含:
a.指示消息中请求签名或加密的内容的信息。该信息与Security-Helper头域中包含的cid参数内容相对应,便于终端进行匹配,该信息通过orig-cid参数返回终端。
b.标识消息中经签名或加密后的内容的信息。用于返回经过公钥服务设备签名或加密处理后的内容,通过new-cid参数进行索引。
c.指示需要知道该消息内容的实体的信息。该信息与Security-Helper头域中包含的KeyRef参数内容相对应,同样用于指示在消息传输的过程中,需要知道该消息内容的实体,通过相同的KeyRef参数返回终端,便于终端完成匹配。
也就是说,在完成加密后,公钥服务设备可以通过将cid参数映射到orig-cid参数以及将KeyRef原样返回,使得终端能够正确完成匹配。
其具体语法格式为:
Security-Response =“Security-Response”HCOLON response-value*(COMMA response-value)
Response=Oirg-cid;New-cid[;KeyRef];*(SEMI generic-param)
Orig-cid=“orig-cid”EQUAL sip-clean-msg-id
New-cid=“new-cid”EQUAL sip-clean-msg-id
通过该第二头域,使得公钥服务设备能够通过SIP消息将加密或签名后的内容返回终端。
3.新增可选标签Tag,此标签可以用于Require头域,表示公钥服务设备必须对上述的Security-Helper头域进行处理,公钥服务设备无能力处理,则通过该标签返回失败指示。
具体语法格式为:Option tag:security-helper
另外,在终端和公钥服务之间没有必要建立SIP呼叫,只需要进行SIP的事务处理就可以了,所以在终端和公钥服务之间,可以利用MESSAGE消息来进行通讯。
具体的加密过程如图4所示,在步骤401中,当终端希望公钥服务设备进行安全相关的处理时,根据需要进行签名的SIP消息内容设置其Security-Helper头域,在此头域的method参数中设置为标识签名请求,在cid参数中设置需要进行签名的消息内容的索引。之后终端将设置后的SIP消息通过接口Z发送给公钥服务设备。终端可以在此头域中可以包含多个头域值,公钥服务设备可以对这些头值域中包含的多个cid所索引的内容分别进行签名处理。
如果终端不能确定服务器是否能够提供公钥服务的功能,则可在SIP消息的Require头域中添加标签(Tag)security-helper,以便服务器在无能力进 行签名及加密时返回失败信息。
其中,终端对于公钥服务设备的发现过程可以有多种方式:
1.配置方式:在终端上固定配置公钥服务设备的地址,从而使得每次的公钥加密请求都会发送到对应的公钥服务设备上;
2.通过动态主机配置协议(Dynamic Host Configuration Protocol,简称“DHCP”)方式:当终端启动,获取IP地址的时候,通过DHCP通知该终端公钥服务设备的地址;
3.对于移动终端,可以由通用分组无线业务网关支持节点(GPRSGateway Support Node,简称“GGSN”)在分组数据协议上下文建立过程中通知该终端公钥服务设备的地址。
接着进入步骤402,公钥服务设备从接口Z上接收到SIP消息后,对消息进行解码以及检查,如果消息中的Require头域中没有包含security-helper标签,或包含security-helper标签且本公钥服务设备支持该签名和加密功能,则进入步骤404;反之,如果消息中的Require头域中存在security-helper标签但是本公钥服务设备不支持该签名和加密功能,则进入步骤403,发送420响应给终端,告知终端本公钥服务设备不支持签名和加密功能。
在步骤404中,公钥服务设备进一步检查Security-Helper头域,首先检查头域中的method参数,在确定终端当前请求的是对消息内容进行签名后,使用本公钥服务设备的私钥对cid索引的内容进行签名处理,并通过SIP消息中的Security-Response头域将签名后的消息内容返回给该终端。如果该公钥服务设备能够获取终端的私钥,则同样可以使用终端的私钥对cid索引的内容进行签名处理。如果第一私钥是公钥服务设备的私钥,由于公钥服务设备和终端是在同一个接入域中的,公钥服务设备可以对终端进行认证,因此由认证终端的公钥服务设备进行签名同样能够保证消息来源的安全性,且采用公钥服务设备的私钥进行签名可以确保终端的私钥不被泄密。如果第一私 钥是终端的私钥,可以唯一确定消息的来源,在消息来源的安全性上更有保障。
接着进入步骤405,终端为待发送的消息内容生成内容密钥,并通过SIP消息将该内容密钥发送到公钥服务设备。具体地说,终端将该内容密钥携带在在SIP消息体中,并设置该SIP消息的Security-Helper头域,将method参数设置为标识加密请求,cid参数设置为指向内容密钥,在KeyRef参数中设置需要知道消息内容的中间实体或对端终端的标识,将设置后的包含内容密钥的消息发送到公钥服务设备。
接着进入步骤406,公钥服务设备收到该消息后,同样检查Security-Helper头域中的method参数,在确定终端当前请求进行加密后,检查KeyRef参数指示的中间实体或对端终端的公钥是否缓存在本地,如果不是则进入步骤407,公钥服务设备根据KeyRef参数从证书服务器获取相应实体的公钥,公钥服务设备可以通过接口Y与证书服务器建立连接,获取需要知道消息内容的实体的公钥,获取公钥的过程可以基于HTTP,LDAP,SIP等,接着进入步骤408;反之,如果KeyRef参数指示的中间实体或对端终端的公钥是缓存在本地,则直接进入步骤408,公钥服务设备使用KeyRef参数指示的实体的公钥对内容密钥进行加密。为了减少公钥获取所消耗的时间,公钥服务设备也可以将相应实体的公钥保存在本地,并向证书服务器订阅实体的证书更新通知,当某个实体的公钥更新时,可以及时得到最新的公钥,
接着进入步骤409,公钥服务设备将加密后的内容密钥返回给终端。
接着进入步骤410,终端使用其生成的内容密钥对签名后的消息内容进行加密。
接着进入步骤411,终端将其加密后的消息和经过公钥加密的内容密钥向对端终端发送。
在加密的过程中,为了提高加密的安全级别,需注意如下几点:
1.终端与公钥服务设备之间必须通过安全连接进行信息交互,如IPSec等。
2.公钥服务设备对消息的加密和签名处理独立于该公钥服务设备中的其它操作,如证书获取/更新等。
3.在非必要时,公钥服务设备不拥有终端的私钥,当需要进行签名时,公钥服务设备使用自己的私钥进行签名,以保证终端的私钥不被泄密。
4.终端和公钥服务设备间的消息禁止普通的公钥服务设备维护人员跟踪,并为消息的维护操作设置日志记录,在发生特殊情况时,可以在日志的监视下进行消息的跟踪。通过这一方式防止终端的消息或密钥被泄漏。
5.公钥服务设备禁止保存终端的内容密钥,公钥服务设备对于密钥和密钥重用过程应该是完全无状态的。
6.所述终端和所述公钥服务设备之间的安全连接与所述终端和SIP服务器间的安全连接相互独立。使得公钥服务设备在对部分的消息内容或者内容密钥进行加密后,依然无法知道通讯的内容。
下面对接口Z上终端发送的SIP消息进行示例(括号里的字体是对消息的说明,不属于消息的一部分):
在此消息中,终端请求公钥服务设备
1.对SDP消息进行签名;
2.将终端用于SDP加密的内容密钥使用pizzahut.exampleB.com主机的公钥进行加密。
MESSAGE sip:public-key-service.exampleA.com SIP/2.0
Via:SIP/2.0/UDP pc33.exampleA.com;branch=z9hG4bK776asdhds
Max-Forwards:70
To:<sip:public-key-service.exampleA.com>
From:Alice<sip:aliceexampleA.com>;tag=1928301774
Call-ID:a84b4c76e66710pc33.exampleA.com
CSeq:3MESSAGE
Contact:<sip:alicepc33.exampleA.com>
Require:security-helper
Security-Helper:method=sign;cid=“telotardmdstexampleA.com”
Security-Helper:method=encrypt;hostref=pizzahut.exampleB.com;
cid=“atyydsdcstmexampleA.com”;
Content-Type:multipart/mixed;boundary=“boundary-1”
Content-Length:XXX
——boundary-1
Content-Type:application/sdp
Content-ID:<telotardmdstexampleA.com>
v=0
o=alice 536557652353687637 IN IP4 pc33.atlanta.com
s=-
t=00
c=IN IP4 pc33.atlanta.com
m=audio 3456 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
——boundary-1
Content-Type:application/text
Content-ID:<atyydsdcstmexampleA.com>
Sdfasdfadfasdagetetetetetlteooyytmyts(此处是终端用于加密的内容密钥,
但是公钥服务并不理解其含义)
——boundary-1——
公钥服务设备根据终端的请求对相应内容进行签名及加密后,在接口Z上返回的消息如下:
SIP/2.0 200 OK
Via:SIP/2.0/UDP pc33.exampleA.com;branch=z9hG4bK776asdhds
To:<sip:public-key-service.exampleA.com>
From:Alice<sip:aliceexampleA.com>;tag=1928301774
Call-ID:a84b4c76e66710pc33.exampleA.com
CSeq:3MESSAGE
Security-Response:orig-cid=“telotardmdstexampleA.com”;new-cid=“123
4exampleA.com”,
orig-cid=“atyydsdcstmexampleA.com”;new-cid=“5678exampleA.com”;
hostref=pizzahut.example B.com
Content-Type:multipart/mixed;boundary=“boundary-1”
Content-Length:XXX (此处填入实际的长度)
——boundary1(第一部分,经过数字签名后的消息体)
Content-Type:application/pkcs7-signature;name=smime.p7s
Content-Transfer-Encoding:base64
Content-ID:<1234exampleA.com>
Content-Disposition:attachment;filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
——boundary1(第二部分,使用pizzahut.exampleB.com公钥加密的内容密钥)
Content-Type:application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7m
Content-ID:<5678exampleA.com>
*****************************************
*Sdfasdfadfasdagetetetetetlteooyytmyts*
*****************************************
——boundary-1——
下面对通信系统中消息加密后的解密方法进行简单说明。
如图5所示,在步骤510中,消息传递路径中需要知道消息内容的中间实体或终端收到来自终端的加密后的消息和经公钥加密的内容密钥后,首先使用自身的私钥解密出内容密钥。
接着进入步骤520,中间实体或终端使用该内容密钥解密消息的内容。
在解密出消息的内容后,接着进入步骤530,以第一私钥对应的公钥进行签名验证。如果该第一私钥是公钥服务设备的私钥,则使用公钥服务设备的公钥对消息的内容进行验证,从而确定消息的来源;如果该第一私钥是终端的私钥,则使用该终端的公钥对消息的内容进行验证。
下面对本发明第二实施方式进行说明,第二实施方式仅涉及通信系统中 消息签名的方法。在本实施方式中,终端在需要对消息内容进行签名时,如在加密待发送的消息之前,将需要签名的消息内容发送给公钥服务设备,由公钥服务设备使用第一私钥对该消息内容进行签名,并将签名后的消息返回该终端。其中需要签名的消息内容可以是SIP消息的消息体或指定头域,用于签名的第一私钥可以是公钥服务设备的私钥或终端的私钥。对于第一私钥是公钥服务设备的私钥的情况,公钥服务设备必须预先对终端进行认证,由于公钥服务设备和终端是在同一个接入域中的,因此认证是可以实现的,在终端通过认证的情况下,公钥服务设备为终端进行消息内容的签名,以确保消息来源的安全性。由于采用公钥服务设备的私钥进行签名可以确保终端的私钥不被泄密,且安全性能够得到保证,因此较为理想。当然,如果第一私钥是终端的私钥,则可以唯一确定消息的来源,在消息来源的安全性上更有保障。需要注意的是,为了保证消息内容不外泄,终端与公钥服务设备之间必须通过独立的安全连接进行信息的交互。
下面对本发明第三实施方式进行说明,第三实施方式涉及通信系统中消息加密的系统,如图6所示,该加密系统包含终端、公钥服务设备和证书服务器。其中,终端还包含生成模块,用于为待发送的消息生成内容密钥;第一加密模块,用于使用生成模块生成的内容密钥对消息的内容加密;第一收发模块,用于将生成模块所生成的内容密钥发送到公钥服务设备进行加密,并从公钥服务设备接收加密后的内容密钥,将该加密后的内容密钥和第一加密模块加密后的消息向对端终端发送。公钥服务设备还包含:第二收发模块,用于接收来自终端的用于加密终端待发送消息内容的内容密钥;第二加密模块,用于从证书服务器获取需要知道消息内容的实体的公钥,并使用需要知道消息内容的实体的公钥对来自第二收发模块的内容密钥加密,指示第二收发模块将加密后的内容密钥返回终端。该需要知道消息内容的实体是消息传递路径中的中间实体或对端终端。通过将计算量十分大的公钥加密操作从终端上分离,转而由专门的公钥服务设备完成此部分功能,使得终端只需进行 一些计算量较小的常规加密,大大减少了终端的负担,且终端无需配置公钥体系专门的加密和解密芯片/软件终端,降低了终端的成本和负担的同时,由于公钥服务可以设计为有较强处理能力的设备,从而可以加快加密的过程,缩短呼叫接续时间,并且进一步保障了内容密钥加密的安全性。另外,由于公钥服务上的公钥加密和解密芯片/软件,可以在多个终端间进行统计复用,所以保持一定的收敛比(例如1000个终端,只配置100个芯片),可以降低整个网络的成本。
为了使得接收消息的中间实体或对端终端能够确定消息的来源,避免受到来源不明的信息攻击,双向确保消息传输的安全性,在公钥服务设备包含签名模块,终端在对消息的内容加密之前,可以通过第一收发模块将消息内容发送给公钥服务设备,由公钥服务设备的签名模块使用第一私钥对消息的内容进行签名,以确定消息来源的安全性。用于签名的第一私钥可以是公钥服务设备的私钥或终端的私钥。对于第一私钥是公钥服务设备的私钥的情况,公钥服务设备可以预先对终端进行认证,在终端通过认证的情况下,公钥服务设备为终端进行消息内容的签名。采用公钥服务设备的私钥进行签名使得消息来源安全性得到保证的同时,可以避免终端的私钥被泄密,因此较为理想。当然,如果第一私钥是终端的私钥,则可以唯一确定消息的来源,在消息来源的安全性上更有保障。需要注意的是,为了提高信息交互的安全性,防止终端消息内容或私钥泄漏,终端与公钥服务设备之间必须通过独立的安全连接进行信息的交互。
值得一提的是,在实际应用中,本实施方式中终端以及公钥服务设备中的各模块可以各自通过独立的物理单元实现,也可以合并到同一个物理单元实现,只要实现各模块对应的功能即能够达到本发明的效果。
下面对本发明第四实施方式进行说明,第四实施方式将通信系统中的消息签名从加密系统中独立出来,形成独立的签名系统。该系统包含终端和公 钥服务设备,其中,终端还包含第一收发模块,用于将需要签名的消息内容发送给公钥服务设备,并从公钥服务设备接收签名后的消息内容;公钥服务设备还包含第二收发模块,用于接收来自终端的需要签名的消息内容;签名模块,用于使用第一私钥对第二收发模块收到的消息内容进行签名,并指示第二收发模块将签名后的消息内容发送给终端。
虽然通过参照本发明的某些优选实施方式,已经对本发明进行了图示和描述,但本领域的普通技术人员应该明白,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。
Claims (21)
1.一种通信系统中消息加密的方法,其特征在于,终端为待发送的消息生成内容密钥,将所生成的内容密钥发送到公钥服务设备;
所述公钥服务设备使用需要知道该消息内容的实体的公钥对该内容密钥加密,并将加密后的所述内容密钥返回所述终端;
所述终端使用该内容密钥对该消息的内容加密,并将所述加密后的消息和所述经公钥加密的内容密钥向对端终端发送。
2.根据权利要求1所述的通信系统中消息加密的方法,其特征在于,所述终端在对所述消息的内容加密之前,将所述消息的内容发送给所述公钥服务设备,所述公钥服务设备使用第一私钥对所述消息的内容进行签名,并将所述签名后的消息返回所述终端;
所述终端使用所述内容密钥加密所述经签名的消息内容。
3.根据权利要求2所述的通信系统中消息加密的方法,其特征在于,所述第一私钥是所述公钥服务设备的私钥或所述终端的私钥。
4.根据权利要求1所述的通信系统中消息加密的方法,其特征在于,所述终端通过以下方式之一获取所述公钥服务设备的地址:
在所述终端上固定配置公钥服务设备的地址;
在所述终端获取IP地址时,通过动态主机配置协议通知其所述公钥服务设备的地址;
所述终端是移动终端时,在分组数据协议上下文建立过程中通知所述终端所述公钥服务设备的地址。
5.根据权利要求2所述的通信系统中消息加密的方法,其特征在于,所述消息是会话初始协议SIP消息,所述消息的内容为SIP消息的消息体和 /或指定头域。
6.根据权利要求5所述的通信系统中消息加密的方法,其特征在于,在所述SIP消息中包含用于请求加密或签名的第一头域,所述第一头域包含以下之一或其任意组合:
指示终端请求签名或请求加密的信息;
标识所述消息中请求签名或加密的内容的信息;
指示所述需要知道该消息内容的实体的信息。
7.根据权利要求5所述的通信系统中消息加密的方法,其特征在于,在所述SIP消息中包含用于返回加密或签名后内容的第二头域,所述第二头域包含以下之一或其任意组合:
指示所述消息中请求签名或加密的内容的信息;
标识所述消息中经签名或加密后的内容的信息;
指示所述需要知道该消息内容的实体的信息。
8.根据权利要求5所述的通信系统中消息加密的方法,其特征在于,在所述SIP消息中包含可选标签,所述公钥服务设备在无能力加密或签名所述消息中的内容时,通过该标签返回失败指示。
9.根据权利要求1所述的通信系统中消息加密的方法,其特征在于,所述公钥服务设备从证书服务器获取所述需要知道消息内容的实体的公钥。
10.根据权利要求9所述的通信系统中消息加密的方法,其特征在于,所述公钥服务设备通过第一接口与所述证书服务器建立连接,获取所述需要知道消息内容的实体的公钥;
所述第一接口是超文本传输协议接口或SIP接口。
11.根据权利要求1至10中任一项所述的通信系统中消息加密的方法, 其特征在于,所述终端通过第二接口与所述公钥服务设备之间建立安全连接,并通过所述安全连接与所述公钥服务设备进行信息的交互;
所述第二接口基于安全的连接协议;
所述第二接口是私有接口或SIP接口。
12.根据权利要求1至10中任一项所述的通信系统中消息加密的方法,其特征在于,所述公钥服务设备禁止普通维护人员对所述终端和公钥服务设备间的消息进行跟踪,并为所述消息的维护操作设置日志记录。
13.根据权利要求1至10中任一项所述的通信系统中消息加密的方法,其特征在于,所述公钥服务设备禁止保存所述终端的内容密钥。
14.根据权利要求1至10中任一项所述的通信系统中消息加密的方法,其特征在于,所述需要知道消息内容的实体是消息传递路径中的中间实体或对端终端。
15.一种通信系统中消息加密的系统,其特征在于,包含终端和公钥服务设备,所述终端还包含:
生成模块,用于为待发送的消息生成内容密钥;
第一加密模块,用于使用所述生成模块生成的内容密钥对所述消息的内容加密;
第一收发模块,用于将所述生成模块所生成的内容密钥发送到公钥服务设备进行加密,并从所述公钥服务设备接收加密后的内容密钥,将该加密后的内容密钥和所述第一加密模块加密后的消息向对端终端发送;
所述公钥服务设备还包含:
第二收发模块,用于接收来自终端的用于加密终端待发送消息内容的内容密钥;
第二加密模块,用于使用需要知道所述消息内容的实体的公钥对来自所 述第二收发模块的内容密钥加密,并指示所述第二收发模块将加密后的所述内容密钥返回所述终端。
16.根据权利要求15所述的通信系统中消息加密的系统,其特征在于,所述第一收发模块还用于将所述待发送消息的内容发送给所述公钥服务设备进行签名;
所述公钥服务设备还包含签名模块,用于使用第一私钥对来自所述第一收发模块的消息内容进行签名;
所述第一加密模块使用内容密钥加密的消息内容为所述签名模块签名后的消息内容。
17.根据权利要求15所述的通信系统中消息加密的系统,其特征在于,还包含证书服务器,所述第二加密模块从所述证书服务器获取所述需要知道消息内容的实体的公钥。
18.一种终端,其特征在于,包含:
生成模块,用于为待发送的消息生成内容密钥;
加密模块,用于使用所述生成模块生成的内容密钥对所述消息的内容加密;
收发模块,用于将所述生成模块所生成的内容密钥发送到公钥服务设备进行加密,并从所述公钥服务设备接收加密后的内容密钥,将该加密后的内容密钥和所述加密模块加密后的消息向对端终端发送。
19.根据权利要求18所述的终端,其特征在于,所述收发模块还用于将所述待发送的消息的内容发送到所述公钥服务设备进行签名;
所述加密模块使用内容密钥加密的消息内容为经签名的消息内容。
20.一种公钥服务设备,其特征在于,包含:
收发模块,用于接收来自终端的用于加密终端待发送消息内容的内容密 钥;
加密模块,用于使用需要知道所述消息内容的实体的公钥对所述收发模块收到的内容密钥加密,并指示所述收发模块将加密后的内容密钥返回所述终端。
21.根据权利要求20所述的公钥服务设备,其特征在于,还包含签名模块,用于在所述收发模块接收来自所述终端的待发送消息的内容后,使用第一私钥对所述消息的内容进行签名。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200610153501 CN101141251B (zh) | 2006-09-08 | 2006-09-08 | 通信系统中消息加密签名的方法及系统和设备 |
PCT/CN2007/070664 WO2008040213A1 (fr) | 2006-09-08 | 2007-09-10 | Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200610153501 CN101141251B (zh) | 2006-09-08 | 2006-09-08 | 通信系统中消息加密签名的方法及系统和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101141251A CN101141251A (zh) | 2008-03-12 |
CN101141251B true CN101141251B (zh) | 2012-05-23 |
Family
ID=39193020
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200610153501 Expired - Fee Related CN101141251B (zh) | 2006-09-08 | 2006-09-08 | 通信系统中消息加密签名的方法及系统和设备 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101141251B (zh) |
WO (1) | WO2008040213A1 (zh) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9137214B2 (en) | 2010-12-15 | 2015-09-15 | Microsoft Technology Licensing, Llc | Encrypted content streaming |
CN102752272A (zh) * | 2011-04-22 | 2012-10-24 | 中兴通讯股份有限公司 | 媒体消息数字签名的处理方法、系统和装置 |
CN105763571A (zh) * | 2016-04-27 | 2016-07-13 | 蓝盾信息安全技术有限公司 | 基于sip的非对称语音加密 |
CN108833091B (zh) * | 2018-05-28 | 2021-03-12 | 武汉斗鱼网络科技有限公司 | 一种日志文件的加密方法、解密方法及装置 |
CN110572454A (zh) * | 2019-09-11 | 2019-12-13 | 深圳钱客多信息科技有限公司 | 一种保障广告投放过程安全的广告投放系统 |
CN110768831B (zh) * | 2019-10-24 | 2022-12-16 | 上海东谷云数字科技有限公司 | 一种获取监控插件方法及系统 |
CN113038459A (zh) * | 2019-12-25 | 2021-06-25 | 中兴通讯股份有限公司 | 隐私信息传输方法、装置、计算机设备及计算机可读介质 |
CN111431890B (zh) * | 2020-03-20 | 2021-12-03 | 苏州瑞立思科技有限公司 | 一种低开销的中间服务器代理传输认证方法及装置 |
CN111756699B (zh) * | 2020-05-28 | 2022-05-06 | 苏州浪潮智能科技有限公司 | 一种基于非对称加密的lldp协议优化方法与系统 |
CN113992352B (zh) * | 2021-09-27 | 2024-06-25 | 青岛海尔科技有限公司 | 一种消息推送方法、装置、电子设备及存储介质 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1472914A (zh) * | 2003-06-27 | 2004-02-04 | 武汉理工大学 | 一种高效快捷的公钥加密方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6779111B1 (en) * | 1999-05-10 | 2004-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Indirect public-key encryption |
US7174021B2 (en) * | 2002-06-28 | 2007-02-06 | Microsoft Corporation | Systems and methods for providing secure server key operations |
JP2005533438A (ja) * | 2002-07-12 | 2005-11-04 | イングリアン ネットワークス インコーポレーテッド | ネットワークに付随する暗号化 |
US7535905B2 (en) * | 2004-03-31 | 2009-05-19 | Microsoft Corporation | Signing and validating session initiation protocol routing headers |
JP3910611B2 (ja) * | 2004-12-28 | 2007-04-25 | 株式会社日立製作所 | 通信支援サーバ、通信支援方法、および通信支援システム |
CN100426718C (zh) * | 2004-12-31 | 2008-10-15 | 北京中星微电子有限公司 | 一种媒体内容安全传输方法 |
-
2006
- 2006-09-08 CN CN 200610153501 patent/CN101141251B/zh not_active Expired - Fee Related
-
2007
- 2007-09-10 WO PCT/CN2007/070664 patent/WO2008040213A1/zh active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1472914A (zh) * | 2003-06-27 | 2004-02-04 | 武汉理工大学 | 一种高效快捷的公钥加密方法 |
Non-Patent Citations (1)
Title |
---|
JP特开2006-50504A 2006.02.16 |
Also Published As
Publication number | Publication date |
---|---|
CN101141251A (zh) | 2008-03-12 |
WO2008040213A1 (fr) | 2008-04-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101141251B (zh) | 通信系统中消息加密签名的方法及系统和设备 | |
EP1378101B1 (en) | Voip terminal security module, sip stack with security manager, system and security methods | |
US9537837B2 (en) | Method for ensuring media stream security in IP multimedia sub-system | |
JP4710267B2 (ja) | ネットワークシステム、データ中継装置、セッションモニタシステム、およびパケットモニタ中継装置 | |
US9755825B2 (en) | Device authentication and secure channel management for peer-to-peer initiated communications | |
CN101911645B (zh) | 用于验证通信关系的端点之间的密钥信息的方法和端点 | |
CN101222320B (zh) | 一种媒体流安全上下文协商的方法、系统和装置 | |
CN101227272A (zh) | 一种获取媒体流保护密钥的方法和系统 | |
KR101016277B1 (ko) | 보안성이 강화된 sⅰp 등록 및 sⅰp 세션 설정 방법 및장치 | |
US20100034384A1 (en) | Method for providing a symmetric key for protecting a key management protocol | |
EP2448172A1 (en) | Method and system for delaying transmission of media information in internet protocol (ip) multimedia subsystem | |
CN100544247C (zh) | 安全能力协商方法 | |
EP2451133B1 (en) | Method and system for transmitting delay media information in ip multimedia subsystem | |
Ignjatic et al. | MIKEY-RSA-R: An additional mode of key distribution in Multimedia Internet KEYing (MIKEY) | |
CN102025485B (zh) | 密钥协商的方法、密钥管理服务器及终端 | |
CN115589288B (zh) | 基于量子密钥预充注实现端到端VoIP加密通信方法 | |
CN101222612A (zh) | 一种安全传输媒体流的方法和系统 | |
CN115589292A (zh) | 实现端到端VoIP一话多密的加密通话方法及系统 | |
CN101729535B (zh) | 一种媒体点播业务的实现方法 | |
Gurbani et al. | A secure and lightweight scheme for media keying in the session initiation protocol (SIP) work in progress | |
WO2015032734A1 (en) | Srtp protocol extension | |
CN101719894B (zh) | 一种安全发送延迟媒体的实现系统及方法 | |
Orrblad et al. | Secure VoIP: call establishment and media protection | |
Seokung et al. | A study on the improvement of MIKEY PKE mode using TLS Handshake Protocol | |
Ignjatic et al. | RFC 4738: MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
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: 20120523 Termination date: 20170908 |