WO2012174843A1 - 一种实现端到端安全的密钥协商方法及系统 - Google Patents

一种实现端到端安全的密钥协商方法及系统 Download PDF

Info

Publication number
WO2012174843A1
WO2012174843A1 PCT/CN2011/085193 CN2011085193W WO2012174843A1 WO 2012174843 A1 WO2012174843 A1 WO 2012174843A1 CN 2011085193 W CN2011085193 W CN 2011085193W WO 2012174843 A1 WO2012174843 A1 WO 2012174843A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
party
call
update parameter
media stream
Prior art date
Application number
PCT/CN2011/085193
Other languages
English (en)
French (fr)
Inventor
田甜
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012174843A1 publication Critical patent/WO2012174843A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement

Definitions

  • the present invention relates to network communication security technologies, and in particular, to a key negotiation method and system for implementing end-to-end security. Background technique
  • IMS IP Multimedia Subsystem
  • SDP Session Description Protocol
  • SDES SDP Security Descriptions for Media Streams
  • SRTP secure real-time transport protocol
  • SDES is not a key agreement protocol in nature but a key distribution protocol. The key is distributed directly over the network through plaintext, so SDES must rely on signaling security. As shown in Figure 1, SDES essentially works like this: When the calling party UE-A and the called party UE-B establish a SIP session, they use the Offer/Response mode exchange to provide SRTP. The key and related parameters required for media stream protection.
  • a call flow for establishing end-to-end security using SDES is as shown in FIG. 2.
  • UE-A first generates a root key K1, which is used to generate a protection UE-A and send it to the UE-
  • the media session key of the B media stream is securely included in the SIP message sent by the IMS network intermediate network element and the call server to the UE-B (ie, in the INVITE message), and the root key K1 is included.
  • Sent to UE-B; and UE-B returns SIP to UE-A In the message (ie, in the 200 Ok message), the root key K2 is included, and the root key K2 is returned to the UE-A.
  • the root key K2 is used to generate a media session key that protects the UE-B from transmitting to the UE-A media stream.
  • Session Initiation Protocol Session Initiation Protocol
  • forked calls communication
  • call diversion communication diversion
  • FIG. 3 The scenario of the existing forked call service is shown in FIG. 3.
  • the split call service means that multiple terminals of the called party can be called at the same time, thereby increasing the probability of the call being connected.
  • the calling party may not know that its call is forked, and when a terminal has already responded, the other terminal can no longer answer the call. This requires that the calling party and the called party have a unique media key, and all terminals except the answering terminal cannot learn the session key that is already in use, so as to ensure that the session content does not Other terminals are being monitored or leaked out.
  • the call forwarding service means that when the called party that enables the call forwarding service during the call is in an unreachable, busy, or other state, the call forwarding application server of the called party transfers the call to the called party in advance.
  • the user equipment of the called party thereby improving the flexibility and configurability of the call.
  • the call forwarding service allows the user to transfer all of their incoming calls to another pre-set phone number or to the user's voicemail.
  • the call transfer also includes a special multiple transfer call scenario, that is, user A calls user B, user B uses call forwarding service, the call is transferred to user C, and user C also uses call forwarding service, and the call is transferred to user D again. .
  • the calling party will send the root key K1 to the called party through the IMS network after the root key K1 is generated.
  • K1 will be sent to all terminals of the called party; when the called party signs the call forwarding service, the call forwarding service is triggered, and the call forwarding application server transfers the call to the called party set by the called party.
  • the root key K1 is included in the INVITE message to be forwarded to the called party; after that, the called party transmits the root key K2 to the calling party through the IMS network, and the calling party and the called party use the root key Kl
  • the root key ⁇ 2 performs secure communication.
  • the disadvantages of the prior art are: In the above-mentioned bifurcation call scenario, there may be multiple called terminals. Knowing the root key K1 used by the calling party, the called terminal also has the ability to decrypt the encrypted media stream sent by the calling party, and the physical security problem of the user equipment does not guarantee the legitimacy of the user, using a legitimate device.
  • a person may be a malicious attacker, such as a user whose user equipment has been stolen, so that there is a threat of key leakage and single-party session compromise; and in the scenario of multiple call forwarding in one session, all called parties
  • the device has the ability to know the root key K1 used by the calling party, and thus has the ability to decrypt the encrypted media stream sent by the calling party. In this way, in the case of a forked call and a call transfer scenario, there is a serious threat of security session compromise, and end-to-end security cannot be achieved. Summary of the invention
  • the main object of the present invention is to provide a method and system for implementing a key agreement for end-to-end security to solve the problem of key compromise threats and session compromise threats in existing end-to-end security technologies.
  • the present invention provides a key agreement method for implementing end-to-end security, the method comprising: generating, by a second party, a second key material and a key update parameter, and updating the parameter and the first key according to the key Material, generating a second key;
  • the second party transmits the generated second key material and the key update parameter to the first party; the first party generates the first according to the key update parameter and the first key material Second key
  • the first party protects the transmitted media stream using the second key.
  • the method further includes:
  • the second party only transmits the generated second key material to the Said the first party.
  • the method further includes: The second party sends a key generation function to the first party, and the first party and the second party generate the second key using the key generation function.
  • the method further includes:
  • the first party and the second party respectively generate the second key according to the same key generation function that is pre-configured, and according to the key update parameter and the first key material.
  • the method further includes:
  • the first key material is pre-configured into the first party and the second party, or the first party generates a first key material and then passes the second key material to the second party.
  • the method further includes:
  • the second party protects the transmitted media stream using the second key or using a third key derived from the second key material.
  • the present invention also provides a key agreement system for implementing end-to-end security, the system comprising: a first party and a second party,
  • the second party is configured to generate a second key material and a key update parameter, and generate a second key according to the key update parameter and the first key material; and the generated second key material And a key update parameter is passed to the first party;
  • the first party is configured to generate the second key according to the key update parameter and the first key material; and protect the sent media stream by using the second key.
  • the second party is further configured to: select the generated second key material as the key update parameter, and when the generated second key material is selected as a key update parameter, the second party only generates The second key material is passed to the first party.
  • the second party is further configured to send a key generation function to the first party, and correspondingly, the first party and the second party generate the second key by using the key generation function.
  • the first party and the second party respectively use the same key generation function respectively configured in advance, Generating the second key according to the key update parameter and the first key material.
  • the first key material is pre-configured into the first party and the second party, or the first party generates a first key material and then passes the second key material to the second party.
  • the second party is further configured to protect the transmitted media stream using the second key or using a third key derived from the second key material.
  • the end-to-end secure key agreement method and system of the present invention can ensure end-to-end media stream security and avoid key leakage threats and session compromise threats.
  • FIG. 1 is a schematic diagram of a working model of SDES in the prior art
  • FIG. 2 is a flow chart of an SDES-based end-to-end secure call process in the prior art
  • FIG. 3 is a schematic diagram of a scenario of an IMS forked call in the prior art
  • FIG. 4 is a flowchart of a method for implementing end-to-end security key negotiation according to the present invention
  • FIG. 5 is a flow chart of a method for implementing end-to-end security in a single call transfer according to Embodiment 1 of the present invention
  • FIG. 6 is a flow chart of a method for implementing end-to-end security in multiple call forwarding according to Embodiment 2 of the present invention
  • FIG. 7 is a flowchart of a method for implementing end-to-end security in a forked call according to Embodiment 3 of the present invention. detailed description
  • a method for implementing end-to-end security key agreement provided by the present invention mainly includes:
  • Step 401 The second party generates a second key material and a key update parameter, and generates a second key according to the key update parameter and the first key material.
  • the first key material may be pre-configured on the second party or may be generated by the first party. After passing to the second party. Either way, it is necessary to ensure that the first key material used by the first party and the second party is the same.
  • the generated second key material may be directly selected as a key update parameter, and when the generated second key material is selected as a key update parameter, the second party only generates the generated second key material. Pass it to the first party.
  • a random number may be selected as the key update parameter, or a combination of the second key material and the random number may be selected as the key update parameter. Either way, you need to ensure that the key update parameters used by the first party and the second party are the same.
  • Step 402 The second party transmits the generated second key material and the key update parameter to the first party.
  • the first party also needs to pass the key generation function to the second party; if the second party is pre-configured with the key generation function, then the first party The key generation function may not be sent to the second party.
  • the first party may always use the key generation function and the second key. The material and key update parameters are passed along to the second party. Either way, you need to ensure that the key generation functions used by the first party and the second party are the same.
  • Step 403 The first party generates a second key according to the key update parameter and the first key material.
  • the second party sends the key generation function to the first party, the first party and the second party generate the second key using the key generation function;
  • the first party and the second party respectively use the same key generation function respectively configured in advance, according to the key update parameter, and the The first key material generates a second key.
  • Step 404 The first party protects the media stream it sends by using the second key.
  • the present invention may further include a step 405, that is, the second party protects the media stream that is sent by using the second key; or, derives the third key according to the second key material, and uses the third secret
  • the key protects the media stream it sends.
  • the present invention further provides a key agreement system for implementing end-to-end security, including: a first party and a second party.
  • the second party is configured to generate a second key material and a key update parameter, and generate a second key according to the key update parameter and the first key material; and the generated second key material and the secret
  • the key update parameter is passed to the first party.
  • the first party is configured to generate a second key according to the key update parameter and the first key material; and protect the sent media stream by using the second key.
  • the second party is further configured to: select the generated second key material as a key update parameter, and when the generated second key material is selected as a key update parameter, the second party only generates the The second key material is passed to the first party.
  • the second party is further configured to send the key generation function to the first party, and correspondingly, the first party and the second party generate the second key by using the key generation function.
  • the first party and the second party respectively generate the second key according to the same key generation function that is pre-configured, and according to the key update parameter and the first key material.
  • the second party is further for protecting the transmitted media stream using the second key, or using a third key derived from the second key material.
  • the calling party of the end-to-end secure communication may perform the first party function operation as the first party; the called party or the called party may serve as the second party. Fang, perform the function operation of the second party.
  • the calling party of the end-to-end secure communication can perform the first party function operation as the first party; the called party or the forked party can serve as the first The two parties perform the function operation of the second party.
  • the key agreement system of the present invention may further include an application server, such as a forked call. Server, call transfer application server, etc.
  • an application server such as a forked call. Server, call transfer application server, etc.
  • the application server is used as the call server to which the second party belongs, it is used to send a call request message to the second party after receiving the call of the first party.
  • the called party sets the called party as the call forwarding destination, and triggers the call forwarding service signed by the called party.
  • This can be one of the following situations: CFB (Communication Forwarding Busy), Call Forwarding (CFNR, Communication Forwarding No Reply), Communication Forwarding Unconditional (CFU), Communication Forwarding on Subscriber Not Reachable (CFNRc, Communication Forwarding on Subscriber Not Reachable), Call Forwarding without Registration (CFNL, Communication Forwarding) On Not Logged in ) and Session Transfer (CD, Communication Deflection) services.
  • CFB Commonation Forwarding Busy
  • CFNR Call Forwarding
  • CFU Communication Forwarding Unconditional
  • CFNRc Communication Forwarding on Subscriber Not Reachable
  • CFNL Communication Forwarding without Registration
  • CD Session Transfer
  • FIG. 5 is a schematic diagram of a method for implementing end-to-end secure call forwarding in a single call transfer according to Embodiment 1 of the present invention, that is, user A wants to call user B, user B subscribes to call forwarding service, and preset user C is a call transfer object. During the call setup process, the call forwarding service subscribed by user B is triggered.
  • UE-A is the first party
  • UE-C is the second party.
  • the end-to-end secure call transfer specifically includes the following steps:
  • Step 501 The UE-A generates a calling key K1 (as the first key material).
  • Step 502 The UE-A sends a call request (INVITE) message to the IMS network to the UE-B, and the call request message carries the calling key K1.
  • Step 503 The IMS network forwards the received INVITE message to the call forwarding application server to which the UE-B belongs.
  • Step 504 The call transfer application server sends an INVITE message to the UE-B. This step Alternatively, for example: When user B signs for an unconditional call transfer, step 504 is omitted. Step 505, the call forwarding service signed by the UE-B is triggered.
  • Step 506 The call forwarding application server forwards the INVITE message including the calling key K1 to the call forwarding number set by the user B through the IMS network, which is UE-C in this embodiment.
  • KDF dense Key Derivation Function
  • Step 508 UE-C includes the called key ⁇ 2 and the key update parameter P1, and the KDF
  • the 200 ⁇ message (or other SIP message containing SDP Answer) is returned to the call transfer application server via the IMS network.
  • K2 contains only the message and steps 509 to 510, the call transfer server application returns a 200 OK message to UE-A via the IMS network 0
  • UE-A and UE-C establish end-to-end secure encrypted media stream communication, UE-A uses ⁇ to protect the media stream sent from UE-A to UE-C, and UE-C can use ⁇ to UE-
  • the media stream sent by A is decrypted; UE-C uses K2 (ie, directly derives the second key material as the third key) to protect the media stream sent from UE-C to UE-A, and UE-A can use K2 pair.
  • K2 ie, directly derives the second key material as the third key
  • UE-A and UE-C may also use ⁇ to protect the media stream between them, UE-C may use ⁇ to decrypt the media stream sent by UE-A, UE-A may use ⁇ to send to UE-C.
  • the media stream is decrypted.
  • 6 is a method for implementing an end-to-end secure call transfer in multiple call forwarding according to Embodiment 2 of the present invention, that is, user B signs a call transfer service, and presets a call transfer to user C, and user C also subscribes to call transfer.
  • the service the call is transferred to the user D by default, and in the session where the UE-A calls the UE-B, both the UE-B and the UE-C trigger the subscribed call transfer service, and the final session is transferred to the UE-D.
  • UE-A is the first party
  • UE-D is the second party.
  • the end-to-end secure call transfer specifically includes the following steps:
  • steps 601 to 606 are the same as the operations of steps 501 to 506.
  • Step 606 is also optional, which is related to the call forwarding service subscribed by the user. If it is an unconditional call forwarding service, step 606 is omitted.
  • Step 607 the call forwarding service of the UE-C is triggered.
  • Step 608 The call forwarding application server forwards the INVITE message including the calling key K1 to the call forwarding number set by the user C through the IMS network, which is UE-D in this embodiment.
  • Step 609 after receiving the INVITE message, the UE-D learns that the call is a SDES end-to-end secure security call by the calling key K1 (as the first key material) included in the message; UE-D generates the called party.
  • the key K2 (as the second key material) and the key update parameter P1, and the UE-D generates a new calling key K1' KDF (Kl, PI) based on P1 and the received K1, ⁇ as the second Key.
  • Step 610 The UE-D returns the called key ⁇ 2 and the key update parameter P1, and the KDF is included in the 200 ⁇ message (or other SIP message containing the SDP Answer) to the call transfer application server through the IMS network. Among them, if P1 is selected as K2, the message only contains K2 and KDF.
  • Steps 611 ⁇ 612 the call forwarding application server returns the 200 OK message to the UE-A through the IMS network.
  • Step 614 UE-A and UE-D establish an end-to-end secure encrypted media stream communication, UE-A uses ⁇ to protect the media stream sent from UE-A to UE-D, and UE-D can use ⁇ to UE-
  • the media stream sent by A is decrypted;
  • UE-D uses K2 (ie, directly derives the second key material as the third key) to protect the media stream sent from UE-D to UE-A, and UE-A can use K2 pair.
  • the media stream sent by UE-D is decrypted.
  • UE-A and UE-D may also use ⁇ to protect the media stream exchanged between them, UE-D may use ⁇ to decrypt the media stream sent by UE-A, UE-A may use ⁇ to send to UE-D. The media stream is decrypted.
  • Embodiment 7 is an end-to-end secure forked call according to Embodiment 3 of the present invention, that is, user B subscribes to a forked call service, and when user A calls user B, UE-B1 and UE-B2 owned by user B are shown.
  • the terminal will be called at the same time, assuming that the UE-B2 terminal finally responds in this embodiment.
  • UE-A is used as the first party
  • UE-B1 and UE-B2 are used as the second party.
  • the implementation of the end-to-end secure call transfer specifically includes the following steps:
  • Step 701 The UE-A generates a calling key K1 (as the first key material).
  • Step 702 UE-A sends a call request (INVITE) message to UE-B to the IMS network, and the call request message carries the calling key K1.
  • Step 703 The IMS network forwards the received INVITE message to the forked call application server to which the UE-B belongs.
  • Step 704 the forked call application server sends an INVITE message to UE-B1, UE-B2, that is, in steps 705a and 705b, the forked call application server sends a SIP message containing the SDP Offer of K1 to the UE-B1, UE. -B2.
  • KDF Key Derivation Function
  • UE-B1 includes the called key K2 and the key update parameter P1, and the KDF is included in the SDP Answer message and returned to the call forwarding application server through the IMS network. Among them, if P1 is selected as K2, the message only contains K2 and KDF.
  • Steps 708a ⁇ 709a the forked call application server returns the message to the IMS network.
  • the media stream sent by UE-A is decrypted; UE-B2 uses K3 (ie, directly derives the second key material as the third key) to protect the media stream sent from UE-B2 to UE-A, and UE-A can use K3 decrypts the media stream sent by UE-B2.
  • UE-A and UE-B2 may also use Ka2 to protect the media stream exchanged between them, UE-B2 may use Ka2 to decrypt the media stream sent by UE-A, UE-A may use Ka2 to UE- The media stream sent by B2 is decrypted.

Abstract

本发明公开了一种实现端到端安全的密钥协商方法和系统，方法包括：第二方生成第二密钥材料和密钥更新参数，并根据密钥更新参数、以及第一密钥材料，生成第二密钥；第二方将生成的第二密钥材料和密钥更新参数传递给第一方；第一方根据密钥更新参数、以及第一密钥材料，生成第二密钥；第一方使用第二密钥保护发送的媒体流；第二方使用第二密钥、或使用根据第二密钥材料导出的第三密钥保护发送的媒体流。通过本发明，能够保证端到端的媒体流安全，避免密钥泄露威胁和会话泄密威胁。

Description

一种实现端到端安全的密钥协商方法及系统 技术领域
本发明涉及网络通信安全技术， 尤其涉及一种实现端到端安全的密钥 协商方法及系统。 背景技术
现有的第三代合作伙伴计划 （3GPP , Third Generation Partnership Projects ) TS33.328的 IP多媒体子系统（ IMS , IP Multimedia Subsystem ) IMS 媒体面安全中使用 RFC4568 的会话描述协议（SDP, Session Description Protocol ) 的媒体流安全描述（ SDES, SDP Security Descriptions for Media Streams )作为媒体面端到端安全方案。 在 SDES方案中， 使用 SDP协议中 的加密属性来传送密钥协商材料， 通过通话双方交互 SDP数据包来导出媒 体密钥， 并且定义了如何在安全实时传输协议 ( SRTP, Secure Real-time Transport Protocol ) 中使用这些媒体密钥。
SDES本质上不是一个密钥协商协议而是一个密钥分发协议，密钥是直 接通过明文在网路上分发， 所以 SDES必须依赖于信令的安全。 如图 1所 示， SDES本质上是这样工作的： 当主叫方 UE-A和被叫方 UE-B建立了一 个 SIP会话时，他们使用提出 /应答（ Offer/Response )模式交换提供给 SRTP 进行媒体流保护所需要的密钥及相关参数。
一个使用 SDES建立端到端安全的呼叫流程如图 2所示， UE-A在发 起 SIP会话时， 首先生成根密钥 K1 , 所述根密钥 K1用来生成保护 UE-A 发给 UE-B媒体流安全的媒体会话密钥， 然后在通过 IMS网络中间网元以 及呼叫服务器发给 UE-B的一个 SIP消息中 （即 INVITE消息中）包含所述 根密钥 K1 ,将根密钥 K1发送给 UE-B;而 UE-B在返回给 UE-A的响应 SIP 消息中 （即 200 Ok消息中） 包含根密钥 K2, 向 UE-A返回根密钥 K2, 根 密钥 K2用来生成保护 UE-B发给 UE-A媒体流安全的媒体会话密钥。
在会话发起协议（SIP, Session Initiation Protocol ) 系统中， 分叉呼叫 ( forking )和呼叫转移 （communication diversion )都是非常常见的实用型 业务。 现有分叉呼叫业务的场景如图 3 所示， 分叉呼叫业务是指， 被呼叫 方的多个终端可以同时被呼叫， 从而提高了呼叫接通的概率。 需要注意的 是， 呼叫方可能并不知道其呼叫被分叉， 且当一个终端已经进行了应答， 其他终端则不能再对呼叫进行应答。 这就要求呼叫方与被呼叫方的任一终 端都有唯一的媒体密钥， 并且除应答终端之外的所有终端都不能获悉已经 在使用的会话密钥， 以此来保证会话内容不会从其他终端被监听或泄露出 去。 呼叫转移业务是指， 当呼叫过程中启用呼叫转移服务的被叫方处于不 可达、 或忙碌、 或其他状态时， 由被叫方的呼叫转移应用服务器将此呼叫 转移到被叫方事先设置的被转呼方的用户设备上， 从而提高呼叫的灵活性 和可配置性。 呼叫转移业务允许用户将其所有来话转接到预先设置的另一 个电话号码上或用户的语音信箱中。 呼叫转移还包含特殊的多次转移呼叫 场景， 即用户 A呼叫用户 B, 用户 B使用呼叫转移业务， 呼叫被转移给用 户 C, 用户 C也使用了呼叫转移业务， 该呼叫被再次转移给用户 D。
使用 SDES方案保证端到端安全时， 主叫方会在生成根密钥 K1后， 将 根密钥 K1 包含在 INVITE消息中通过 IMS网络传到被叫方， 当被叫方为 forking场景时， K1会被发给被叫方的所有终端； 而当被叫方签约了呼叫转 移服务时， 呼叫转移业务被触发， 呼叫转移应用服务器将该呼叫转移到被 叫方所设置的被转呼方，将根密钥 K1包含在 INVITE消息中转到被转呼方； 之后， 被转呼方再将根密钥 K2通过 IMS网络传到主叫方， 主叫方和被转 呼方使用根密钥 Kl、 根密钥 Κ2进行安全通信。
现有技术的缺陷在于： 在上述分叉呼叫场景下， 可能多个被叫终端都 获知了主叫方所使用的根密钥 K1 , 被叫终端也有能力解密主叫方所发送的 加密媒体流， 而用户设备的物理安全问题并不能保证使用者的合法性， 使 用一个合法设备的人可能是一个恶意攻击者， 例如用户设备被偷盗后的使 用者， 这样， 就会存在密钥泄露及单方会话泄密的威胁； 而在一次会话多 次呼叫转移的场景下， 所有被转呼方的设备都有能力获知主叫方所使用的 根密钥 K1 , 也就都有能力解密主叫方所发送的加密媒体流。 这样， 在分叉 呼叫及呼叫转移场景下， 会存在严重的安全会话泄密威胁， 无法实现端到 端安全。 发明内容
有鉴于此， 本发明的主要目的在于提供一种实现端到端安全的密钥协 商方法及系统， 以解决现有端到端安全技术存在密钥泄露威胁和会话泄密 威胁的问题。
为达到上述目的， 本发明的技术方案是这样实现的：
本发明提供了一种实现端到端安全的密钥协商方法， 该方法包括： 第二方生成第二密钥材料和密钥更新参数， 并根据所述密钥更新参 数、 以及第一密钥材料， 生成第二密钥；
第二方将生成的第二密钥材料和密钥更新参数传递给所述第一方； 所述第一方根据所述密钥更新参数、 以及所述第一密钥材料， 生成 所述第二密钥；
所述第一方使用所述第二密钥保护发送的媒体流。
该方法进一步包括：
选择生成的第二密钥材料作为所述密钥更新参数， 且当选择生成的 第二密钥材料作为密钥更新参数时， 所述第二方只将生成的第二密钥材 料传递给所述第一方。
该方法进一步包括： 所述第二方将密钥生成函数发送给所述第一方， 所述第一方和第二 方使用所述密钥生成函数生成第二密钥。
该方法进一步包括：
所述第一方和第二方分别使用各自预先配置的相同的密钥生成函 数， 根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密 钥。
该方法进一步包括：
所述第一密钥材料预先配置到所述第一方与所述第二方中， 或者所 述第一方生成第一密钥材料后传递给所述第二方。
该方法进一步包括：
所述第二方使用所述第二密钥、 或使用根据所述第二密钥材料导出 的第三密钥保护发送的媒体流。
本发明还提供了一种实现端到端安全的密钥协商系统， 该系统包括： 第一方和第二方，
所述第二方， 用于生成第二密钥材料和密钥更新参数， 并根据所述 密钥更新参数、 以及第一密钥材料， 生成第二密钥； 将生成的第二密钥 材料和密钥更新参数传递给所述第一方；
所述第一方， 用于根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密钥； 使用所述第二密钥保护发送的媒体流。
所述第二方进一步用于， 选择生成的第二密钥材料作为所述密钥更 新参数， 且当选择生成的第二密钥材料作为密钥更新参数时， 所述第二 方只将生成的第二密钥材料传递给所述第一方。
所述第二方进一步用于， 将密钥生成函数发送给所述第一方， 相应的， 所述第一方和第二方使用所述密钥生成函数生成第二密钥。 所述第一方和第二方分别使用各自预先配置的相同的密钥生成函数, 根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密钥。 所述第一密钥材料预先配置到所述第一方与所述第二方中， 或者所 述第一方生成第一密钥材料后传递给所述第二方。
所述第二方进一步用于， 使用所述第二密钥、 或使用根据所述第二密 钥材料导出的第三密钥保护发送的媒体流。
通过本发明的实现端到端安全的密钥协商方法及系统， 能够保证端到 端的媒体流安全， 避免密钥泄露威胁和会话泄密威胁。 附图说明
图 1为现有技术中 SDES的工作模型示意图；
图 2为现有技术中基于 SDES的端到端安全呼叫过程的流程图； 图 3为现有技术中 IMS分叉呼叫的场景示意图；
图 4为本发明一种实现端到端安全的密钥协商的方法流程图； 图 5 为本发明实施例一的单次呼叫转移中实现端到端安全的方法流程 图；
图 6为本发明实施例二的多次呼叫转移中实现端到端安全的方法流程 图；
图 7为本发明实施例三的分叉呼叫中实现端到端安全的方法流程图。 具体实施方式
下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。 本发明所提供的一种实现端到端安全的密钥协商的方法， 如图 4所示， 主要包括：
步驟 401 , 第二方生成第二密钥材料和密钥更新参数， 并根据密钥更 新参数、 以及第一密钥材料， 生成第二密钥。
其中， 第一密钥材料可以在第二方预先配置， 也可以由第一方生成 后传递给第二方。 无论采用哪种方式， 需要保证第一方和第二方所使用 的第一密钥材料相同。
在实际应用中， 可以直接选择生成的第二密钥材料作为密钥更新参 数， 且当选择生成的第二密钥材料作为密钥更新参数时， 第二方只将生 成的第二密钥材料传递给第一方即可。 当然， 也可以选择一随机数作为 密钥更新参数、 或者选择第二密钥材料和随机数的组合作为密钥更新参 数。 无论采用哪种方式， 需要保证第一方和第二方所使用的密钥更新参 数相同。
步驟 402 ,第二方将生成的第二密钥材料和密钥更新参数传递给第一 方。
需要说明的是， 如果第二方没有预先配置密钥生成函数， 那么第一 方还需要将密钥生成函数传递给第二方； 如果第二方预先配置有密钥生 成函数， 那么第一方可以不向第二方发送密钥生成函数。 优选的， 为了 避免第二方没有配置密钥生成函数、 或第二方与第一方配置的密钥生成 函数不匹配的情况发生， 第一方可以始终将密钥生成函数与第二密钥材 料和密钥更新参数一起传递给第二方。 无论采用哪种方式， 需要保证第 一方和第二方所使用的密钥生成函数相同。
步驟 403 , 第一方根据密钥更新参数、 以及第一密钥材料， 生成第二 密钥。
如果是第二方将密钥生成函数发送给第一方， 那么第一方和第二方 使用所述密钥生成函数生成第二密钥；
如果是在第一方和第二方分别预先配置相同的密钥生成函数， 那么 第一方和第二方分别使用各自预先配置的相同的密钥生成函数， 根据密 钥更新参数、 以及所述第一密钥材料， 生成第二密钥。
步驟 404, 第一方使用第二密钥保护其发送的媒体流。 较佳的， 本发明还可以进一步包括步驟 405 , 即第二方使用第二密钥保 护其发送的媒体流； 或者， 根据第二密钥材料导出第三密钥， 并使用所述 第三密钥保护其发送的媒体流。
对应上述实现端到端安全的密钥协商方法， 本发明还提供了一种实现 端到端安全的密钥协商系统， 包括： 第一方和第二方。 其中， 第二方， 用 于生成第二密钥材料和密钥更新参数， 并根据密钥更新参数、 以及第一密 钥材料， 生成第二密钥； 将生成的第二密钥材料和密钥更新参数传递给第 一方。 第一方， 用于根据密钥更新参数、 以及第一密钥材料， 生成第二密 钥； 使用第二密钥保护发送的媒体流。
较佳的， 第二方可进一步用于， 选择生成的第二密钥材料作为密钥更 新参数， 且当选择生成的第二密钥材料作为密钥更新参数时， 第二方只将 生成的第二密钥材料传递给第一方。
较佳的， 第二方还可进一步用于， 将密钥生成函数发送给第一方， 相应的， 第一方和第二方使用所述密钥生成函数生成第二密钥。
较佳的， 第一方和第二方分别使用各自预先配置的相同的密钥生成函 数， 根据密钥更新参数、 以及第一密钥材料， 生成所第二密钥。
第二方还进一步用于， 使用第二密钥、 或使用根据第二密钥材料导出 的第三密钥保护发送的媒体流。
当上述密钥协商方法和系统应用于呼叫转移场景时， 端到端安全通信 的主叫方可以作为第一方， 执行第一方的功能操作； 被叫方或被转呼方可 以作为第二方， 执行第二方的功能操作。
当上述密钥协商方法和系统应用于分叉呼叫场景时， 端到端安全通信 的主叫方可以作为第一方， 执行第一方的功能操作； 被叫方或被分叉方可 以作为第二方， 执行第二方的功能操作。
较佳的， 本发明的密钥协商系统还可以包括应用服务器， 如分叉呼叫 服务器、 呼叫转移应用服务器等。 当应用服务器作为第二方所属的呼叫服 务器时， 用于在收到第一方的呼叫后向第二方发送呼叫请求消息。
下面结合具体实施例对上述端到端安全的密钥协商方法和系统进一步 详细说明。 以下实施例分别列举呼叫转移场景和分叉呼叫场景下的端到端 安全实现， 其中实施例一和实施例二针对呼叫转移场景， 实施例三针对分 叉呼叫场景。
呼叫转移场景下被叫方将被转呼方设定为呼叫转移目标， 触发被叫方 签约的呼叫转移业务的情况， 可以是以下情况之一： 遇忙呼叫转移 （CFB, Communication Forwarding Busy )、无应答呼叫转移 ( CFNR, Communication Forwarding No Reply ), 无条件呼叫转移 ( CFU, Communication Forwarding Unconditional )、 寻呼不可及转移 ( CFNRc, Communication Forwarding on Subscriber Not Reachable ), 未注册时呼叫转移 （CFNL , Communication Forwarding on Not Logged in )和会话转移 ( CD, Communication Deflection ) 业务。
图 5 所示为本发明实施例一的单次呼叫转移中实现端到端安全呼叫转 移的方法， 即用户 A想呼叫用户 B, 用户 B签约了呼叫转移业务， 预设用 户 C为呼叫转移对象， 在呼叫建立过程中， 用户 B签约的呼叫转移业务被 触发。 在本实施例中， UE-A作为第一方， UE-C作为第二方， 实现端到端 安全呼叫转移具体包括以下步驟：
步驟 501 , UE-A生成主叫密钥 K1 (作为第一密钥材料）。
步驟 502 , UE-A向 IMS网络发送对 UE-B的呼叫请求（ INVITE )消息 , 且此呼叫请求消息中携带主叫密钥 Kl。
步驟 503 , IMS网络将收到的 INVITE消息转发到 UE-B所属的呼叫转 移应用服务器。
步驟 504, 呼叫转移应用服务器将 INVITE消息发送到 UE-B。 该步驟 为可选的， 例如： 当用户 B签约的为无条件呼叫转移时， 步驟 504省略。 步驟 505， UE-B签约的呼叫转移业务被触发。
步驟 506, 呼叫转移应用服务器将包含主叫密钥 K1的 INVITE消息通 过 IMS网络转发给用户 B设定的呼叫转移号码， 在本实施例中即 UE-C。
步驟 507, UE-C收到 INVITE消息后， 获知此为一个呼叫转移， 并由 消息中包含的主叫密钥 K1 获知该呼叫是一个 SDES端到端安全的安全呼 叫； UE-C生成被叫密钥 K2 (作为第二密钥材料）和密钥更新参数 P1 , 且 UE-C基于 P1和收到的 K1生成新的主叫密钥 K1'=KDF ( Kl , PI ), 其中 KDF为密钥生成函数 ( Key Derivation Function ), Κ 作为第二密钥。
步驟 508 , UE-C将被叫密钥 Κ2和密钥更新参数 P1 , 以及 KDF包含在
200 ΟΚ消息 （或其他含有 SDP Answer的 SIP消息 ) 中通过 IMS网络返回 给呼叫转移应用服务器。 其中， 如果 P1选择为 K2, 则消息中只包含 K2和 步驟 509~510,呼叫转移应用服务器将 200 OK消息通过 IMS网络返回 给 UE-A0
步驟 511 , UE-A在收到该消息后基于主叫密钥 K1和收到的密钥更新 参数 P1 , 使用 KDF生成新的主叫密钥 K1'=KDF ( Kl , PI )0
步驟 512, UE-A和 UE-C建立起端到端安全的加密媒体流通信， UE-A 使用 Κ 保护从 UE-A发给 UE-C的媒体流， UE-C可以使用 Κ 对 UE-A发 送的媒体流进行解密； UE-C使用 K2 (即直接将第二密钥材料作为第三密 钥导出 )保护从 UE-C发给 UE-A的媒体流， UE-A可以使用 K2对 UE-C 发送的媒体流进行解密。
UE-A和 UE-C也可以均使用 Κ 保护其之间交互的媒体流， UE-C可以 使用 Κ 对 UE-A发送的媒体流进行解密， UE-A可以使用 Κ 对 UE-C发送 的媒体流进行解密。 图 6所示为本发明实施例二的多次呼叫转移中实现端到端安全呼叫转 移的方法， 即用户 B签约呼叫转移业务，预设将通话转移到用户 C, 用户 C 也签约了呼叫转移业务， 预设将通话转移到用户 D, 且在 UE-A呼叫 UE-B 的会话中， UE-B和 UE-C均触发签约的呼叫转移业务， 最终会话被转移到 UE-D。 在本实施例中， UE-A作为第一方， UE-D作为第二方， 实现端到端 安全呼叫转移具体包括以下步驟：
步驟 601~606的操作与步驟 501~506的操作相同。 其中， 步驟 606也 为可选， 这与用户签约的呼叫转移业务相关， 如果是无条件呼叫转移业务， 则步驟 606省略。
步驟 607, UE-C的呼叫转移业务被触发。
步驟 608, 呼叫转移应用服务器将包含主叫密钥 K1的 INVITE消息通 过 IMS网络转发给用户 C设定的呼叫转移号码， 在本实施例中即 UE-D。
步驟 609, UE-D收到 INVITE消息后， 由消息中包含的主叫密钥 K1 (作为第一密钥材料）获知该呼叫是一个 SDES端到端安全的安全呼叫； UE-D生成被叫密钥 K2 (作为第二密钥材料 )和密钥更新参数 P1 ,且 UE-D 基于 P1和收到的 K1生成新的主叫密钥 K1'=KDF ( Kl , PI ), Κ 作为第二 密钥。
步驟 610, UE-D将被叫密钥 Κ2和密钥更新参数 P1 , 以及 KDF包含 在 200 ΟΚ消息（或其他含有 SDP Answer的 SIP消息 ) 中通过 IMS网络返 回给呼叫转移应用服务器。 其中， 如果 P1选择为 K2, 则消息中只包含 K2 和 KDF。
步驟 611~612,呼叫转移应用服务器将 200 OK消息通过 IMS网络返回 给 UE-A。
步驟 613 , UE-A在收到该消息后基于主叫密钥 K1和收到的密钥更新 参数 P1 , 使用 KDF生成新的主叫密钥 K1'=KDF ( Kl , PI )0 步驟 614, UE-A和 UE-D建立起端到端安全的加密媒体流通信， UE-A 使用 Κ 保护从 UE-A发给 UE-D的媒体流， UE-D可以使用 Κ 对 UE-A发 送的媒体流进行解密； UE-D使用 K2 (即直接将第二密钥材料作为第三密 钥导出）保护从 UE-D发给 UE-A的媒体流， UE-A可以使用 K2对 UE-D 发送的媒体流进行解密。
UE-A和 UE-D也可以均使用 Κ 保护其之间交互的媒体流， UE-D可以 使用 Κ 对 UE-A发送的媒体流进行解密， UE-A可以使用 Κ 对 UE-D发送 的媒体流进行解密。
图 7所示为本发明实施例三的端到端安全的分叉呼叫， 即用户 B签约 了分叉呼叫业务，当用户 A呼叫用户 B时，用户 B所拥有的 UE-B1、 UE-B2 终端将同时被呼叫，假设该实施例中 UE-B2终端最终应答。在本实施例中， UE-A作为第一方， UE-B1、 UE-B2作为第二方， 实现端到端安全呼叫转移 具体包括以下步驟：
步驟 701 , UE-A生成主叫密钥 K1 (作为第一密钥材料）。
步驟 702, UE-A向 IMS网络发送对 UE-B的呼叫请求（ INVITE )消息 , 且此呼叫请求消息中携带主叫密钥 Kl。
步驟 703 , IMS网络将收到的 INVITE消息转发到 UE-B所属的分叉呼 叫应用服务器。
步驟 704,分叉呼叫应用服务器将 INVITE消息发送到 UE-B1、 UE-B2, 即在步驟 705a和 705b步驟中， 分叉呼叫应用服务器发送包含 K1的 SDP Offer的 SIP消息给 UE-B1、 UE-B2。
步驟 706a, UE-B 1收到 INVITE消息后， 由消息中包含的主叫密钥 K1 获知该呼叫是一个 SDES端到端安全的安全呼叫； UE-B1生成被叫密钥 K2 (作为第二密钥材料）和密钥更新参数 P1 , 且 UE-B1基于 P1和收到的 K1 生成新的主叫密钥 Kal=KDF ( Kl , PI ), 其中 KDF为密钥生成函数（Key Derivation Function ), Kal作为 UE-B 1与 UE- A之间的第二密钥。 步驟 707a, UE-B1将被叫密钥 K2和密钥更新参数 P1 , 以及 KDF包含 在 SDP Answer消息中通过 IMS网络返回给呼叫转移应用服务器。其中，如 果 P1选择为 K2 , 则消息中只包含 K2和 KDF。
步驟 708a~709a, 分叉呼叫应用服务器将该消息通过 IMS 网络返回给
UE-A。
步驟 710a, UE-A在收到该消息后基于主叫密钥 K1和收到的密钥更新 参数 P1 , 使用 KDF生成新的主叫密钥 Kal=KDF ( Kl , PI )0
步驟 706b-709b, UE-B2 生成 K3 (作为第二密钥材料）和 Ρ2, 使用 KDF生成 Ka2=KDF ( Kl , P2 ), Ka2作为 UE-B2与 UE-A之间的第二密钥； 其他过程与 706a-709a步驟相同， 不再累述。
步驟 710b, UE-A基于主叫密钥 Kl和收到的密钥更新参数 P2, 使用 KDF生成新的主叫密钥 Ka2=KDF ( Kl , P2 )0
步驟 711-713 , UE-B2应答， 通过网络向 UE-A发送 200 Ok消息。 步驟 714, UE-A和 UE-B2建立起端到端安全的加密媒体流通信， UE-A 使用 Ka2保护从 UE-A发给 UE-B2的媒体流， UE-B2可以使用 Ka2对 UE-A 发送的媒体流进行解密； UE-B2使用 K3 (即直接将第二密钥材料作为第三 密钥导出）保护从 UE-B2发给 UE-A的媒体流， UE-A可以使用 K3对 UE-B2 发送的媒体流进行解密。
UE-A和 UE-B2也可以均使用 Ka2保护其之间交互的媒体流， UE-B2 可以使用 Ka2对 UE-A发送的媒体流进行解密， UE-A可以使用 Ka2对 UE-B2 发送的媒体流进行解密。
以上所述， 仅为本发明的较佳实施例， 并非用于限定本发明的保护范 围。

Claims

权利要求书
1、一种实现端到端安全的密钥协商方法， 其特征在于， 该方法包括： 第二方生成第二密钥材料和密钥更新参数， 并根据所述密钥更新参 数、 以及第一密钥材料， 生成第二密钥；
第二方将生成的第二密钥材料和密钥更新参数传递给所述第一方； 所述第一方根据所述密钥更新参数、 以及所述第一密钥材料， 生成 所述第二密钥；
所述第一方使用所述第二密钥保护发送的媒体流。
2、 根据权利要求 1所述实现端到端安全的密钥协商方法， 其特征在 于， 该方法进一步包括：
选择生成的第二密钥材料作为所述密钥更新参数， 且当选择生成的 第二密钥材料作为密钥更新参数时， 所述第二方只将生成的第二密钥材 料传递给所述第一方。
3、 根据权利要求 1所述实现端到端安全的密钥协商方法， 其特征在 于， 该方法进一步包括：
所述第二方将密钥生成函数发送给所述第一方， 所述第一方和第二 方使用所述密钥生成函数生成第二密钥。
4、 根据权利要求 1所述实现端到端安全的密钥协商方法， 其特征在 于， 该方法进一步包括：
所述第一方和第二方分别使用各自预先配置的相同的密钥生成函 数， 根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密 钥。
5、 根据权利要求 1所述实现端到端安全的密钥协商方法， 其特征在 于， 该方法进一步包括：
所述第一密钥材料预先配置到所述第一方与所述第二方中， 或者所 述第一方生成第一密钥材料后传递给所述第二方。
6、根据权利要求 1至 5任一项所述实现端到端安全的密钥协商方法， 其特征在于， 该方法进一步包括：
所述第二方使用所述第二密钥、 或使用根据所述第二密钥材料导出 的第三密钥保护发送的媒体流。
7、一种实现端到端安全的密钥协商系统， 其特征在于， 该系统包括： 第一方和第二方，
所述第二方， 用于生成第二密钥材料和密钥更新参数， 并根据所述 密钥更新参数、 以及第一密钥材料， 生成第二密钥； 将生成的第二密钥 材料和密钥更新参数传递给所述第一方；
所述第一方， 用于根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密钥； 使用所述第二密钥保护发送的媒体流。
8、 根据权利要求 7所述实现端到端安全的密钥协商系统， 其特征在 于， 所述第二方进一步用于， 选择生成的第二密钥材料作为所述密钥更 新参数， 且当选择生成的第二密钥材料作为密钥更新参数时， 所述第二 方只将生成的第二密钥材料传递给所述第一方。
9、 根据权利要求 7所述实现端到端安全的密钥协商系统， 其特征在 于， 所述第二方进一步用于， 将密钥生成函数发送给所述第一方，
相应的， 所述第一方和第二方使用所述密钥生成函数生成第二密钥。
10、 根据权利要求 7所述实现端到端安全的密钥协商系统， 其特征 在于， 所述第一方和第二方分别使用各自预先配置的相同的密钥生成函 数， 根据所述密钥更新参数、 以及所述第一密钥材料， 生成所述第二密 钥。
11、 根据权利要求 7所述实现端到端安全的密钥协商系统， 其特征 在于， 所述第一密钥材料预先配置到所述第一方与所述第二方中， 或者 所述第一方生成第一密钥材料后传递给所述第二方。
12、 根据权利要求 7至 11任一项所述实现端到端安全的密钥协商系 统， 其特征在于， 所述第二方进一步用于， 使用所述第二密钥、 或使用 根据所述第二密钥材料导出的第三密钥保护发送的媒体流。
PCT/CN2011/085193 2011-06-22 2011-12-31 一种实现端到端安全的密钥协商方法及系统 WO2012174843A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110169683.X 2011-06-22
CN201110169683.XA CN102843660B (zh) 2011-06-22 2011-06-22 一种实现端到端安全呼叫转移的方法及系统

Publications (1)

Publication Number Publication Date
WO2012174843A1 true WO2012174843A1 (zh) 2012-12-27

Family

ID=47370664

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/085193 WO2012174843A1 (zh) 2011-06-22 2011-12-31 一种实现端到端安全的密钥协商方法及系统

Country Status (2)

Country Link
CN (1) CN102843660B (zh)
WO (1) WO2012174843A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105847225B (zh) * 2015-01-16 2019-02-05 中国移动通信集团公司 基于ip多媒体子系统的端到端的加密协商方法及装置
CN106850521A (zh) * 2016-04-18 2017-06-13 中国科学院信息工程研究所 一种端到端VoIP加密通信的密钥交换方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006106393A2 (en) * 2005-04-04 2006-10-12 Nokia Corporation Access management in a wireless local area network
CN101183935A (zh) * 2007-12-17 2008-05-21 华为技术有限公司 Rtp报文的密钥协商方法、装置及系统
CN101895877A (zh) * 2009-05-21 2010-11-24 华为技术有限公司 密钥协商方法、设备及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101102185B (zh) * 2006-07-06 2012-03-21 朗迅科技公司 Ims会话的媒体安全
CN101222320B (zh) * 2007-01-11 2011-02-16 华为技术有限公司 一种媒体流安全上下文协商的方法、系统和装置
US8301883B2 (en) * 2009-08-28 2012-10-30 Alcatel Lucent Secure key management in conferencing system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006106393A2 (en) * 2005-04-04 2006-10-12 Nokia Corporation Access management in a wireless local area network
CN101183935A (zh) * 2007-12-17 2008-05-21 华为技术有限公司 Rtp报文的密钥协商方法、装置及系统
CN101895877A (zh) * 2009-05-21 2010-11-24 华为技术有限公司 密钥协商方法、设备及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ALCATEL LUCENT ET AL.: "Corrections and clarifications in call set-up", 3GPP TSG SA WG3 SECURITY-S3#58 S3-100276, 1 February 2010 (2010-02-01), pages 4 - 6 *

Also Published As

Publication number Publication date
CN102843660B (zh) 2017-11-24
CN102843660A (zh) 2012-12-26

Similar Documents

Publication Publication Date Title
KR101501399B1 (ko) 종단간 암호화를 갖는 통신 시스템에서의 정책 라우팅 기반 합법적 인터셉션
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
US7382881B2 (en) Lawful interception of end-to-end encrypted data traffic
WO2015180654A1 (zh) 一种保密通信实现方法及装置
EP2124379B1 (en) A method and system for distributing secret keys of media stream
EP2426852B1 (en) Method and system for implementing secure forking calling session in ip multi-media subsystem
Wang et al. A dependable privacy protection for end-to-end VoIP via Elliptic-Curve Diffie-Hellman and dynamic key changes
CN101420413A (zh) 会话密钥协商方法、网络系统、认证服务器及网络设备
WO2011131055A1 (zh) 一种实现安全呼叫转移的方法、系统及装置
CN111756726A (zh) 一种支持国密算法的sip安全认证方法
CN104683098A (zh) 一种保密通信业务的实现方法、设备及系统
Wing et al. Requirements and analysis of media security management protocols
US20080109652A1 (en) Method, media gateway and system for transmitting content in call established via media gateway control protocol
US8924722B2 (en) Apparatus, method, system and program for secure communication
US10848471B2 (en) Communication apparatus, communication method, and program
WO2012174843A1 (zh) 一种实现端到端安全的密钥协商方法及系统
CN102752263B (zh) 一种实现端到端安全呼叫转移的方法及系统
KR101210938B1 (ko) 암호 통신 방법 및 이를 이용한 암호 통신 시스템
WO2008074226A1 (fr) Procédé pour négocier la clé secrète de session entre les points d'extrémité à travers des zones à multiples contrôleurs d'accès
CN104753869A (zh) 基于sip协议的通话加密方法
CN104753876A (zh) 灵活可控的通话加密方法
CN105763571A (zh) 基于sip的非对称语音加密
US20100002885A1 (en) Efficient multiparty key exchange
WO2011127765A1 (zh) 一种实现单一无线语音呼叫连续性安全的方法及系统
KR101078226B1 (ko) Ｓｒｔｐ 세션 중계를 위한 게이트웨이 시스템과 이를 이용한 리던던시 제공 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11868318

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11868318

Country of ref document: EP

Kind code of ref document: A1