WO2011041962A1 - 一种支持合法监听的端到端会话密钥协商方法和系统 - Google Patents

一种支持合法监听的端到端会话密钥协商方法和系统 Download PDF

Info

Publication number
WO2011041962A1
WO2011041962A1 PCT/CN2010/075904 CN2010075904W WO2011041962A1 WO 2011041962 A1 WO2011041962 A1 WO 2011041962A1 CN 2010075904 W CN2010075904 W CN 2010075904W WO 2011041962 A1 WO2011041962 A1 WO 2011041962A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
session
terminal
ilr
random number
Prior art date
Application number
PCT/CN2010/075904
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 WO2011041962A1 publication Critical patent/WO2011041962A1/zh

Links

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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications

Definitions

  • the present invention relates to the field of the Internet, and in particular, to an end-to-end session key negotiation method and system for supporting lawful interception. Background technique
  • IP-based Internet is an open network composed of networks of multiple countries and organizations. Therefore, if an end-to-end session is established, it is likely to need to go through multiple intermediate nodes (such as routers). Nodes may not be completely networked by the same country or organization, so for highly confidential sessions, there is a possibility of eavesdropping or modification by a third party illicit agency.
  • end-to-end encryption In order to prevent confidential information from being stolen or modified, people usually use end-to-end encryption to conduct conversations.
  • national laws often stipulate that the business carried out by telecommunications companies must be monitored by legitimate institutions. Therefore, if a telecom enterprise conducts IP-based end-to-end encryption services, it must also be able to support the functions that are legally monitored by legitimate organizations. In this way, if the end-to-end session key is independently negotiated by the user, the network cannot understand the content of the session key, and the lawful interception cannot be performed. Therefore, the network must participate in the session key negotiation process, so that the specific network node can also Knowing the information of the end-to-end session key can properly support lawful interception.
  • conferencing In addition to lawful interception, functions such as conferencing need to be considered in session key negotiation. For example, in a highly confidential environment, when using a session for a multi-party conference, it is required to assign a different key to each terminal participating in the conference, so in a conference session, the conference host needs to assign keys to multiple participants in turn. , only one key is generated relative to one session, and the number of keys negotiated by the conference session is more.
  • the current industry end-to-end key negotiation scheme includes several key negotiation methods such as Security Descriptions (SDES) and tickets (TICKET);
  • SDES includes the session key in the end-to-end signaling of UE A to UE B , so end-to-end signaling is required to be secure. Since end-to-end signaling security also requires key encryption, it also needs end-to-end Signaling key negotiation or piecemeal signaling key negotiation, and the requirements of these signaling key negotiation are as complex as media plane key negotiation. Therefore, SDES has certain limitations in deployment.
  • the TICKET key negotiation method is to pass a session key index in the end-to-end session establishment signaling by the terminal UE A , without directly transmitting the session key to the UE B , so that the session key is not used in the UE A and the UE B. The direct signaling is transmitted, eliminating the need for signaling encryption.
  • the TICKET key negotiation method is easier to implement on key delivery than SDES.
  • the key negotiation method of the TICKET key negotiation method is often performed independently with the signaling interaction.
  • KMS Key Management Server
  • the related key negotiation is very complicated and the implementation method is not uniform, which leads to the terminal and the key management server (Key Management Server (KMS) has more than 4 key negotiation scenarios, and the process is very complicated. It is not as convenient as SDES in transferring keys. This is the main disadvantage of the TICKET method.
  • KMS Key Management Server
  • the current implementation of the TICKET key negotiation method is based on the Generic Authentication Architecture (GAA)/Generic Bootstrapping Architecture (GBA), so it is necessary to deploy the GBA server.
  • GBA Generic Authentication Architecture
  • GBA Generic Bootstrapping Architecture
  • Otway-Rees TICKET is a representative algorithm is the algorithm, as shown in FIG first UE A and UE B establish a shared key KMS and K b, respectively, and by GBA method 8; UE A and the ID A and ID B encrypted with K a After forming E a (ID A , ID B ), it is sent to UE B ; UE B encrypts ID A and ID B with key K b to form E b (ID A , ID b ), and E A (ID A , ID B) and E b (ID A, ID B ) - starting to KMS; KMS respectively of K a and K b E a (ID A, ID B ) and E b (ID A, ID B ) decrypts, if decrypted ID a, ID B correctly, the KMS generates a session key K, respectively, and K a and K b is encrypted to generate E a (K) and E b (K) and sent to UE B; UE B de
  • 'Otway-Rees' the key is generated in the KMS, and UE A has no control over what key is assigned. In a multi-party session or conference session, if UE A needs to assign the same key to the peer. , is not possible in 'Otway-Rees'.
  • an E a (K) is obtained, denoted as El; if UE A and UE C talk, UE B intercepts between UE A and UE C in the 806 message.
  • E a ( K ) denoted as E2 . If UE B wants to implement a man-in-the-middle attack, E2 can be changed to El in the 806 message, and UE A and UE C communication are encrypted using E1, so UE B can decrypt UE A.
  • UE C data data.
  • the technical problem to be solved by the present invention is to provide a method for negotiating an end-to-end session key for legal interception, which can provide end-to-end encryption and meet the requirements of a legitimate organization for monitoring end-to-end sessions.
  • the present invention provides a method for supporting end-to-end session key negotiation for lawful interception.
  • the key negotiation process initiated by the first terminal to the session of the second terminal includes:
  • the first terminal performs session root key negotiation with its belonging first identity location register (ILR), and after generating the session root key K as of the current session and saving, the first terminal according to the first random number including the first random number generated by itself A parameter and K as generate a session key, and initiate an end-to-end session key request to the second terminal, where the carried key negotiation parameter includes the first ciphertext and the first ciphertext including the first random number information encrypted by K as Describe the first identification information of the session;
  • ILR identity location register
  • the second terminal sends the received key negotiation parameter directly to the first ILR when the first ILR belongs to the ILR, otherwise sends the second ILR through the second ILR to the first ILR; the first ILR uses the K as decryption Obtaining the first random number in a ciphertext, generating the session key in the same manner as the first terminal, saving the ciphertext, and directly sending the ciphertext to the second terminal, or sending the second ILR to the second ILR. Transmitting the session key to the second terminal in cipher text;
  • the second terminal decrypts the ciphertext, obtains a session key therein, and the first terminal and the second terminal use the session key to perform a session, and the session key includes a session encryption key.
  • the above method also has the following characteristics:
  • the first terminal and the first ILR are configured with a shared permanent root key K a , and the step of the first terminal performing the session root key negotiation with the first ILR to which the first terminal belongs includes:
  • the first terminal generates a second random number, and sends a session root key generation parameter including the second random number and the second identifier information of the session to the first ILR;
  • the first terminal generates K as in the same manner as the first ILR to complete the session root key negotiation.
  • the method further includes: when the two devices perform key negotiation, the integrity of the transmitted parameters is also verified.
  • the two devices include a first terminal and a first ILR, a second terminal and an ILR to which it belongs, and one or more of the first terminal and the second terminal.
  • the step of performing the session root key negotiation between the first terminal and the first ILR to which the first terminal belongs includes: when the first terminal sends the session root key generation parameter to the first ILR, the first authentication response is also delivered to the first ILR.
  • the first is the first terminal authentication response message to generate a temporary complete verification key K at least in part according to the session and K a root key generation parameter to at least partially session root key generation parameter is the third parameter, by using K at Calculated by the first integrity protection algorithm;
  • the first ILR after receiving the session root key generation parameter and the first authentication response, first generation parameter according to the stored root key K a session and received, to obtain a first authentication response to the same manner as in the first terminal calculated An authentication response is compared with the first authentication response. If the two are different, the authentication fails, and the key negotiation process of the session is ended. If the two are the same, the step of generating K as is performed.
  • the step of performing the session root key negotiation between the first terminal and the first ILR to which the first terminal belongs includes: when the first ILR sends the third random number to the first terminal, the second authentication response is further forwarded to the first terminal, where The authentication response is obtained by the first ILR according to K as and a fourth parameter including a third random number and at least part of the session root key generation parameter, by using a second integrity protection algorithm;
  • the method further includes: after the first terminal generates the K as , the first authentication response is calculated and compared with the second authentication response in the same manner as the first ILR obtains the second authentication response, and if the two are different, the authentication fails, and the method ends.
  • the key negotiation process of the session if the two are the same, performs the step of generating a session key.
  • the second identifier information includes a session index (SI) allocated by the first terminal for the session and a user identity (SID A ) of the first terminal;
  • SI session index
  • SID A user identity
  • the method further includes:
  • the session key is saved with the SI as an index.
  • the session root key generation parameter further includes a key derivable number, which is used to indicate a set number of times that the session key can be generated by utilizing K as ;
  • the step of performing the session root key negotiation between the first terminal and the first ILR to which the first terminal belongs includes: after the first ILR receives the session root key generation parameter, the number of times that the K as generates the session key is not exceeded in real time This key can be derived from the number of times.
  • the number of times the key can be deduced is 0, the number of times is not limited, and any number of session keys can be generated by using 1 ⁇ ; when the number of times the key can be deduced is 1, only one called party can be generated, and 1 ⁇ can be generated once.
  • the first ciphertext includes the first identification information encrypted with the K as and the first random number, where the first identification information includes the session index SI allocated by the first terminal for the session, and the user identity SID of the first terminal. A and second terminal user identity SID B .
  • the above method also has the following characteristics:
  • the first ciphertext generated by the first terminal further includes a third authentication response encrypted by the K as , the third authentication response being a fifth parameter of the first terminal according to the K as and the first identifier information and the first random number. Calculated by the third integrity protection algorithm;
  • the method further includes: receiving, by the first ILR, a key negotiation parameter sent by the second terminal, decrypting the first ciphertext according to the K as retrieved by the first identification information, and acquiring the first random parameter, first using Calculating an authentication response in the same manner as the first terminal obtains the third authentication response, and comparing with the third authentication response, if the two are different, the authentication fails, and the key negotiation process of the session ends, if the two are the same, and then executed.
  • the above methods also include:
  • the second terminal After the second terminal decrypts the ciphertext sent by the second ILR, obtains the session key, and then requests the first terminal to verify by using the key verification data, after the first terminal passes the verification, the first terminal and the second terminal are used again.
  • the session key generated by the first terminal further includes an integrity check key, where the integrity check key is generated by the first terminal according to K as and a parameter including the first random number;
  • the above methods also include:
  • the first ILR After receiving the key negotiation parameter, the first ILR generates the integrity check key in the same manner as the first terminal and sends the integrity check key to the second terminal;
  • the second terminal When the second terminal requests the first terminal to verify by using the key verification data, according to the received integrity check key and the sixth parameter including the first identification information, the first random number, and the fourth random number generated by itself, Calculating a fourth authentication response by using an integrity protection algorithm, and encrypting the fourth authentication response and the fourth random number with a session encryption key to generate key verification data, and transmitting the key verification data to the first terminal;
  • the first terminal decrypts the key verification data with the session encryption key to obtain a fourth authentication response and a fourth random number, and calculates an authentication response and the fourth authentication response in the same manner as the second terminal obtains the fourth authentication response. If the two are different, the verification fails, and the key negotiation process of the session is ended. When the two are the same, the verification is passed.
  • the above methods also include:
  • the first terminal When the first terminal serves as a calling terminal and a plurality of called terminals, the first terminal is initiated and the first one is When the session of the terminal is called, the session is negotiated with the first ILR to obtain the K as and saved, and the session initiated with the other called terminals directly generates the session key of each session according to the first random number generated by the K as and the corresponding session;
  • the first terminal negotiates with different called terminals to obtain different session keys by generating and transmitting different first random numbers for different called terminals; or, the first terminal generates and delivers the same number for different called terminals. A random number, negotiated with different called terminals to get the same session key.
  • the above methods also include:
  • the second terminal After receiving the key negotiation parameter sent by the first terminal, the second terminal generates a fifth random number, and sends the fifth random number together with the key negotiation parameter to the ILR to which the second terminal belongs, and the ILR to which the second terminal belongs. And storing first identifier information in the fifth random number and the key negotiation parameter;
  • the ILR to which the second terminal belongs After receiving or generating the session key, the ILR to which the second terminal belongs generates a sixth random number, according to the permanent root key K b shared with the second terminal, and the fifth random number, the sixth random number, and the second terminal.
  • the seventh parameter of the user identity identifier generates a temporary encryption key K bt , and after encrypting the eighth parameter including the session key by using K bt , the obtained ciphertext and the sixth random number are sent to the second terminal;
  • the second terminal After receiving the ciphertext and the sixth random number sent by the ILR to which the second terminal belongs, the second terminal generates K bt in the same manner as the ILR to which the second terminal belongs, and decrypts the ciphertext sent by the ILR with K bt to obtain the session key. .
  • the above methods also include:
  • the second terminal further sends the fifth authentication response together with the fifth random number and the key negotiation parameter to the ILR to which the second terminal belongs, the fifth authentication response is that the second terminal according to K b and includes the first identification information and the fifth
  • the parameters of the random number are calculated by the integrity protection algorithm
  • the ILR that belongs to the second terminal calculates an authentication response and compares it with the fifth authentication response in the same manner as the second terminal obtains the fifth authentication response. If the two are different, the negotiation fails, and the key negotiation process of the session is ended. If the first ILR is the ILR to which the second terminal belongs, the first ciphertext in the key negotiation parameter is decrypted. Otherwise, the key negotiation parameters are sent to the first ILR.
  • the eighth parameter that the second terminal belongs to the ILR encrypted by K bt further includes a sixth authentication response, where the fifth authentication response is that the second terminal belongs to the ILR according to the session encryption key and includes the fifth random number and the The parameters of the six random numbers are calculated by the integrity protection algorithm;
  • the above methods also include:
  • the second terminal decrypts the ciphertext sent by the ILR to which the second terminal belongs, and obtains the session encryption key, and then calculates an authentication response and the sixth authentication in the same manner as the third authentication response is obtained by the ILR to which the second terminal belongs.
  • the negotiation fails, and the key negotiation process of the session is ended. If the two are the same, the key verification data request is generated and sent to the first terminal. After the first terminal passes the verification, the first The terminal and the second terminal then use the session key to conduct the session.
  • the present invention also provides a system for supporting end-to-end session key agreement for lawful interception, the system comprising a terminal and an identity location register (ILR);
  • ILR identity location register
  • the terminal includes a calling key negotiation module and a called key negotiation module, and the calling key negotiation module includes a terminal session root key negotiation unit and a terminal session key generation and sending unit; the called key negotiation module The key agreement parameter transceiver unit and the session key acquisition unit are included;
  • the ILR includes a calling home key agreement module and a called home key agreement module, and the caller home key agreement module includes an ILR session root key agreement unit and an ILR session key generation and sending unit;
  • the terminal session root key negotiation unit is configured to: perform session root key negotiation with the ILR session root key negotiation unit to which the terminal belongs, generate a session root key K as of the current session, save, and send Giving the terminal session key generation and sending unit;
  • the terminal session key generation and sending unit is configured to: after receiving the session root key K as , generate a session key according to the first parameter and K as including the first random number generated by itself, and send the session key to the key
  • the negotiation parameter transceiver unit sends a key negotiation parameter to initiate an end-to-end session key request, where the key negotiation parameter includes a first ciphertext including the first random number information and a first identifier of the session obtained by using K as encryption.
  • the session key includes a session encryption key;
  • the key negotiation parameter transceiver unit is configured to: send the received key negotiation parameter to the called home key negotiation module;
  • the session key obtaining unit is configured to: decrypt the ciphertext sent by the called home key negotiation module, and obtain the session key therein;
  • the ILR session root key negotiation unit is configured to: perform session root key negotiation with the terminal session root key negotiation unit, generate a session root key K as of the current session, and save the session root The key K as is sent to the ILR session key generation and sending unit;
  • the ILR session key generation and sending unit is configured to: decrypt the first ciphertext sent by the called home key negotiation module by using the K as sent by the ILR session root key negotiation unit, to obtain the first random And generating a session key in the same manner as the terminal session key generation and sending unit, and saving the same, and then sending the session key to the called home key negotiation module;
  • the called home key negotiation module is configured to: send a key negotiation parameter sent by the key negotiation parameter transceiver unit to the ILR session key generation and sending unit, and generate the ILR session key
  • the session key sent by the sending unit is encrypted and generated to be sent to the session key obtaining unit.
  • the terminal session root key negotiation unit and the ILR session root key negotiation unit are configured with a shared permanent root key K a ;
  • the terminal session root key negotiation unit is configured to perform session root key negotiation with the ILR session root key negotiation unit to which the terminal belongs in the following manner: generating a second random number, and to the ILR session root
  • the key agreement unit transmits a session root key generation parameter including the second random number and the second identification information of the session; and generates K as in the same manner as the ILR session root key negotiation unit, completing the session root key Negotiation process
  • the ILR session root key negotiation unit is configured to perform session root key negotiation with the terminal session root key negotiation unit in the following manner: after receiving the session root key generation parameter, according to and including the second random number the second parameter of the first and second identification information generated by the third random number ILR after K as generated by the key generation algorithm and stores the first mapping relation with K as second identification information, the third random number will be returned Giving the terminal a session root key negotiation unit.
  • the equipment includes the ILR to which the calling terminal and the calling terminal belong, and the called terminal and the called terminal belong to the ILR, and one or more of the calling and called terminals.
  • the second identifier information includes a session index (SI) allocated by the terminal session root key negotiation unit for the session and a user identity (SID A ) of the terminal;
  • SI session index
  • SID A user identity
  • the terminal is also configured to: allocate different SIs for each session, and generate different K a for each session through the session root key negotiation process;
  • the session key is saved with the SI as an index.
  • the first ciphertext includes a first identification information encrypted with K as and a first random number, where the first identification information includes a session index SI allocated by the terminal for the session, a user identity SID A of the calling terminal, and The user identity of the called terminal is SID B .
  • the calling key negotiation module further includes a calling key verification unit, and the called key negotiation module further includes a called key verification unit;
  • the session key obtaining unit is further configured to: send a session key to the called key verification unit;
  • the called key verification unit is configured to: generate key verification data according to the session key, and send the key verification unit to the calling key verification unit;
  • the calling key verification unit is configured to: verify the session key by the key verification data.
  • the session key further includes an integrity check key, which is generated by the terminal session key generation and transmission unit and the ILR session key generation and transmission unit, according to K as and The parameter of the first random number is generated;
  • the called key verification unit is configured to: pass the integrity according to the received integrity check key and the sixth parameter including the first identification information, the first random number, and the fourth random number generated by itself.
  • the protection algorithm calculates a fourth authentication response, and uses the session encryption key to respond to the fourth authentication and the fourth After the number of machines is encrypted, key verification data is generated and sent to the calling key verification unit;
  • the calling key verification unit is configured to: decrypt the key verification data by using a session encryption key to obtain a fourth authentication response and a fourth random number, and calculate in the same manner as the second terminal obtains the fourth authentication response. An authentication response is obtained and compared with the fourth authentication response. If the two are different, the verification fails, and the key negotiation process of the session is ended. When the two are the same, the verification is passed.
  • the terminal acts as a calling terminal and a plurality of called terminals
  • the terminal session root key negotiation unit initiates a session with the first called terminal
  • the terminal negotiates with the ILR session root key negotiation unit.
  • Obtaining K as and saving, and then the session initiated with the remaining called terminals directly generates a session key of each session according to the first random number generated by the K as and the corresponding session;
  • the calling terminal negotiates with different called terminals to obtain different session keys by generating and transmitting different first random numbers for different called terminals; or, the first terminal generates and delivers the same by using different called terminals.
  • the first random number negotiated with different called terminals to get the same session key.
  • the called home key agreement module and the session key obtaining unit are configured with a shared permanent root key K b:
  • the key negotiation parameter transceiver unit is further configured to: after receiving the key negotiation parameter, generate a fifth random number, and send the fifth random number together with the key negotiation parameter to the called home key negotiation module, where the The home key negotiation module is further configured to: save the first identifier information in the fifth random number and the key agreement parameter sent by the key negotiation parameter transceiver unit; and receive and send the ILR session key After the session key sent by the unit, generating a sixth random number, generating a temporary encryption key K bt according to K b and a seventh parameter including a fifth random number, a sixth random number, and a user identity of the called terminal, After K bt encrypts the eighth parameter including the session key, the obtained ciphertext and the sixth random number are sent to the session key obtaining unit;
  • the session key obtaining unit is further configured to: after receiving the ciphertext and the sixth random number sent by the called home key negotiation module, generate K bt in the same manner as the called home key negotiation module, K bt decrypts the ciphertext sent by the called home key negotiation module to obtain the session key.
  • the above methods and systems provide end-to-end encryption as well as the need for legitimate organizations to listen to end-to-end sessions.
  • the present invention avoids different processes in the key negotiation process according to different session scenarios.
  • the method for preventing man-in-the-middle attacks is greatly improved, the security of session key delivery is improved, and multiple pairs of the same session can be used.
  • the same key is allocated at the end, which improves the performance of the terminal caused by different keys in multi-session.
  • Otway-Rees needs to establish a shared key by means of the GBA/GAA process in the key negotiation.
  • the embodiment of the present invention uses a permanent shared key mode, which is simpler in actual operation and deployment.
  • the TICKET transmitted from UE A to UE B is encrypted with the same shared root key K a each time.
  • the TICKET is encrypted with the session root key £ ⁇ , each time The E Kas generated by the session are different, thus avoiding the middleman collecting the shared root key K a and cracking K a ;
  • the Otway-Rees key is generated in the KMS, and the calling party does not have the control right of the key negotiation. Therefore, in the case of a multi-party session and a conference call, multiple terminals cannot use the same session key, so the calling party needs to encrypt and decrypt multiple Calling the media stream of the terminal, performance will become a bottleneck.
  • An embodiment of the present invention first negotiates a session root key, and subsequent callers can transmit the same or different random numbers to form the same or different session keys, which improves the encryption and decryption performance of the calling party;
  • the session key is passed from the KMS to the UE B , and then to the UE A by the UE B.
  • Session key to an embodiment of the present invention are independently generated in UE A and ILR, the key is completely help UE A UE B to UE A or UE B to UE A transmission, reducing the session key is transmitted to the UE B The possibility of being stolen, cracked and modified during UE A ;
  • the session key is passed from UE B to UE A , and there is no integrity check. Therefore, if the last generated session key is modified or replaced by an intermediary, UE A cannot be perceived; In the case, this defect was overcome;
  • the KMS In Otway-Rees, the KMS generates a session key K, and K a and K respectively B encryption, to generate E a (K) and E b (K) and sent to UE B, UE B to give both the session key K , also obtain E a ( K ) encrypted with K a for K. If UE B repeatedly sends a key message to the KMS, it will get one. Series: ⁇ and £ & ( K ) comparison table, it is easy to be broken by UE B. In an embodiment of the present invention, since the data is not transmitted to the UE B without K a encryption, and each time the session key is used, it is impossible for the UE B to initiate a similar attack.
  • FIG. 1 is a schematic structural diagram of a system according to an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of a scenario of multi-party session key negotiation according to an embodiment of the present invention.
  • FIG. 4 is a schematic diagram of an application scenario of a key negotiation in a conference session according to an embodiment of the present invention
  • FIG. 5 is an example of a single-party call negotiation parameter according to an embodiment of the present invention
  • FIG. 8 is a signaling flowchart of Otway-Rees key negotiation in the prior art
  • FIG. 9 is a diagram of a system function module in an embodiment of the present invention.
  • FIG. 1 is a schematic diagram of a system architecture of the present embodiment, where the system includes User Equipment (UE): UE A and UE B ; Access Server Node (ASN): ASN1 and ASN2; and identity location register ( Identification Location Register, ILR ): ILR A and ILR B.
  • UE User Equipment
  • ASN Access Server Node
  • ILR Identification Location Register
  • the data link between the UEA and the UEB is an insecure link, such as an IP link, so the session key between UE A and UE B cannot be transmitted in plain text, because UE A may be among hundreds of millions of other users at any time.
  • the access server also referred to as an access service node, is a logical entity. To provide access to the IP network, it can be a serving general packet radio service (GPRS) support node (Serving GPRS). Support Node, SGSN), Gateway GPRS Support Node (GGSN), Packet Data Serving Node (PDSN), and Broadband Remote Access Server (BRAS).
  • GPRS general packet radio service
  • Support Node SGSN
  • GGSN Gateway GPRS Support Node
  • PDSN Packet Data Serving Node
  • BRAS Broadband Remote Access Server
  • the ILR is a logical entity that undertakes the management and negotiation of the end-to-end key and stores the node information of the user terminal.
  • it may be a KMS, a Home Location Register (HLR), or a home subscriber server (Home). Subscriber Server, HSS), Authorization, Authentication, Accounting, AAA, or other entity that undertakes end-to-end key management and negotiation functions.
  • the session key is generated and delivered by two user terminals, UE A and UE B, and two ILRs, ILR A and ILR B , which solves the problem of lawful interception well.
  • FIG. 2 shows the basic flow of key negotiation in this embodiment, among the four network nodes involved.
  • the Subscriber Identification (SID) of UE A and UE B are SID A and SID B respectively . Furthermore, there is shared between the UE A and the ILR A permanent root key K a, the presence of the permanent root key shared between the UE B and K b ILR B; includes a plurality UE A and the UE B and ILR A and ILR B
  • the security algorithm includes: an encryption algorithm, an integrity protection algorithm, a key generation algorithm, and the like; and the security algorithm can use the security algorithm in the prior art, which is not limited in this embodiment.
  • the encryption algorithm may be an algorithm such as DES, 3DES, or AES, and the integrity protection algorithm includes an algorithm such as MD5 and SHA-1; the key generation algorithm is generally formulated by an operator, and may be a specific algorithm.
  • the key negotiation process of the first terminal initiating the end-to-end session to the second terminal in this embodiment includes the following steps:
  • the first terminal and the first ILR of the home location perform session root key negotiation, and the session root key K as of the session is generated by using the shared permanent root key K a and saved, the first terminal generates
  • the first random number is a parameter
  • the session key is generated by using K as
  • the end-to-end session key request is initiated to the second terminal
  • the carried key negotiation parameter includes the first random number information obtained by using K as encryption.
  • step (1) is further divided into the following steps:
  • Step 201 The first terminal UE A generates a random number RAND A , and sends a session root key generation parameter to the ILR A , including a random number RANDA and a session index (SI) and SID A ;
  • UE A may send the above parameters to ILR A through a "session root key negotiation request”message;
  • SI and SID A UE A is initiated by the identification information session, a session initiated by A uniquely identifies the UE.
  • the SI is a fixed-length integer, such as 16-bit or 32-bit length, and is allocated by the UE A to uniquely identify the session currently initiated by the UE A. Each time a new session is established, the SI should be assigned a different integer. The limit value can be used in zero.
  • SI is a 16-bit integer, for example, UE A each build a new session, may be added to the corresponding SI 1, SI if exceeds 65535, it is automatically reset to 0.
  • a session root key K as different from other sessions is established for each session.
  • an index number SI is used to distinguish the current session. Which session the session key of the key negotiation belongs to, the communication parties can distinguish which session is based on the SI, thereby finding the session root key K as of the session, that is, the end-to-end negotiation between the UE A and the peer session, tell the other particular preclude the use of SI which generates a session key using a session root key K as; in another embodiment, if the non-secure channel, UE a a transmitted between the UE a and the ILR ILR a session When the root key generates parameters, the authentication response RES A can also be passed to ILR A at the same time, and the integrity check is performed with RES A to ensure that the data received by ILR A comes from UE A , ensuring that ILR A is not affected by the intermediary modifying RANDA. Attack, specifically:
  • UE A encapsulates the RES A and session root key generation parameters into a "session root key negotiation request" message and sends it to the authentication server ILR A .
  • the session root key generation parameters are not necessarily RAND A , SID A , SI, but also include other parameters (see below).
  • the session root key generation parameter may further include a Key Derived Number (KDN); the KDN is used to indicate that the session secret can be generated by using each session root key K as The number of times the key is specified by UE A and passed to ILR A. The number of times the ILR A real-time control key K as generates the session key does not exceed KDN.
  • KDN Key Derived Number
  • KDN is 0, the number of times is not limited, K as can be used to generate any session key; 1 means there can be only one called, 1 ⁇ can be used to generate a session key; n means there can be only n fixed The called, K as can be used to generate n session keys, and n is an integer greater than one.
  • the correspondence between the value of the KDN and the number of session keys generated by the KDN is not limited thereto;
  • KDN can enhance the security of key distribution and is used to limit the number of keys generated by the session root key when a conference session is restricted.
  • UE A may further specify a session root key in addition to the KDN.
  • the lifetime of K as is added to the session root key generation parameter passed to ILR A.
  • the lifetime indicates the time that K as can be used. After the lifetime is reached, the lifetime of K as ; K as can be deleted.
  • the method of delivery and use is the same as KDN, and will not be repeated here.
  • Step 202 After receiving the session root key generation parameter, the ILR A generates a random number.
  • ILR A UE A After ILR A UE A receives the parameters transmitted may be based on the shared key K a of SID A retrieval UE A and ILR A permanent roots, you may be informed that the root key K a permanent manner by another;
  • the ILR A UE A receives the authentication response transmitted RES A, generates a random number before ILR A RANDILRSA, the first integrity check authentication response RES A, specifically:
  • ILR A first RES A by the same manner as the UE A to give the calculated XRES A, in particular, ILR A root key generation parameter to the session as a parameter, and the UE A using the permanent ILR A shared root key K a, through the dense
  • ILR A and UE A can pre-agreed algorithms to be commonly used, such as key generation algorithm fl0, integrity protection algorithm fl l, key generation algorithm fl2, integrity protection algorithm fl3, encryption key generation algorithm fl4, complete Sex protection algorithm fl6 and encryption algorithm fl7.
  • key generation algorithm fl0 integrity protection algorithm fl l
  • key generation algorithm fl2 integrity protection algorithm fl3
  • encryption key generation algorithm fl4 complete Sex protection algorithm fl6 and encryption algorithm fl7.
  • the same type of algorithms with different markings above may be the same or different.
  • Step 203 UE A uses the RANDn ⁇ A and the session root key generation parameter as parameters, and uses the shared permanent root key K a to calculate the session root key K as by the key generation algorithm fl2, and then generates a random number ANDA2 B .
  • the session key is generated by using the session root key K AS , including generating the session encryption key K abENC by using the encryption key generation algorithm f! 4, and maintaining the index by SI.
  • the session key is stored.
  • the session key parameters (including the ciphertext E Kas ⁇ SID A , SID B , SI ) are sent to UE B together;
  • UE A and ILR A generate K AS in the same way.
  • the same way is to use the same parameters, keys and algorithms.
  • the establishment session key request parameters include SI, SID B , SID A, and RANDA2 B .
  • the parameter for generating the session key may further include other parameters that are only related to the UE A and are not related to the UE B , such as SID A , SI, and the like;
  • the key negotiation process can be performed independently or in combination with the session establishment process.
  • the former is used to modify the key during the session, etc., and the latter is mostly used for initial establishment of the session.
  • the terminal first initiates "establishing an end-to-end session key request" before the session, so this step
  • the key negotiation parameters in the middle can be carried in UE B in the "establishing an end-to-end session key request".
  • the session key may further include an integrity check key K ABINT , and the UE A generates the same parameter of the session encryption key K ABENC , such as RANDA2 B , and uses K AS to pass the integrity check key.
  • the key generation algorithm fl5 is generated.
  • the UE A receives the authentication response RESEDA in the "Session Root Key Agreement Response" message.
  • the UE uses the session root key generation parameter and RANDn ⁇ A as parameters, and uses the session root key K AS to calculate the authentication response XRESJLR2A through the integrity protection algorithm fl3; compares whether RESEDA and XRESJLR2A are equal, if not equal, indicating that there is a middleman Modify the data, the key negotiation fails; if they are equal, start generating the random number RANDA2 B ;
  • UE A further includes an authentication response RESA2B in the parameter for generating the ciphertext E KAS ; that is, UE A uses the session root key K AS by establishing a session key request parameter as a parameter.
  • the authentication response RESA2B is calculated by the integrity protection algorithm fl6, and then the session response key RESMB and the establishment session key request parameter are used as parameters, and the session root key K AS is used to encrypt Algorithm fl7 generates ciphertext E KAS .
  • each caller in a conference session may have multiple called parties, such as a conference bridge in a conference call, and multiple The peer generates a session, and the key between each caller and the called party may be the same or different.
  • the end-to-end key management control right is in the calling terminal UE A , and UE A can negotiate differently with different called terminals by generating and transmitting different RANDA2 Bs for different called terminals.
  • the session key by generating and delivering the same RANDA2 B for different called terminals, can negotiate the same session key with different called terminals.
  • UE A may be allocated for UE B.
  • the RANDA2C allocated to UE C is also equal to 0001, and the session key assigned by UE A and UE B and UE A and UE C will be the same; but if it is allocated for UE B For the UE c , the last generated UE A and UE B and the session keys of UE A and UE C will be different.
  • UE A can assign the same key to different peers of each session by assigning the same or different random number RANDA2 B to the peer, and can also assign different keys, which is very satisfactory.
  • RANDA2 B random number assigned to the peer
  • the second terminal sends the received negotiation parameter to the first ILR through the second ILR, the first ILR decrypts the first ciphertext by using the K AS to obtain the first random number, and then generates the session in the same manner as the first terminal. Key and save, and then send the session key to the second ILR, the second ILR saves the session key and sends the session key to the second terminal in cipher text;
  • step (2) specifically includes:
  • Step 204 After receiving the ciphertext E KAS and SID A , SID B and SI sent by the UE A , the UE B generates a random number RANDB, and saves the random number RAND B in the UE B by using the SI as an index, and then and transmitting the ciphertext E KAS SID A, SIDB, SI, and a random number RAND B together to ILR B;
  • the UE B may obtain the ciphertext E Kas ⁇ o SID A , SID B by obtaining an end-to-end key request message.
  • the UE B saves the RAND B , and further includes: the UE B uses RAND B , SID B , SID A , and SI as parameters.
  • Step 205 ILR B sends ciphertext E KAS and SID A , SID B , SI to ILR A ;
  • Step 206 ILR A search by SI and SID A root key K AS to the session, using the session root key K AS E KAS ciphertext is decrypted by the decryption algorithm corresponding to the encryption algorithm fl7 obtain RANDA2 B, and in the UE A Generating a session key in the same way as generating a session key, including the session encryption key K ABENC , and sending the session key to ILR B and sending it to ILR B ;
  • the session key is generated in the same manner as the UE A generates the session key, and the same key is used to generate the session key by using the same key generation algorithm, such as using RANDA2 B as a parameter.
  • the session root key K AS generates a session key;
  • ILR A can send the session key to ILR B by obtaining an end-to-end session key response message; in addition, the session key can also include the integrity check key K ABINT , ILR A takes RANDA2 B as a parameter, with K AS Generated by the integrity check key generation algorithm fl5.
  • the ILR A performs the following processing before generating the session key: ILR A takes the session key request parameter as a parameter, and utilizes the session root secret.
  • Step 207 ILR B generates a random number And at RAND B, SID B as a parameter using the shared between the UE B and ILR B permanent root key K B, the temporary encryption between ILR B and UE B is calculated by the key generation algorithm fl9 key K BT, Then, using RANDILJ ⁇ B and the session key as parameters, using the temporary encryption key K BT , the ciphertext E KBT is calculated by the encryption algorithm £21, and then the ciphertext E KBT and the random number RANDIL ⁇ B are sent to the UE B ;
  • the ILR B may send the encrypted session key and the random number RANDIL ⁇ B to the UE B by acquiring an end-to-end key response message;
  • the ILR B may also generate a ciphertext by using only the session key as a parameter;
  • the parameter for calculating the ciphertext E KBT may further include an authentication response.
  • the authentication response RESIRR2B is calculated by using the temporary encryption key K BT and the integrity protection algorithm GO by using the session key, RAND B as a parameter.
  • the session key includes the session encryption key, and may further include the session integrity. Sexual key.
  • the second terminal decrypts the ciphertext sent by the second ILR, obtains the session key, and requests the first terminal to verify by using the key verification data. After the first terminal passes the verification, the first The terminal and the second terminal use the session key to conduct a session.
  • step (3) specifically includes:
  • Step 208 UE B uses RAND B.
  • the SID B is a parameter
  • the temporary encryption key K BT is generated by the key generation algorithm fl9 using the permanent root key K B ; and then the temporary encryption key K BT is used to transmit the ILR B by the decryption algorithm corresponding to the encryption algorithm £21.
  • the ciphertext E KBT decrypts, extracts the session key, and then generates key check data and sends it to UE A ;
  • the key negotiation process can be performed independently or in combination with the session establishment process.
  • the UE B when the session is successfully established, the UE B returns a response message of "establishing an end-to-end session key response" to the UE A , so that the parameters related to the key negotiation carried in this step are all It can be carried to UE A in the "Build End-to-End Session Key Response" message.
  • the key verification data may be: UE B generates a random number RAND B2A , and SI, SID B , SID A , RANDA2 B , RAND B2A is a parameter, using the integrity check key K ABINT , the authentication response RES B2A is generated by the integrity protection algorithm £22; the session encryption key K ABENC is used by the RAND B2A and the authentication response RES B2A as parameters.
  • the key verification data E KABENC is generated by the encryption algorithm £23, and the key verification data E K abENC is sent to the UE A ;
  • the decrypted data further comprises authentication response RESILR2B
  • UE B before generating the key verification data further comprising the step of RESJLR2B integrity check, in particular: UE B to generate the ILR B RESILRSB
  • the authentication response XRESJLR2B is calculated by the integrity protection algorithm £20, ie F20 Kb t(K abENC , K a blNT, RANDB), judges whether RESJLR2B is equal to XRESJLR2B. If they are equal, it indicates that it has not been modified by the intermediary, and continues to execute the step of generating key verification data £ 10 ⁇ 1 ⁇ ; otherwise, the key negotiation fails.
  • Step 209 After receiving the key check data, UE A checks the key check data. If the check passes, UE A and UE B can use the session key to perform the session.
  • UE A K ABENC 23 with the corresponding decryption algorithm to obtain the RAND B2A decrypted by the encryption algorithm E KABENC £, to SI, SID B, SID A,
  • UE A correctly transmits the session key to UE B , and both ILR a and ILR B know the actual session key between UE A and UE B , so that even UE A and UE B are used.
  • the key encrypts the data stream, and ILR A and ILR B can also decrypt it, thus satisfying the need for lawful interception.
  • the authentication server ILR A of UE B and the authentication server ILR B of UEA may be the same, in which case both users UE A and UE B are assigned and managed by ILR A , so that Step 205 and step 206 in FIG. 2 may be combined to generate a key K abINT , K abENC directly after ILR A receives the message of step 204, and send the message to UE B through step 207.
  • the step (2) can be corrected to: the second terminal sends the received key negotiation parameter to the first ILR, and the first ILR uses the K as decryption first ciphertext to obtain the first random number, and then the first terminal The session key is generated and saved in the same manner, and the session key is sent to the second terminal in a cipher text manner;
  • FIG. 3 shows an application scenario of conference session key negotiation.
  • UE A is the master of the conference, and UE A , UE C, and UE D successfully access and pass through ASN1, ASN3, and ASN2 respectively.
  • Authentication when the user UE A needs to initiate a multi-party encryption session of the UE A and the UE C and the UE D , the UE A may negotiate the session key with the UE C and the UE D in turn, or the UE A negotiates the session secret with the UE D and the UE C in sequence. key. Which order is used depends on the order in which UE A initiates session services.
  • ILR A negotiates the session root key K as .
  • UE A and the second peer or the third and fourth peers negotiate the key, since K as has been generated, UE A does not need to negotiate with ILR A again.
  • the root key K as that is, when UE A negotiates the session key with the other peers after the first peer, the messages in steps 201-202 are no longer needed.
  • UE A when UE A needs to initiate a 305, 306 conference session to UE C and UE D at the same time, UE A negotiates the session key with UE C for the first time, because the session root key K as has not been generated yet, UE A and ILR A need to negotiate the session root key K as through messages 201 to 202. Since UE A and UE C belong to the same ILR A , subsequent session negotiation does not require 205 ⁇ 206 messages, and finally UE A only needs 201 - 204, 207, 208 can establish a session key with UE C. When UE A and UE D negotiate the session key, since the session root key 1 ⁇ already exists, the 201 ⁇ 201 message is no longer needed. However, since UE A and UE D do not belong to the same ILR, 205 ⁇ 206 messages are needed. Finally, UE A only needs 203 ⁇ 208 messages and UE D establishes a session key.
  • FIG 4 is a scenario of a key negotiation application for a multi-party conference session through the conference bridge CB.
  • CB is the master of the conference.
  • CB, UE A , UE C, and UE B pass ASN1 and ASN1 respectively.
  • ASN3 and ASN2 are connected.
  • CB, UE A , UE C, and UE B interact with ILR A , ILR A , ILR A , and ILR B through 401, 402, 403, and 404 messages, respectively, to perform access authentication.
  • the CB Before the CB initiates a multi-party encryption session, the CB has obtained information such as the number of participants, whether each participant independently assigns a key, and the like, and then the CB first negotiates the session key with the UE A through the messages 201-204, 207, 208. Then, based on the negotiated session root key, the CB negotiates the session key with the UE C through 203, 204, 207, and 208, and finally negotiates the session key with the UE B through 203 to 208.
  • Figure 5 is an example of parameters for session key negotiation during a single-party call (see Figure 1 for an architecture diagram of the key negotiation).
  • the number of random numbers RANDA2 B here is only indicated. In practice, the random number may be 128 bits, 256 bits or other lengths.
  • Figure 6 is an example of parameters for session key negotiation during multi-party call (see Figure 3 for the implementation architecture of this figure).
  • UE A wants UE A and UE C and UE A and UE D to negotiate both ends.
  • RANDA2 B can be used to negotiate the same random number with the first one, so that two end-to-end connections negotiated from UE A Will have the same session key.
  • the random number length of the random number RANDA2 B herein is also only an indication. In practical applications, the random number may be 128 bits, 256 bits or other lengths.
  • FIG. 7 is an example of parameter negotiation when a multi-party conference call is implemented by using the conference bridge CB (the implementation architecture of this figure can be referred to FIG. 4 ).
  • the random number assignment of the three end-to-end branch calls is different, indicating the three-way call in the conference. It is called separate encryption, so that when any one of the way is cut off, others will not be able to use the same key to eavesdrop, and the security is better.
  • the CB can also use the same random number for the three branch calls, so that the three end-to-end session keys will be the same, which can reduce the encryption and decryption processing load of the conference bridge CB.
  • the embodiment further provides a system for supporting end-to-end session key negotiation of lawful interception.
  • the system includes a terminal and an ILR;
  • the terminal includes a calling key negotiation module and a called key negotiation module, and the calling key negotiation module further includes a terminal session root key negotiation unit and a terminal session key generation and sending unit; the called key negotiation module includes a key Negotiating a parameter transceiver unit and a session key acquisition unit;
  • the ILR includes a calling home key negotiation module and a called home key negotiation module, and the calling home key negotiation module is further divided into an ILR session root key negotiation unit and an ILR session key generation and sending unit;
  • the terminal session root key negotiation unit is configured to perform session root key negotiation with the ILR session root key negotiation unit to which the terminal belongs, generate the session root key K as of the current session, save it, and send it to the terminal session key generation. And sending unit;
  • the terminal session key generation and sending unit is configured to: after receiving the session root key K as , generate a session key according to the first parameter including the first random number generated by itself and K as , and negotiate parameters with the key
  • the transceiver unit sends a key negotiation parameter to initiate an end-to-end session key request, where the key negotiation parameter includes a first ciphertext containing the first random number information and a first identification information of the session obtained by using K as encryption;
  • the key includes a session encryption key;
  • a key negotiation parameter transceiver unit configured to send the received key negotiation parameter to the called home key negotiation module
  • a session key obtaining unit configured to decrypt the ciphertext sent by the called home key negotiation module, and obtain the session key therein;
  • ILR root session key negotiation means for performing a session key negotiation with the terminal session root root key negotiation unit, the session key K as raw root sessions and save costs, it will be sent to the root key K as ILR Session key generation and sending unit;
  • An ILR session key generation and transmission unit for transmitting by using an ILR session root key negotiation unit
  • the obtained K as decrypts the first ciphertext sent by the called home key agreement module, acquires the first random number, and generates the session key in the same manner as the terminal session key generation and sending unit, and saves the session key. , sent to the called home key negotiation module;
  • the called home key negotiation module is configured to send the key negotiation parameter sent by the called key negotiation parameter transceiver unit to the ILR session key generation and transmission unit, and send the ILR session key generation and sending unit
  • the session key is encrypted and sent to the session key acquisition unit.
  • the terminal session root key negotiation unit and the ILR session root key negotiation unit are configured with a shared permanent root key K a ;
  • the terminal session root key negotiation unit is configured to generate a second random number and send the second random number to the ILR session root key negotiation unit when performing the session root key negotiation with the ILR session root key negotiation unit to which the terminal belongs. a session root key generation parameter of the second identification information of the session; and generating K as in the same manner as the ILR session root key negotiation unit, completing the session root key negotiation process;
  • the ILR session root key negotiation unit performs the session root key negotiation with the terminal session root key negotiation unit, and is configured to: after receiving the session root key generation parameter, according to and including the second random number and the second identifier information after a first and a second parameter ILR a third random number generated, by first generating a key generation algorithm ⁇ and storing the second identification information with the mapping relation ⁇ K a, the third random number back to the terminal session secret root Key negotiation unit.
  • the two devices When two devices with signaling interactions are insecure links during the key negotiation process, the two devices also check the integrity of the transmitted parameters when performing key negotiation.
  • the two devices include the master.
  • the ILR to which the terminal and the calling terminal belong the ILR to which the called terminal and the called terminal belong, and one or more of the calling terminal and the called terminal.
  • the second identifier information includes a session index (SI) allocated by the terminal session root key negotiation unit for the session and a user identity (SID A ) of the terminal.
  • SI session index
  • SID A user identity
  • the session key is saved with the SI as an index.
  • the first ciphertext includes the first identification information encrypted with the K as and the first random number, where the first identification information includes the session index SI allocated by the terminal for the session, the user identity SID A of the calling terminal, and The user identity of the called terminal is SID B .
  • the above-mentioned calling key negotiation module further includes a calling key verification unit, and the called key negotiation module further includes a called key verification unit;
  • the session key obtaining unit is further configured to send the session key to the called key verification unit;
  • the called key verification unit is configured to generate key verification data according to the session key, and send the key verification data to the calling secret Key check unit
  • the session key further includes an integrity check key, the integrity check key is the terminal session key generation and transmission unit and the ILR session key generation and transmission unit, according to K as and include Generated by a parameter of a random number;
  • the called key verification unit When the called key verification unit sends the key verification data to the calling key verification unit, it is based on the received integrity check key and includes the first identification information, the first random number, and the self.
  • the sixth parameter of the generated fourth random number is calculated by the integrity protection algorithm to obtain a fourth authentication response, and the fourth authentication response and the fourth random number are encrypted by the session encryption key to generate key verification data, and sent to the main Called the key verification unit;
  • the calling key verification unit decrypts the key verification data with the session encryption key to obtain a fourth authentication response and a fourth random number, and calculates an authentication response in the same manner as the second terminal obtains the fourth authentication response. Compared with the fourth authentication response, if the two are different, the verification fails, and the key negotiation process of the session is ended. When the two are the same, the verification is passed.
  • the terminal session key negotiation unit When the terminal as a calling terminal and a plurality of session called terminal, when the terminal session key negotiation unit initiates a session with the root of a called terminal, negotiate with the negotiating unit ILR session root key K as obtained and stored The session initiated with the remaining called terminals directly generates the session key of each session according to the first random number generated by the K as and the corresponding session;
  • the calling terminal negotiates with different called terminals to obtain different session keys by generating and transmitting different first random numbers for different called terminals; or, the first terminal generates and delivers the same number for different called terminals. A random number, negotiated with different called terminals to get the same session key.
  • the called home key agreement module and the session key acquisition unit are configured with a shared permanent root key K b :
  • the key negotiation parameter transceiver unit is further configured to generate a fifth random number after receiving the key negotiation parameter, The fifth random number is sent to the home key negotiation module together with the key negotiation parameter, and the called home key negotiation module is further configured to save the fifth random number and the key sent by the key negotiation parameter transceiver unit.
  • the seventh parameter of the user identity of the called terminal generates a temporary encryption key K bt , and after encrypting the eighth parameter including the session key by using K bt , the obtained ciphertext and the sixth random number are sent to the session key.
  • the session key obtaining unit is further configured to generate K bt in the same manner as the called home key negotiation module after receiving the ciphertext and the sixth random number sent by the called home key negotiation module, using K bt Decrypt the ciphertext sent by the called home key negotiation module to obtain the session key.
  • Fl5 A key generation algorithm for the session integrity check key between UE A and UE B , that is, an algorithm for generating K abINT by K as .
  • Fl6 An integrity protection algorithm that protects the integrity of several parameters involved in the algorithm. It can be an algorithm such as MAC or SHA. This document does not specify a specific algorithm.
  • Fl8 An integrity protection algorithm for ILR B authentication of UE B.
  • Fl9 generates a temporary encryption key K bt generation algorithm. This paper does not specify a specific algorithm.
  • UE A transmits the "establish end-to-end session key response" response plus
  • ILR A identity location locator ( Identification Location
  • ILR A indicates the end of the user
  • the ILR B represents the authentication and key management server of the user terminal UE B.
  • ILR A and ILR B may be the same server. ILR.
  • ILR A represents the authentication and key management server of the user terminal UE A
  • ILR B represents the authentication and key management server of the user terminal UEB.
  • ILR A and ILR B can Is the same server ILR.
  • Session key K as .
  • the integrity check keys of UE A and ILR A may be shared in advance, or may be derived from Ka and RAND A at a time, or may be derived from other methods (such as derivation at the time of registration authentication).
  • K UE B and ILR B temporary encryption keys generated in a similar manner
  • KDN KDN (Key Derived Number) indicates the number of times the negotiated session root key can be used. 0 means that it can be derived without restriction. It is usually used for conference sessions where the number of participants cannot be determined. 1 means that it can only be derived once, usually for 1 Session to 1; other big An integer of 1 indicates a conference call with a fixed participant. That is to say, a session equal to or greater than 1 has a fixed number of participants, so that the ILR can delete the key when the number of key requests reaches the limit of the number of users, making the key management more secure and efficient.
  • the random number generated by the terminal UE A which is passed to the UE B for use.
  • the random number generated by the terminal UE B which is passed to the ILR B.
  • RAND B 2A The random number generated by the terminal UE B , which is passed to UE A for use.
  • RES B is the integrity check result given by UE B for ILR B authentication
  • SI Session Index. Because a terminal can have multiple sessions, each session should negotiate different keys, and each session may have a different number of called, such as when there is a conference call, in the conference call. When the calling party and the called party have the same key, they may also have different keys.
  • the SI identifier is used for which specific session the UE A tells the ILR A to negotiate.
  • TICKET A key negotiation method that transmits an encrypted key index without directly transmitting the key.
  • the invention avoids the key negotiation different from the session scenario, and has the advantages of preventing the man-in-the-middle attack, improving the security of the session key transmission, and assigning the same key to multiple peers of the same session. , improved the performance of the terminal caused by different keys in multi-session.

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)
  • Technology Law (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种支持合法监听的端到端会话密钥协商方法和系统
技术领域
本发明涉及因特网领域， 尤其涉及一种支持合法监听的端到端会话密钥 协商方法和系统。 背景技术
基于互联网络协议（IP ) 的因特网是开放的网络， 由多个国家和组织的 网络共同组成， 因此如果建立一个端到端会话， 很可能需要经过多个中间节 点（如路由器等）， 由于这些节点可能并不完全属于同一国家或组织的网络， 因此对于高度机密的会话， 就存在被第三方非法机构窃听或修改的可能。
因此， 为了防止机密信息被窃取或被修改， 人们通常使用端到端加密的 方法进行会话； 但是由于防恐等警务信息需要， 各国法律往往规定电信企业 开展的业务必须能被合法机构监听。 因此如果电信企业开展基于 IP的端到端 加密业务， 也必须能够支持被合法机构合法监听的功能。 这样如果由用户自 己独立协商端到端会话密钥， 网络就无法了解会话密钥的内容， 合法监听就 无法进行， 因此必须由网络参与到会话密钥协商的过程， 让特定的网络节点 也能够了解端到端会话密钥的信息， 才能够正确支持合法监听。
除了合法监听外， 在会话密钥协商中也需要考虑会议等功能。 如在高度 机密的场合， 当用于多方会议的会话时， 要求为每个参与会议的终端都分配 不同的密钥， 因此在一个会议会话中会议主持者需要为多个参与者依次分配 密钥， 相对于一次会话只生成一个密钥， 会议会话协商的密钥次数更多。
当前业界端到端密钥的协商方案包括安全描述方法 （ Security Descriptions, SDES )和票据（ TICKET )等几种密钥协商方法； 其中，
SDES将会话密钥包含在 UEA到 UEB的端到端信令中， 因此要求端到端 信令是安全的， 由于端到端信令安全也需要密钥加密， 因此也需要端对端的 信令密钥协商或逐段信令密钥协商， 而这些信令密钥协商的要求和媒体面密 钥协商一样复杂， 因此 SDES在部署上面存在一定的局限性。 而 TICKET密钥协商方法是通过终端 UEA在端到端会话建立信令中传递 一个会话密钥索引， 而不用直接传递会话密钥给 UEB, 这样会话密钥不用在 UEA和 UEB之间的信令直接传输， 消除了信令加密的必要， 因而 TICKET密 钥协商方法在密钥传递上相对于 SDES在部署上更容易实现。 但 TICKET密 钥协商方法进行密钥协商时往往和信令交互独立进行， 在建立多方呼叫等复 杂业务时， 相关密钥协商非常复杂且实现方法不统一， 会导致终端以及密钥 管理服务器（ Key Management Server, KMS ) 的密钥协商场景 4艮多， 流程非 常复杂， 不如 SDES在传递密钥时方便， 这是 TICKET方法的主要缺点。 另 夕卜， 目前 TICKET密钥协商方法的实现前提是建立在通用鉴权架构 （ Generic Authentication Architecture , GAA ) /通用自引导架构 ( Generic Bootstrapping Architecture, GBA )基础上， 因此需要部署 GBA服务器才能够实现 TICKET 密钥协商方法， 这在实际部署上也增加了难度。
Otway-Rees是 TICKET算法的一个代表算法， 如图 8所示， 首先 UEA和 UEB用 GBA方法分别和 KMS建立共享密钥 和 Kb;然后 UEA将 IDA和 IDB 用 Ka加密后形成 Ea (IDA, IDB)后通过发送给 UEB; UEB用密钥 Kb加密 IDA和 IDB , 形成 Eb (IDA, IDb)，将 EA (IDA, IDB)和 Eb (IDA, IDB)—起送到 KMS ; KMS 分别用 Ka和 Kb对 Ea (IDA, IDB)和 Eb (IDA, IDB)解密， 如果解密后 IDA, IDB正 确， KMS将生成一个会话密钥 K, 并分别用 Ka和 Kb加密， 生成 Ea ( K )和 Eb ( K )并发送给 UEB; UEB解密 Eb ( K ) , 得到会话密钥 Κ, 并将 Ea ( K ) 发送到 UEA, UEA再利用 Ka解密 Ea ( K )后得到会话密钥 Κ。
Otway-Rees存在如下缺点：
1、 在' Otway-Rees"中， 从 UEA到 UEB之间传递的 TICKET每次都用相 同的共享根密钥 Ka加密； 如果 Ka不是每次会话都重新协商， 则 Ka容易被攻 破， 一旦 Ka被攻破， 则后续会话密钥都被攻破；如果 Ka每次会话都协商， 则 因为 GBA建立过程中的信令交互也较多， 会降低密钥协商的效率。
2、 在' Otway-Rees"中， 密钥是在 KMS中生成， UEA对分配什么密钥没 有主控权， 在多方会话或者会议会话中， 如果 UEA需要为对端分配相同的密 钥， 在' Otway-Rees"中是无法实现的。
3、 "Otway-Rees"中， 最终生成的会话密钥是由 UEB传递给 UEA, 但没有 完整性校验措施， 如果中间人修改了加密后的密钥， 由于传递密钥的时候缺 乏完整性检验， UEA无法知道密钥是否被修改， 仍然能解密出一个错误密钥， 结果会出现 UEA和 UEB分别拥有不同的密钥， 这样后续传递的数据在加解密 时会严重错乱， 也增加了中间人攻击可能性。 例如， 在 UEA和 UEB进行加密 会话后， 会得到一个 Ea(K), 记为 El ; 如果 UEA和 UEC通话， UEB在 806消 息中截取了 UEA和 UEC之间的 Ea ( K ) , 记为 E2 , 如果 UEB想实施中间人攻 击， 可将 806消息中的 E2换为 El , UEA和 UEC通信就使用 E1加密， 这样 UEB就可以解密 UEA发向 UEC的数据。 发明内容
本发明要解决的技术问题是提供一种支持合法监听的端到端会话密钥的 协商方法， 可以在提供端到端加密的同时， 也满足合法机构对端到端会话进 行监听的需求。
为了解决上述问题， 本发明提供了一种支持合法监听的端到端会话密钥 协商的方法， 第一终端发起的到第二终端的会话的密钥协商过程包括：
第一终端与其归属的第一身份位置寄存器 (ILR)进行会话根密钥协商， 生 成本次会话的会话根密钥 Kas并保存后，第一终端根据包含自己生成的第一随 机数的第一参数和 Kas生成会话密钥， 并向第二终端发起端到端会话密钥请 求，携带的密钥协商参数包括用 Kas加密得到的包含第一随机数信息的第一密 文以及所述会话的第一标识信息；
第二终端在第一 ILR为其归属 ILR时， 将收到的密钥协商参数直接发送 到第一 ILR, 否则经其归属的第二 ILR发送到第一 ILR; 第一 ILR利用 Kas 解密第一密文获取所述第一随机数， 用与第一终端相同的方式生成会话密钥 并保存后， 直接以密文方式发送给第二终端， 或者先发送给第二 ILR, 第二 ILR保存该会话密钥并以密文方式将该会话密钥发送给第二终端；
第二终端解密所述密文， 获取其中的会话密钥， 第一终端和所述第二终 端使用该会话密钥进行会话， 该会话密钥包括会话加密密钥。
上述方法还具有如下特点： 第一终端和第一 ILR配置有共享的永久根密钥 Ka, 所述第一终端与其归 属的第一 ILR进行会话根密钥协商的步骤包括：
第一终端生成第二随机数， 并向第一 ILR发送包含第二随机数和所述会 话的第二标识信息的会话根密钥生成参数；
第一 ILR收到后， 根据 Ka和包含第二随机数、 第二标识信息及第一 ILR 生成的第三随机数的第二参数，通过第一密钥生成算法生成 Kas并保存第二标 识信息与 Ka 々映射关系后， 将第三随机数返回给第一终端；
第一终端用与第一 ILR相同的方式生成 Kas, 完成会话根密钥协商。
上述方法还具有如下特点：
在密钥协商过程中存在信令交互的两个设备之间为不安全链路时， 所述 方法还包括： 该两个设备在进行密钥协商时， 还对传递的参数的完整性进行 检验， 所述两个设备包括第一终端和第一 ILR, 第二终端和其归属的 ILR, 以 及第一终端和第二终端中的一组或多组。
上述方法还具有如下特点：
所述第一终端与其归属的第一 ILR进行会话根密钥协商的步骤还包括： 第一终端向第一 ILR发送会话根密钥生成参数时， 还将第一认证响应传递给 第一 ILR, 第一认证响应是第一终端根据 Ka和至少部分会话根密钥生成参数 生成临时消息完整校验密钥 Kat后，以至少部分会话根密钥生成参数为第三参 数， 用 Kat通过第一完整性保护算法计算得到的；
第一 ILR收到会话根密钥生成参数和第一认证响应后， 先根据保存的 Ka 和收到的会话根密钥生成参数， 用与第一终端得到第一认证响应相同的方式 计算得到一认证响应并与第一认证响应比较， 如两者不同， 则认证失败， 结 束该会话的密钥协商过程， 如两者相同， 再执行生成 Kas的步骤。
, 上述方法还具有如下特点：
所述第一终端与其归属的第一 ILR进行会话根密钥协商的步骤还包括： 第一 ILR向第一终端发送第三随机数时，还将第二认证响应传递给第一终端， 第二认证响应是第一 ILR根据 Kas以及包含第三随机数和至少部分会话根密 钥生成参数的第四参数， 通过第二完整性保护算法计算得到的； 该方法还包括： 第一终端生成 Kas后， 先用与第一 ILR得到第二认证响 应相同的方式计算得到一认证响应并与第二认证响应比较， 如两者不同， 则 认证失败， 结束该会话的密钥协商过程， 如两者相同， 再执行生成会话密钥 的步骤。
上述方法还具有如下特点：
所述第二标识信息包括第一终端为本次会话分配的会话索引（SI)和第一 终端的用户身份标识 (SIDA);
所述方法还包括：
第一终端同时存在的多个会话时， 为各个会话分配不同的 SI, 通过会话 根密钥协商过程为各个会话生成不同的 Ka;
第一终端生成会话密钥后， 以 SI为索引保存该会话密钥。
上述方法还具有如下特点：
所述会话根密钥生成参数还包括密钥可推导次数， 用于表示设定的可利 用 Kas生成会话密钥的次数；
所述第一终端与其归属的第一 ILR进行会话根密钥协商的步骤还包括： 第一 ILR收到所述会话根密钥生成参数后， 实时控制该 Kas生成会话密钥的 次数不超过该密钥可推导次数。
上述方法还具有如下特点：
所述密钥可推导次数为 0时表示次数不限制，可利用 1^生成任意次会话 密钥； 所述密钥可推导次数为 1时表示只能有一个被叫，可利用 1^生成一次 会话密钥； 所述密钥可推导次数为 n时表示固定只能有 n个被叫， 可利用 Kas 生成 n次会话密钥。
上述方法还具有如下特点：
所述第一密文包含用 Kas加密后的第一标识信息和第一随机数，该第一标 识信息包括第一终端为本次会话分配的会话索引 SI、 第一终端的用户身份标 识 SIDA和第二终端的用户身份标识 SIDB。
上述方法还具有如下特点： 第一终端生成的第一密文还包含用 Kas加密后的第三认证响应，该第三认 证响应是第一终端根据 Kas及包含第一标识信息和第一随机数的第五参数，通 过第三完整性保护算法计算得到的；
所述方法还包括： 第一 ILR收到第二终端发来的密钥协商参数， 根据其 中的第一标识信息检索到的 Kas对第一密文解密，获取第一随机参数后，先用 与第一终端得到第三认证响应相同的方式计算得到一认证响应并与第三认证 响应比较， 如两者不同， 则认证失败， 结束该会话的密钥协商过程， 如两者 相同， 再执行用与第一终端相同的方式生成所述会话密钥的步骤。
上述方法还包括：
第二终端解密第二 ILR发送的密文， 获取其中的会话密钥后， 还通过密 钥校验数据请求第一终端验证， 第一终端验证通过后， 再执行第一终端和第 二终端使用该会话密钥进行会话的步骤。
上述方法还具有如下特点：
第一终端生成的会话密钥还包括完整性校验密钥， 该完整性校验密钥是 第一终端根据 Kas和包含第一随机数的参数生成的；
上述方法还包括：
第一 ILR收到密钥协商参数后， 用与第一终端相同的方式生成该完整性 校验密钥并发送到第二终端；
第二终端通过密钥校验数据请求第一终端验证时， 根据收到的完整性校 验密钥和包含第一标识信息、 第一随机数和自己生成的第四随机数的第六参 数， 通过完整性保护算法计算得到第四认证响应， 用会话加密密钥对第四认 证响应和第四随机数加密后生成密钥校验数据， 发送到第一终端；
第一终端用会话加密密钥解密该密钥校验数据得到第四认证响应和第四 随机数， 用与第二终端得到第四认证响应相同的方式计算得到一认证响应并 与第四认证响应比较， 如两者不同， 则校验失败， 结束该会话的密钥协商过 程， 两者相同时， 校验通过。
上述方法还包括：
第一终端作为主叫终端与多个被叫终端进行会话时， 在发起与第一个被 叫终端的会话时与第一 ILR协商得到 Kas并保存， 之后发起的与其余被叫终 端的会话则直接根据该 Kas和各会话对应生成的第一随机数生成各会话的会 话密钥；
第一终端通过为不同被叫终端生成和传递不同的第一随机数， 与不同的 被叫终端协商得到不同的会话密钥； 或者， 第一终端通过为不同被叫终端生 成和传递相同的第一随机数， 与不同的被叫终端协商得到相同的会话密钥。
上述方法还包括：
第二终端收到第一终端发来的密钥协商参数后， 生成第五随机数， 将该 第五随机数与密钥协商参数一起发送到第二终端归属的 ILR, 第二终端归属 的 ILR保存第五随机数和密钥协商参数中的第一标识信息；
第二终端归属的 ILR在收到或生成会话密钥后， 生成第六随机数， 根据 与第二终端共享的永久根密钥 Kb和包含第五随机数、第六随机数和第二终端 的用户身份标识的第七参数生成临时加密密钥 Kbt, 用 Kbt对包含会话密钥的 第八参数加密后， 将得到的密文和第六随机数发送给第二终端；
第二终端收到其归属的 ILR发来的密文和第六随机数后， 用与第二终端 归属的 ILR相同的方式生成 Kbt, 用 Kbt解密 ILR发来的密文得到会话密钥。
上述方法还包括：
第二终端还将第五认证响应和第五随机数、 密钥协商参数一起发送到第 二终端归属的 ILR, 该第五认证响应是第二终端根据 Kb和包含第一标识信息 和第五随机数的参数， 通过完整性保护算法计算得到的；
第二终端归属的 ILR收到第五认证响应、第五随机数和密钥协商参数后， 用与第二终端得到第五认证响应相同的方式计算得到一认证响应并与第五认 证响应比较， 如两者不同， 则协商失败， 结束该会话的密钥协商过程， 如两 者相同， 在第一 ILR为第二终端归属的 ILR时， 再解密该密钥协商参数中的 第一密文， 否则再将该密钥协商参数发送到第一 ILR。
上述方法还具有如下特点：
第二终端归属的 ILR用 Kbt加密的第八参数还包括第六认证响应， 该第 五认证响应是第二终端归属的 ILR根据会话加密密钥和包含第五随机数和第 六随机数的参数， 通过完整性保护算法计算得到的；
上述方法还包括：
第二终端解密第二终端归属的 ILR发来的密文， 得到会话加密密钥后， 先用与第二终端归属的 ILR得到第六认证响应相同的方式计算得到一认证响 应并与第六认证响应比较， 如两者不同， 则协商失败， 结束该会话的密钥协 商过程， 如两者相同， 再生成密钥校验数据请求并发送到第一终端， 第一终 端验证通过后， 第一终端和第二终端再使用该会话密钥进行会话。
为了解决上述问题， 本发明还提供了一种支持合法监听的端到端会话密 钥协商的系统， 所述系统包括终端和身份位置寄存器 (ILR);
所述终端包括主叫密钥协商模块和被叫密钥协商模块， 所述主叫密钥协 商模块包括终端会话根密钥协商单元和终端会话密钥生成与发送单元； 被叫 密钥协商模块包括密钥协商参数收发单元和会话密钥获取单元；
所述 ILR包括主叫归属密钥协商模块和被叫归属密钥协商模块， 主叫归 属密钥协商模块包括 ILR会话根密钥协商单元和 ILR会话密钥生成与发送单 元； 其中，
所述终端会话根密钥协商单元设置为： 与所述终端归属的所述 ILR会话 根密钥协商单元进行会话根密钥协商，生成本次会话的会话根密钥 Kas并保存 后， 发送给所述终端会话密钥生成与发送单元；
所述终端会话密钥生成与发送单元设置为：接收到会话根密钥 Kas后，根 据包含自己生成的第一随机数的第一参数和 Kas生成会话密钥，并向所述密钥 协商参数收发单元发送密钥协商参数发起端到端会话密钥请求， 所述密钥协 商参数包括用 Kas加密得到的包含第一随机数信息的第一密文以及所述会话 的第一标识信息； 所述会话密钥包括会话加密密钥；
所述密钥协商参数收发单元设置为： 将收到的密钥协商参数发送到被叫 归属密钥协商模块；
所述会话密钥获取单元设置为：解密被叫归属密钥协商模块发送的密文， 获取其中的会话密钥； 所述 ILR会话根密钥协商单元设置为： 与所述终端会话根密钥协商单元 进行会话根密钥协商，生成本次会话的会话根密钥 Kas并保存后，将所述会话 根密钥 Kas发送给所述 ILR会话密钥生成与发送单元；
所述 ILR会话密钥生成与发送单元设置为： 利用所述 ILR会话根密钥协 商单元发送来的 Kas解密所述被叫归属密钥协商模块发送来的第一密文，获取 第一随机数， 并用与所述终端会话密钥生成与发送单元相同的方式生成会话 密钥并保存后， 发送给被叫归属密钥协商模块；
所述被叫归属密钥协商模块设置为： 将所述密钥协商参数收发单元发送 来的密钥协商参数发送到所述 ILR会话密钥生成与发送单元，以及将所述 ILR 会话密钥生成与发送单元发送来的会话密钥加密生成密文后发送给所述会话 密钥获取单元。
上述系统还具有如下特点：
所述终端会话根密钥协商单元和所述 ILR会话根密钥协商单元上配置有 共享的永久根密钥 Ka;
所述终端会话根密钥协商单元是设置为以如下方式与所述终端归属的所 述 ILR会话根密钥协商单元进行会话根密钥协商： 生成第二随机数， 并向所 述 ILR会话根密钥协商单元发送包含第二随机数和所述会话的第二标识信息 的会话根密钥生成参数； 以及与所述 ILR会话根密钥协商单元相同的方式生 成 Kas, 完成会话根密钥协商过程；
所述 ILR会话根密钥协商单元是设置为以如下方式与所述终端会话根密 钥协商单元进行会话根密钥协商： 在收到会话根密钥生成参数后， 根据 和 包含第二随机数、 第二标识信息及第一 ILR生成的第三随机数的第二参数， 通过第一密钥生成算法生成 Kas并保存第二标识信息与 Kas的映射关系后， 将 第三随机数返回给所述终端会话根密钥协商单元。
上述系统还具有如下特点：
在密钥协商过程中存在信令交互的两个设备之间为不安全链路时， 该两 个设备在进行密钥协商时， 还设置为对传递的参数的完整性进行检验， 所述 两个设备包括主叫终端和主叫终端归属的 ILR , 被叫终端和被叫终端归属的 ILR , 以及主叫终端和被叫终端中的一组或多组。
上述系统还具有如下特点：
所述第二标识信息包括所述终端会话根密钥协商单元为本次会话分配的 会话索引（SI)和终端的用户身份标识 (SIDA);
终端同时存在的多个会话时， 还设置为： 为各个会话分配不同的 SI, 通 过会话根密钥协商过程为各个会话生成不同的 Ka;
终端生成会话密钥后， 以 SI为索引保存该会话密钥。
上述系统还具有如下特点：
所述第一密文包含用 Kas加密后的第一标识信息和第一随机数，该第一标 识信息包括终端为本次会话分配的会话索引 SI、 主叫终端的用户身份标识 SIDA和被叫终端的用户身份标识 SIDB。
上述系统还具有如下特点：
所述主叫密钥协商模块还包括主叫密钥校验单元， 所述被叫密钥协商模 块还包括被叫密钥校验单元；
所述会话密钥获取单元还设置为： 将会话密钥发送到所述被叫密钥校验 单元；
所述被叫密钥校验单元设置为： 根据所述会话密钥生成密钥校验数据， 并发送到所述主叫密钥校验单元；
所述主叫密钥校验单元设置为： 通过所述密钥校验数据验证所述会话密 钥。
上述系统还具有如下特点：
所述会话密钥还包括完整性校验密钥， 该完整性校验密钥是由所述终端 会话密钥生成与发送单元和所述 ILR会话密钥生成与发送单元， 根据 Kas和 包含第一随机数的参数生成的；
所述被叫密钥校验单元是设置为： 根据收到的完整性校验密钥和包含第 一标识信息、 第一随机数和自己生成的第四随机数的第六参数， 通过完整性 保护算法计算得到第四认证响应， 用会话加密密钥对第四认证响应和第四随 机数加密后生成密钥校验数据， 发送到主叫密钥校验单元；
所述主叫密钥校验单元是设置为： 用会话加密密钥解密该密钥校验数据 得到第四认证响应和第四随机数， 用与第二终端得到第四认证响应相同的方 式计算得到一认证响应并与第四认证响应比较， 如两者不同， 则校验失败， 结束该会话的密钥协商过程， 两者相同时， 校验通过。
上述系统还具有如下特点：
所述终端作为主叫终端与多个被叫终端进行会话时， 在所述终端会话根 密钥协商单元发起与第一个被叫终端的会话时， 与所述 ILR会话根密钥协商 单元协商得到 Kas并保存， 之后发起的与其余被叫终端的会话则直接根据该 Kas和各会话对应生成的第一随机数生成各会话的会话密钥；
所述主叫终端通过为不同被叫终端生成和传递不同的第一随机数， 与不 同的被叫终端协商得到不同的会话密钥； 或者， 第一终端通过为不同被叫终 端生成和传递相同的第一随机数， 与不同的被叫终端协商得到相同的会话密 钥。
上述系统还具有如下特点：
所述被叫归属密钥协商模块与所述会话密钥获取单元上配置有共享的永 久根密钥 Kb:
所述密钥协商参数收发单元还设置为： 收到密钥协商参数后生成第五随 机数， 将该第五随机数与密钥协商参数一起发送到被叫归属密钥协商模块， 所述被叫归属密钥协商模块还设置为： 保存所述密钥协商参数收发单元 发送来的第五随机数和密钥协商参数中的第一标识信息； 以及收到所述 ILR 会话密钥生成与发送单元发送来的会话密钥后， 生成第六随机数， 根据 Kb和 包含第五随机数、 第六随机数和被叫终端的用户身份标识的第七参数生成临 时加密密钥 Kbt, 用 Kbt对包含会话密钥的第八参数加密后， 将得到的密文和 第六随机数发送给会话密钥获取单元；
所述会话密钥获取单元还设置为： 在收到被叫归属密钥协商模块发来的 密文和第六随机数后， 用与被叫归属密钥协商模块相同的方式生成 Kbt, 用 Kbt解密被叫归属密钥协商模块发来的密文得到会话密钥。 上述方法和系统在提供端到端加密的同时， 也满足合法机构对端到端会 话进行监听的需求。 本发明避免了密钥协商随会话场景不同而流程不同， 在 一实施例中， 对防止中间人攻击有较大改进， 提高了会话密钥传递的安全性， 并可以为同一个会话的多个对端分配相同的密钥， 改善了多会话时不同密钥 导致终端性能的下降。
相对 Otway-Rees密钥协商方法， 本发明的方法和系统有下面优点：
Otway-Rees在密钥协商需要先借助于 GBA/GAA流程建立共享密钥， 本 发明一实施例釆用永久共享密钥方式， 在实际运营和部署上更为简单；
Otway-Rees方法中，从 UEA到 UEB之间传递的 TICKET每次都用相同的 共享根密钥 Ka加密， 本发明一实施例釆用会话根密钥 £^加密 TICKET, 由 于每次会话生成的 EKas是不同的， 因此避免了中间人收集共享根密钥 Ka并破 解 Ka;
Otway-Rees密钥在 KMS生成， 主叫方没有密钥协商的控制权， 因而在 多方会话和会议电话等场合， 多个终端无法使用相同会话密钥， 因此主叫方 需要加解密多个被叫终端的媒体流， 性能会成为瓶颈。 本发明一实施例先协 商了会话根密钥， 后续主叫方可以传递相同或不同的随机数， 形成相同或不 同的会话密钥， 提高了主叫方的加解密性能；
Otway-Rees中， 会话密钥从 KMS传递给 UEB, 再由 UEB传递给 UEA。 本发明一实施例的会话密钥在 UEA和 ILR中分别独立生成， UEA的密钥完全 不由 UEA到 UEB或者 UEB到 UEA传递，减少了会话密钥在从 UEB传递给 UEA 过程中被窃取、 破解和修改的可能；
Otway-Rees中， 会话密钥从 UEB传递到 UEA过程中， 没有完整性校验， 因而如果最后生成的会话密钥被中间人修改或替换， UEA是无法感知的； 本 发明在一实施例中， 克服了这一缺陷；
Otway-Rees中， KMS将生成一个会话密钥 K, 并分别用 Ka和 Kb加密， 生成 Ea ( K )和 Eb ( K )并发送给 UEB, UEB既得到会话密钥 K, 也得到用 Ka对 K加密后的 Ea ( K ) 。 如果 UEB反复向 KMS发起密钥消息， 将得到一 系列：^和£& ( K )的对照表， 最终 很容易被 UEB攻破。 本发明一实施例由 于不用 Ka加密传递数据给 UEB, 而且每次使用的都是会话密钥， 因此 UEB 不可能发起类似的攻击。
附图概述
图 1 为本发明实施例的系统架构示意图；
图 2 为本发明实施例的密钥协商机制的流程图；
图 3 为本发明实施例多方会话密钥协商的场景的示意图；
图 4 为本发明实施例会议会话时密钥协商的应用场景的示意图； 图 5 为本发明实施例单方呼叫协商参数的示例；
图 6 为本发明实施例多方呼叫时协商参数的示例；
图 7 为本发明实施例会议呼叫时协商参数的示例；
图 8 为现有技术中 Otway-Rees密钥协商的信令流程图；
图 9为本发明实施例中系统功能模块图。
本发明的较佳实施方式
下面结合附图详细说明本发明的具体实施方式。
图 1 所示为本实施例的系统架构示意图， 系统包括用户终端 （User Equipment, UE ) ： UEA和 UEB; 接入服务器（ Access Server Node , ASN ) ： ASN1和 ASN2; 以及身份位置寄存器（ Identification Location Register, ILR )： ILRA和 ILRB。 其中， 终端 UEA和 UEB之间的数据链路为不安全链路， 如 IP 链路， 因此 UEA和 UEB之间会话密钥不能明文传递， 由于 UEA随时可能和数 亿其他用户之中的一个发生通讯， UEA上不可能包含所有用户的预共享密钥， 从而 UEA不能用预共享密钥与 UEB建立安全的端到端会话， 因此必须设计一 种端到端的会话密钥协商机制， 来解决端到端会话的安全问题。
接入服务器也可称为接入服务节点， 是逻辑实体， 为提供接入 IP网服务 的节点， 可以是服务通用分组无线业务（GPRS ) 支持节点（Serving GPRS Support Node, SGSN)、 网关 GPRS支持节点 (Gateway GPRS Support Node, GGSN)、 分组数据业务节点 （Packet Data Serving Node, PDSN )和宽带接入 服务器 (Broadband Remote Access Server, BRAS)等设备。
ILR是逻辑实体， 承担端到端密钥的管理和协商， 保存有用户终端属性 信息的节点，在具体应用场景中可以是 KMS、归属位置寄存器（ Home Location Register, HLR ) 、 归属用户服务器（ Home Subscriber Server, HSS ) 、 授权 / 认证 /计费月良务器 ( Authorization、 Authentication、 Accounting, AAA ) 、 或其 他承担端到端密钥管理和协商功能的实体。
本实施例中 , UEA通过 ASN1向 ILRA注册（ 101 ) , UEB通过 ASN2向 ILRB注册（ 102 )； 在 UEA和 UEB注册成功后， 如果 UEA希望向 UEB发起加 密会话（104 ) ,就需要先协商 UEA和 UEB之间的会话密钥， 由于 UEA和 UEB 之间本身为不安全链路， 因此需要设计一种方法将 UEA生成的会话密钥能够 通过不安全链路正确无误地传送给 UEB。 另外为保证合法监听的进行， UEA 和 UEB协商的会话密钥必须让网络中与合法监听设备连接的特定节点了解， 这是合法监听进行的前提， 其中特定节点可以是 ILR。
在本实施例中， 通过两个用户终端即 UEA和 UEB和两个 ILR即 ILRA和 ILRB来生成和传递会话密钥， 很好地解决了合法监听问题。
图 2所示出为本实施例中密钥协商的基本流程， 其中涉及的四个网络节 点中。 UEA和 UEB的用户身份标识（Subscriber Identification, SID )分别为 SIDA和 SIDB。此外， UEA和 ILRA之间存在共享的永久根密钥 Ka, UEB和 ILRB 之间存在共享的永久根密钥 Kb; UEA和 UEB以及 ILRA和 ILRB上具备多种安 全算法； 其中， 安全算法包括加密算法、 完整性保护算法和密钥生成算法等； 这些安全算法均可以釆用现有技术中的安全算法， 本实施例对此并不限定。
如加密算法可以为 DES、3DES、AES等算法，完整性保护算法包括 MD5、 SHA-1等算法； 密钥生成算法一般由运营商制定， 可以是特定的算法。
ILRA和 ILRB之间是安全和可信任的， 即： ILRA和 ILRB之间已存在加密 的安全数据通道，且 ILRA总认为 ILRB发来的以 SIDB为标识的 UEB的信令和 数据包已通过 ILRB认证， 是合法的。 本实施例第一终端发起到第二终端的端到端会话的密钥协商过程包括如 下步骤：
( 1 )第一终端和其归属地的第一 ILR进行会话根密钥协商， 用共享的永 久根密钥 Ka生成本次会话的会话根密钥 Kas并保存后， 第一终端以生成的第 一随机数为参数，用 Kas生成会话密钥，并向第二终端发起端到端会话密钥请 求，携带的密钥协商参数包括用 Kas加密得到的包含第一随机数信息的第一密 文以及端到端会话的标识信息；
其中， 步骤（1 )进一步分为以下步骤：
步骤 201 : 第一终端 UEA生成随机数 RANDA, 并向 ILRA发送会话根密 钥生成参数， 包括随机数 RANDA以及会话索引（ Session Index, SI )和 SIDA;
本步骤中， UEA可以通过 "会话根密钥协商请求" 消息将上述参数发送 给 ILRA;
SI和 SIDA是 UEA发起的会话的标识信息， 可以唯一标识 UEA发起的一 个会话。 其中， SI为固定长度的整数， 如可以为 16位或 32位长度， 由 UEA 分配， 用于唯一标识 UEA当前发起的会话， 每次建立新的会话， SI应分配不 同的整数， 超出限制值可以归零使用。 例如 SI为 16位整数， UEA每建一个 新的会话， 可将对应的 SI加 1 , 如果 SI超出 65535, 则自动归 0。 在本实施 例中， 给每个会话都建立一个与其他会话不同的会话根密钥 Kas。 由于一个用 户可以同时存在多个会话， 因此 UEA和对端 UEB在密钥协商时需要区分协商 的密钥属于哪一个会话的， 因此本实施例中用一个索引号 SI来区分当前进行 会话密钥协商的会话密钥属于哪一个会话， 通信双方可以根据 SI区分是哪一 个会话， 从而找出该会话的会话根密钥 Kas, 也就是说， UEA与对端协商的端 到端会话时候，用 SI告诉对方具体釆用哪一个会话根密钥 Kas生成会话密钥； 在另一实施例中， 如果 UEA和 ILRA之间为非安全通道， UEA向 ILRA传 递会话根密钥生成参数时，还可以同时将认证响应 RESA传递给 ILRA,用 RESA 进行完整性校验以确保 ILRA接收到的数据来自 UEA, 保证 ILRA不受中间人 修改 RANDA而遭受攻击， 具体为：
UEA生成随机数 RANDA后， 以会话根密钥生成参数为参数， 用 UEA与 ILRA共享的永久根密钥 Ka通过密钥生成算法 flO计算出一个临时消息完整校 验密钥 Kat, 即 Kat= f lOKa (RANDA, SIDA, SI), 应说明的是， 在其他实施例中， 会话根密钥生成参数可以不同； 然后以会话根密钥生成参数为参数， 用临时 消息完整性校验密钥 Kat通过完整性保护算法 fl l计算得到认证响应 RESA, 即 RESA= fl lKat(RANDA, SIDA, SI,); UEA将 RESA和会话根密钥生成参数封装 到 "会话根密钥协商请求" 消息中发送给认证服务器 ILRA。 当然， 会话根密 钥生成参数并不一定为 RANDA, SIDA, SI, 还包括其他参数 (参见下文）。 另 夕卜，也可以只使用部分会话根密钥生成参数来生成 Kat,如在包括其他参数时， 也可以只使用 RANDA, SIDA, SI来生成 KAT。
在另一实施例中， 会话根密钥生成参数还可以进一步包括密钥可推导次 数（ Key Derived Number , KDN ) ； KDN用来表明设定的可利用每个会话根 密钥 Kas生成会话密钥的次数， 此 KDN由 UEA指定并传递给 ILRA, ILRA实 时控制密钥 Kas生成会话密钥的次数不超过 KDN。
其中， KDN为 0表示次数不限制， Kas可以用于生成任意次会话密钥； 1 表示只能有一个被叫， 1^可以用于生成一次会话密钥； n表示固定只能有 n 个被叫， Kas可以用于生成 n次会话密钥， n为大于 1的整数。 当然 KDN的 取值与其生成的会话密钥的次数的对应关系并不限于此；
釆用 KDN可以加强密钥分发的安全性，用于限定会议会话时由会话根密 钥生成的密钥数量。
在本步骤中， UEA除了指定 KDN 以外， 还可以进一步指定会话根密钥
Kas的生存期，并将该生存期添加到会话根密钥生成参数传递给 ILRA,生存期 表示 Kas可以使用的时间， 生存期到后， 可以删除 Kas; Kas的生存期的传递与 使用方法与 KDN相同， 本文对此不再赘述。
步骤 202: ILRA收到会话根密钥生成参数后， 生成随机数
Figure imgf000018_0001
以 RANDn^A和会话根密钥生成参数为参数，利用 UEA和 ILRA共享的永久根 密钥 Ka, 通过密钥生成算法 fl2生成会话根密钥 Kas, ILRA保存 SIDA、 SI和 会话根密钥 Kas的映射关系后， 将 RANDn^A返回给 UEA; 其中， ILRA可以通过 "会话根密钥协商响应" 消息将 RANDILJ^A返回给
UEA;
ILRA收到 UEA发送来的参数后，可以根据 SIDA检索 UEA和 ILRA的共享 的永久根密钥 Ka, 也可以用其他方式获知该永久根密钥 Ka;
在另一实施例中， 如果 ILRA收到 UEA发送来的认证响应 RESA, ILRA生 成随机数 RANDILRSA前， 先对认证响应 RESA进行完整性校验， 具体为：
ILRA先用与 UEA得到 RESA相同的方式计算出 XRESA, 具体地， ILRA 以会话根密钥生成参数为参数， 利用 UEA和 ILRA共享的永久根密钥 Ka, 通 过密钥生成算法 flO计算一个临时消息完整性校验密钥 Kat,本实施例中， Kat= flOKa (RANDA, SIDA, SI); 然后以会话根密钥生成参数为参数， 利用 Kat通过 完整性保护算法 fl l 计算得到认证响应 XRESA, 本实施例中， XRESA= fl lKat(RANDA , SIDA, SI);
对比 RESA和 XRESA是否相同：
如果不同， 说明中间人修改了数据， 密钥协商失败；
如果相同， 则执行生成随机数 RANDILJ^A之后的步骤生成会话根密钥
Kas; 然后以会话根密钥生成参数和 RANDn^A为参数， 利用会话根密钥 Kas, 通过完整性保护算法 fl3 计算一个认证响应 RESEDA , 如
Figure imgf000019_0001
fl3Kas( ANDA, SIDA, SI,
Figure imgf000019_0002
将 RANDJLR^和 RESJLR^通过 "会话根 密钥协商响应" 消息返回给 UEA。
ILRA与 UEA可以预先约定好要共同釆用的算法， 如密钥生成算法 fl0、 完整性保护算法 fl l、 密钥生成算法 fl2、 完整性保护算法 fl3、加密密钥生成 算法 fl4、 完整性保护算法 fl6和加密算法 fl7等。 下文中的 ILRA与 UEB之 间也是如此。 上述标记不同的同类算法可以相同或不同。
步骤 203: UEA以 RANDn^A和会话根密钥生成参数为参数，利用共享的 永久根密钥 Ka通过密钥生成算法 fl2计算出会话根密钥 Kas, 再生成随机数 ANDA2B, 以随机数 RANDA2B为参数， 利用会话根密钥 KAS生成会话密钥， 包括通过加密密钥生成算法 f!4生成会话加密密钥 KabENC, 并以 SI为索引保 存会话密钥； 然后以建立会话密钥请求参数为参数， 利用会话根密钥 KAS, 通 过加密算法 fl7生成密文 EKAS后，将会话密钥参数（包括密文 EKas^ SIDA, SIDB, SI )一起发送给 UEB;
可以看出， UEA和 ILRA是按相同的方式生成 KAS, 文中， 相同的方式是 指釆用相同的参数、 密钥和算法。
其中， 建立会话密钥请求参数包括 SI, SIDB, SIDA和 RANDA2B。
此外，生成会话密钥时，生成会话密钥的参数还可以包括其他的只与 UEA 相关且与 UEB不相关的参数， 如 SIDA, SI等；
如果不考虑中间人攻击的问题， 也可以只对生成密文 EKAS的参数中的随 机数 RANDA2B加密； 而将其他 SI, SIDB, SIDA以明文的方式传递给 UEB; 在实际运用中， 密钥协商过程可以独立进行， 也可以和会话建立过程结 合进行。 前者用于会话过程中修改密钥等情况， 在后者多用于和会话初始建 立的情况，对于后者，终端在会话前，会先发起 "建立端对端会话密钥请求"， 这样本步骤中的密钥协商参数都可以携带在 "建立端对端会话密钥请求" 中 传到 UEB。
在另一实施例中， 会话密钥中还可以包括完整性校验密钥 KABINT, UEA 以生成会话加密密钥 KABENC相同的参数， 如 RANDA2B, 用 KAS通过完整性校 验密钥生成算法 fl5生成。
在另一实施例中， UEA收到 "会话根密钥协商响应" 消息中还包括认证 响应 RESEDA, UEA在计算出会话根密钥 KAS后， 生成随机数 RANDA2B之前， 还执行以下处理： UEA以会话根密钥生成参数和 RANDn^A为参数， 利用会 话根密钥 KAS通过完整性保护算法 fl3计算认证响应 XRESJLR2A;比较 RESEDA 和 XRESJLR2A是否相等， 如果不等， 说明有中间人修改数据， 密钥协商失败； 如果相等， 则开始执行生成随机数 RANDA2B;
在另一实施例中， 为防止中间人攻击， UEA在生成密文 EKAS的参数中还 包括认证响应 RESA2B; 即， UEA以建立会话密钥请求参数为参数， 利用会话 根密钥 KAS通过完整性保护算法 fl6计算出认证响应 RESA2B, 然后以认证响 应 RESMB和建立会话密钥请求参数为参数， 利用会话根密钥 KAS, 通过加密 算法 fl7生成密文 EKAS。
在一应用示例中， 当会话为会议会话时（如用于会议电话等场合）， 一个 会议会话中的每个主叫可以有多个被叫， 如会议电话中会议桥， 将会和多个 对端产生会话， 每一个主叫和被叫之间的密钥可以相同， 也可以不同。 在本 实施例中， 端到端密钥管理控制权在主叫终端 UEA中， UEA通过为不同的被 叫终端生成和传递不同的 RANDA2B , 就可以与不同的被叫终端协商得到不同 的会话密钥， 通过为不同的被叫终端生成和传递相同的 RANDA2B , 就可以与 不同的被叫终端协商得到相同的会话密钥。
如， 本步骤中， UEA可以为 UEB分配的
Figure imgf000021_0001
, 为 UEC分配的 RANDA2C也等于 0001 ,则 UEA和 UEB及 UEA和 UEC分配的会话密钥将相同； 但如果为 UEB分配的
Figure imgf000021_0002
, 为 UEc分配的 , 则最 后生成的 UEA和 UEB及 UEA和 UEC的会话密钥将不同。
由此可见， UEA通过为对端分配相同或不同的随机数 RANDA2B , 可以 对每个会话的不同对端分配相同的密钥， 也可以分配不同的密钥， 这就很好 的满足了会议电话等多方通话的场合。
( 2 )第二终端将收到的协商参数通过第二 ILR发送到第一 ILR,第一 ILR 利用 KAS解密第一密文获取第一随机数，然后以与第一终端相同的方式生成会 话密钥并保存， 然后将会话密钥发送给第二 ILR, 第二 ILR保存该会话密钥 并以密文方式将该会话密钥发送给第二终端；
其中， 步骤（2 )具体包括：
步骤 204: UEB收到 UEA发送来的密文 EKAS和 SIDA, SIDB, SI后， 生成随 机数 RANDB ,并以 SI为索引将该随机数 RANDB保存在 UEB中，然后将密文 EKAS和 SIDA, SIDB, SI, 以及随机数 RANDB一起发送给 ILRB;
其中， UEB可以通过获取端到端密钥请求消息将密文 EKas^o SIDA, SIDB,
SI, 以及随机数 RANDB发送给 ILRB;
在另一实施例中，如果 UEB与 ILRB之间为非安全链路时， UEB将 RANDB 保存后， 进一步包括： UEB以 RANDB, SIDB, SIDA, SI为参数， 利用共享的永 久根密钥 KB通过完整性保护算法 fl8计算出认证响应 RESB, 即 ESB= fl8Kb ( RANDB, SIDB, SIDA, SI ) , 然后将 RESB连同 EKAS和 SIDA, SIDB, SI, 以及随 机数 RANDB一起发送给 ILRB„
步骤 205： ILRB将密文 EKAS和 SIDA, SIDB, SI发送给 ILRA;
其中， 如果 ILRB收到 UEB发送来的数据中包含 RESB, 则在向 ILRA发送 数据前， 还执行以下处理： ILRB以 RANDB, SIDB, SIDA, SI为参数， 利用 KB, 通过完整性保护算法 fl8, 计算出 XRESB, 即 XRESB= fl8Kb ( RANDB, SIDB, SIDA, SI ) , 比较 XRESB和 RESB是否相同， 如果不同， 说明中间被修改， 密 码协商失败， 如果相同， 再将密文 EKas^o SIDA, SIDB, SI发送给 ILRA, 同时 ILRB记录下其中的 RANDB等留作以后使用。
步骤 206: ILRA根据 SIDA和 SI检索到会话根密钥 KAS, 利用会话根密钥 KAS通过加密算法 fl7对应的解密算法对密文 EKAS解密， 获取 RANDA2B, 并以 与 UEA生成会话密钥相同的方式生成会话密钥，其包括会话加密密钥 KABENC, 并将会话密钥发送给 ILRB并发送给 ILRB;
其中， 以与 UEA生成会话密钥相同的方式生成会话密钥指釆用相同的参 数，利用相同的密钥，通过相同的密钥生成算法产生会话密钥，如以 RANDA2B 为参数， 利用会话根密钥 KAS生成会话密钥；
ILRA可以通过获取端到端会话密钥响应消息将会话密钥发送给 ILRB; 此外， 会话密钥还可以包括完整性校验密钥 KABINT, ILRA以 RANDA2B为 参数， 用 KAS通过完整性校验密钥生成算法 fl5生成。
在另一实施例中， 如果 ILRA解密得到的数据中还包括 RESA2B, ILRA在 生成会话密钥之前，还执行以下处理： ILRA以建立会话密钥请求参数为参数， 利用会话根密钥 Kas通过完整性保护算法 fl6生成认证响应 XRESA2B , 即 XRESA2B = fl6KAS(SI, SIDB, SIDA,
Figure imgf000022_0001
并与解密得到的 RES^B比较， 如果一致， 再开始执行生成会话密钥， 否则密钥协商失败； 步骤 207: ILRB生成随机数
Figure imgf000023_0001
并以 RANDB, SIDB 为参数， 利用 UEB和 ILRB之间的共享的永久根密钥 KB, 通过密钥生成算法 fl9计算 ILRB和 UEB之间的临时加密密钥 KBT,然后以 RANDILJ^B和会话密钥 为参数， 利用临时加密密钥 KBT, 通过加密算法 £21计算密文 EKBT, 然后将密 文 EKBT和随机数 RANDIL^B发送给 UEB;
其中， ILRB可以通过获取端对端密钥响应消息将加密后的会话密钥与随 机数 RANDIL^B发送给 UEB;
本步骤中， ILRB也可以只会话密钥为参数生成密文；
在另一实施例中， 计算密文 EKBT的参数中还可以进一步包括认证响应
Figure imgf000023_0002
其中， 认证响应 RESILR2B是以会话密钥， RANDB为参 数， 利用临时加密密钥 KBT, 通过完整性保护算法 GO计算得到； 其中， 会话 密钥包括会话加密密钥， 还可以进一步包括会话完整性密钥。
( 3 )第二终端解密第二 ILR发送的密文， 获取其中的会话密钥， 并通过 密钥校验数据请求所述第一终端验证， 所述第一终端验证通过后， 所述第一 终端和所述第二终端使用该会话密钥进行会话。
其中， 步骤（3 )具体包括：
步骤 208: UEB以 RANDB,
Figure imgf000023_0003
SIDB为参数， 利用永久根密钥 KB, 通过密钥生成算法 fl9生成临时加密密钥 KBT; 然后用临时加密密钥 KBT, 通过加密算法 £21对应的解密算法对 ILRB发送来的密文 EKBT解密， 提取出会 话密钥， 然后生成密钥校验数据并发送到 UEA;
前面已经指出， 在实际运用中， 密钥协商过程可以独立进行， 也可以和 会话建立过程结合进行。 对于后者， 在此步骤中， 终端在会话建立成功时， UEB会向 UEA返回 "建立端对端会话密钥响应" 的应答消息， 这样本步骤中 所携带的密钥协商相关参数都可以携带在 "建立端对端会话密钥响应" 消息 中传到 UEA。
其中， 对密钥进行校验的方法有很多， 本实施例中给出一种较佳的实施 方式， 即密钥校验数据可以为： UEB生成随机数 RANDB2A, 以 SI, SIDB, SIDA, RANDA2B, RANDB2A为参数， 利用完整性校验密钥 KABINT, 通过完整性保护算 法 £22生成认证响应 RESB2A; 以 RANDB2A和认证响应 RESB2A为参数， 利用 会话加密密钥 KABENC, 通过加密算法 £23生成密钥校验数据 EKABENC, 将该密 钥校验数据 EKabENC发送给 UEA;
在另一实施例中， 如果解密数据中还包括认证响应 RESILR2B, UEB生成 密钥校验数据之前，还包括对 RESJLR2B进行完整性校验的步骤， 具体为： UEB 以与 ILRB生成 RESILRSB相同的方式， 生成认证响应 XRESILR2B; 如以会话加 密密钥、 会话完整性密钥、
Figure imgf000024_0001
RANDB为参数， 利用 Kbt, 通过完整 性保护算法 £20计算认证响应 XRESJLR2B,即
Figure imgf000024_0002
f20Kbt(K abENC ， KablNT，
Figure imgf000024_0003
RANDB), 判断 RESJLR2B是否和 XRESJLR2B相等， 如果相等， 则表 明没有被中间人修改， 继续执行生成密钥校验数据 £10^1^的步骤； 否则密钥 协商失败。
步骤 209: UEA收到密钥校验数据后，对该密钥校验数据进行校验， 如校 验通过， UEA和 UEB之间就可以使用会话密钥进行会话；
若 UEA收到密钥校验数据 EKABENC, UEA用 KABENC通过加密算法 £23对应 的解密算法解密 EKABENC后获取 RANDB2A后， 以 SI, SIDB, SIDA,
Figure imgf000024_0004
ANDB2A为参数， 利用完整性校验密钥 KABINT,通过完整性保护算法 £22计算 XRESB2A, 即 XRESB2A= f22KabiNT(SI, SIDB, SIDA,
Figure imgf000024_0005
RANDB2A), 比较 RESB2A和 XRESB2A是否一致， 如果一致， 说明对端收到了正确的会话密钥； 后续 UEA和 UEB之间就可以使用 KABENC和 KABINT正常进行媒体加密和完整性 校验。
经过上述步骤， UEA就正确的将会话密钥传给了 UEB, 同时 ILRa和 ILRB 都知道 UEA和 UEB之间的实际会话密钥，从而即使 UEA和 UEB釆用了密钥对 数据流加密， ILRA和 ILRB也一样可以进行解密，从而满足了合法监听的需要。
值得指出的是,上文中 UEB的认证服务器 ILRA和 UEA的认证服务器 ILRB 可以是同一个， 此时两个用户 UEA和 UEB都由 ILRA分配和管理密钥， 这样 在图 2中步骤 205和步骤 206可以合并为当 ILRA收到步骤 204的消息后， 直 接生成密钥 KabINT, KabENC,并向通过步骤 207消息发送给 UEB。此时步骤（2 ) 可修正为： 第二终端将收到的密钥协商参数发送到第一 ILR, 第一 ILR利用 Kas解密第一密文获取第一随机数， 然后以与第一终端相同的方式生成和保存 会话密钥， 并以密文方式将该会话密钥发送给第二终端；
下面根据附图详细介绍本发明的应用示例。 需要说明的是， 本发明内容 可以用以下应用示例解释， 但不限于以下的应用示例。
图 3所示为一种会议会话密钥协商的应用场景， 在此场景中， UEA是会 议的主控方， UEA、 UEC和 UED分别经由 ASN1、 ASN3和 ASN2成功接入并 通过认证， 当用户 UEA需要发起一个 UEA和 UEC以及 UED的多方加密会话， UEA可依次和 UEC、 UED协商会话密钥， 或者 UEA依次和 UED、 UEC协商会 话密钥。 釆用哪种顺序取决于 UEA发起会话业务的顺序。
不管 UEA釆用何种顺序， 在同一个会话中， 当 UEA和第一个对端协商密 钥时， 因为之前会话根密钥 Kas尚未生成， UEA需要利用 201 ~ 202消息先和 ILRA协商会话根密钥 Kas, 在 UEA和第二个对端或者第三、 第四个对端协商 密钥时， 由于 Kas已经生成， 因此 UEA不需要再和 ILRA协商会话根密钥 Kas, 也就是说， 当 UEA和第一个对端以后的其他对端协商会话密钥时， 不再需要 步骤 201 ~ 202中的消息。
另外， 如果 UEA和对端在同一个 ILR下注册， 在协商会话密钥的时候不 需要两个 ILR之间传递信息， 也就是说不需要 205 ~ 206步骤； 如果 UEA和 对端不在同一个 ILR下， 则 UEA和对端协商会话密钥的时候， 需要 205 ~ 206 步骤。
例如， 在图 3中， 当 UEA需要同时向 UEC和 UED发起 305、 306会议会 话时， UEA在首次和 UEC协商会话密钥时， 因为会话根密钥 Kas尚未生成， 因此 UEA和 ILRA需通过消息 201 ~ 202先协商会话根密钥 Kas, 由于 UEA和 UEC属于同一个 ILRA, 因此后续会话协商不需要 205 ~ 206消息， 最终 UEA 只需要 201 - 204, 207, 208就可以和 UEC建立会话密钥。 随后 UEA和 UED 协商会话密钥时， 由于会话根密钥 1^已存在， 因此不再需要 201 ~ 201消息， 但由于 UEA和 UED不属于同一个 ILR, 因此需要 205 ~ 206消息， 最终 UEA 只需要 203 ~ 208消息和 UED建立会话密钥。
图 4 为通过会议桥 CB来进行多方会议会话的密钥协商应用场景， 在这 个场景中， CB是会议的主控方， 图中 CB、 UEA、 UEC和 UEB分别通过 ASN1、 ASN1、 ASN3和 ASN2接入， 在接入时 CB、 UEA、 UEC和 UEB分别通过 401、 402、 403、 404消息与 ILRA、 ILRA、 ILRA、 ILRB交互， 进行接入认证。 当 CB 发起一个多方加密会话前， CB已经得到了参会人数、每个参会者是否独立分 配密钥等信息， 然后 CB通过消息 201 ~ 204, 207, 208首先和 UEA协商会话 密钥， 然后 CB在协商好的会话根密钥基础上， 再通过 203、 204、 207、 208 协商与 UEC的会话密钥， 最后再通过 203 ~ 208协商与 UEB的会话密钥。
图 5为单方呼叫时会话密钥协商的参数示例 （此密钥协商的架构图可参 考如图 1 ) , 其中 SI索引为 1 , 表示协商第一个会话的会话根密钥， KDN=1 表示此会话中只允许 ILRA从 Kas推导出一个密钥， 当 UEA和 UEB协商好会话 密钥后， 后续其他用户无法再在此会话中利用根密钥 Kas推导其他会话密钥。 需要说明的是， 此处的随机数 RANDA2B 机数长度仅为示意， 实际应用中此 随机数可以是 128bit、 256bit或者其他长度。
图 6为多方呼叫时会话密钥协商的参数示例 （此图的实现架构可参考图 3 ) 。 其中 SI索引为 2, 表示协商第 2个会话的会话根密钥， KDN=2表示此 会话中只允许 ILRA从 Kas推导出 2个密钥， 当 UEA和 UEC以及 UEA和 UED 各自协商好会话密钥后，后续其他用户无法再在此会话中的根密钥 Kas推导其 他会话密钥， 当 UEA希望 UEA和 UEC以及 UEA和 UED协商的两个端到端会 话釆用相同密钥时， 可以在第二个端到端密钥协商中， 将 RANDA2B釆用和第 一个协商相同的随机数， 这样从 UEA协商的两个端到端连接将具有相同的会 话密钥。 同样需要说明的是， 此处的随机数 RANDA2B的随机数长度也仅为示 意， 实际应用中此随机数可以是 128bit、 256bit或者其他长度。
图 7为釆用会议桥 CB实现多方会议呼叫时的参数协商示例 （此图的实 现架构可参考图 4 ) 。 其中 SI索引为 1003 , 表示协商第 1003个会话的会话 根密钥， KDN=0表示此会话允许从会话根密钥推导出任意个端到端会话密 钥。 另外， 三个端到端分支呼叫的随机数分配都不同， 表示会议中的三路呼 叫分别加密， 这样当任意一路被切断呼叫时， 他人将不能釆用相同的密钥窃 听， 安全性更好。 当然， CB也可以为三个分支呼叫使用相同的随机数， 这样 分配的三个端到端会话密钥将相同， 可以减小会议桥 CB的加解密处理负荷。
相应地， 本实施例还提供了一种支持合法监听的端到端会话密钥协商的 系统， 如图 9所示， 所述系统包括终端和 ILR;
终端包括主叫密钥协商模块和被叫密钥协商模块， 主叫密钥协商模块又 包括终端会话根密钥协商单元和终端会话密钥生成与发送单元； 被叫密钥协 商模块包括密钥协商参数收发单元和会话密钥获取单元；
ILR 包括主叫归属密钥协商模块和被叫归属密钥协商模块， 主叫归属密 钥协商模块又分为 ILR会话根密钥协商单元和 ILR会话密钥生成与发送单元； 其中，
终端会话根密钥协商单元， 用于与终端归属的 ILR会话根密钥协商单元 进行会话根密钥协商，生成本次会话的会话根密钥 Kas并保存后，发送给终端 会话密钥生成与发送单元；
终端会话密钥生成与发送单元，用于接收到会话根密钥 Kas后，根据包含 自己生成的第一随机数的第一参数和 Kas生成会话密钥，并向所述密钥协商参 数收发单元发送密钥协商参数发起端到端会话密钥请求， 密钥协商参数包括 用 Kas加密得到的包含第一随机数信息的第一密文以及所述会话的第一标识 信息； 会话密钥包括会话加密密钥；
密钥协商参数收发单元， 用于将收到的密钥协商参数发送到被叫归属密 钥协商模块；
会话密钥获取单元， 用于解密被叫归属密钥协商模块发送的密文， 获取 其中的会话密钥；
ILR会话根密钥协商单元， 用于与终端会话根密钥协商单元进行会话根 密钥协商， 生成本次会话的会话根密钥 Kas并保存后， 将会话根密钥 Kas发送 给 ILR会话密钥生成与发送单元；
ILR会话密钥生成与发送单元， 用于利用 ILR会话根密钥协商单元发送 来的 Kas解密所述被叫归属密钥协商模块发送来的第一密文， 获取第一随机 数， 并用与所述终端会话密钥生成与发送单元相同的方式生成会话密钥并保 存后， 发送给被叫归属密钥协商模块；
被叫归属密钥协商模块， 用于将被叫密钥协商参数收发单元发送来的密 钥协商参数发送到 ILR会话密钥生成与发送单元， 以及将 ILR会话密钥生成 与发送单元发送来的会话密钥加密生成密文后发送给会话密钥获取单元。
其中， 终端会话根密钥协商单元和 ILR会话根密钥协商单元上配置有共 享的永久根密钥 Ka;
终端会话根密钥协商单元与终端归属的所述 ILR会话根密钥协商单元进 行会话根密钥协商时， 用于生成第二随机数， 并向 ILR会话根密钥协商单元 发送包含第二随机数和该会话的第二标识信息的会话根密钥生成参数； 以及 与 ILR会话根密钥协商单元相同的方式生成 Kas, 完成会话根密钥协商过程；
ILR会话根密钥协商单元与所述终端会话根密钥协商单元进行会话根密 钥协商时， 用于在收到会话根密钥生成参数后， 根据 和包含第二随机数、 第二标识信息及第一 ILR生成的第三随机数的第二参数， 通过第一密钥生成 算法生成 1^并保存第二标识信息与 Ka 々映射关系后， 将第三随机数返回给 终端会话根密钥协商单元。
在密钥协商过程中存在信令交互的两个设备之间为不安全链路时， 该两 个设备在进行密钥协商时， 还对传递的参数的完整性进行检验， 两个设备包 括主叫终端和主叫终端归属的 ILR ,被叫终端和被叫终端归属的 ILR , 以及主 叫终端和被叫终端中的一组或多组。
其中， 第二标识信息包括终端会话根密钥协商单元为本次会话分配的会 话索引（SI)和终端的用户身份标识 (SIDA), 终端同时存在的多个会话时， 为各 个会话分配不同的 SI, 通过会话根密钥协商过程为各个会话生成不同的 Ka;
终端生成会话密钥后， 以 SI为索引保存该会话密钥。
其中，第一密文包含用 Kas加密后的第一标识信息和第一随机数，该第一 标识信息包括终端为本次会话分配的会话索引 SI、 主叫终端的用户身份标识 SIDA和被叫终端的用户身份标识 SIDB。 上述主叫密钥协商模块还包括主叫密钥校验单元， 被叫密钥协商模块还 包括被叫密钥校验单元； 其中，
会话密钥获取单元， 还用于将会话密钥发送到被叫密钥校验单元； 被叫密钥校验单元， 用于根据会话密钥生成密钥校验数据， 并发送到主 叫密钥校验单元；
主叫密钥校验单元， 用于通过所述密钥校验数据验证所述会话密钥。 所述会话密钥还包括完整性校验密钥， 该完整性校验密钥是所述终端会 话密钥生成与发送单元和所述 ILR会话密钥生成与发送单元， 根据 Kas和包 含第一随机数的参数生成的；
被叫密钥校验单元将密钥校验数据发送到所述主叫密钥校验单元时， 是 根据收到的完整性校验密钥和包含第一标识信息、 第一随机数和自己生成的 第四随机数的第六参数， 通过完整性保护算法计算得到第四认证响应， 用会 话加密密钥对第四认证响应和第四随机数加密后生成密钥校验数据， 发送到 主叫密钥校验单元；
主叫密钥校验单元， 用会话加密密钥解密该密钥校验数据得到第四认证 响应和第四随机数， 用与第二终端得到第四认证响应相同的方式计算得到一 认证响应并与第四认证响应比较， 如两者不同， 则校验失败， 结束该会话的 密钥协商过程， 两者相同时， 校验通过。
当终端作为主叫终端与多个被叫终端进行会话时， 在终端会话根密钥协 商单元发起与第一个被叫终端的会话时， 与 ILR会话根密钥协商单元协商得 到 Kas并保存， 之后发起的与其余被叫终端的会话则直接根据该 Kas和各会话 对应生成的第一随机数生成各会话的会话密钥；
主叫终端通过为不同被叫终端生成和传递不同的第一随机数， 与不同的 被叫终端协商得到不同的会话密钥； 或者， 第一终端通过为不同被叫终端生 成和传递相同的第一随机数， 与不同的被叫终端协商得到相同的会话密钥。
被叫归属密钥协商模块与所述会话密钥获取单元上配置有共享的永久根 密钥 Kb:
密钥协商参数收发单元， 还用于收到密钥协商参数后生成第五随机数， 将该第五随机数与密钥协商参数一起发送到归属密钥协商模块， 被叫归属密钥协商模块， 还用于保存所述密钥协商参数收发单元发送来 的第五随机数和密钥协商参数中的第一标识信息； 以及收到所述 ILR会话密 钥生成与发送单元发送来的会话密钥后， 生成第六随机数， 根据 Kb和包含第 五随机数、 第六随机数和被叫终端的用户身份标识的第七参数生成临时加密 密钥 Kbt, 用 Kbt对包含会话密钥的第八参数加密后， 将得到的密文和第六随 机数发送给会话密钥获取单元；
会话密钥获取单元， 还用于在收到被叫归属密钥协商模块发来的密文和 第六随机数后， 用与被叫归属密钥协商模块相同的方式生成 Kbt, 用 Kbt解密 被叫归属密钥协商模块发来的密文得到会话密钥。
本文涉及的名词缩写如下表：
Figure imgf000030_0001
fl5 UEA和 UEB的之间会话完整性校验密钥的密钥生 成算法， 即由 Kas生成 KabINT的算法。
fl6 一种完整性保护算法， 保护算法中涉及的几个参 数的完整性， 可以是 MAC或 SHA等算法， 本文 不指定具体的算法。
fl7 一种加密算法， 对 UEA和 UEB数据加密，本文不 指定具体的算法。
fl8 一种完整性保护算法，用于 ILRB对 UEB的认证。 fl9 生成临时加密密钥 Kbt生成算法， 本文不指定具 体的算法。
no 一种完整性保护算法， 用于 ILRB和 UEB之间传 递密钥的正确性。
m 一种加密算法， 用于对 ILRB和 UEB之间传递的 密钥进行力口密。
m 一种完整性保护算法，釆用 KabINT计算，用于 UEB 向 UEA "建立端到端会话密钥响应"应答密钥已 正确收到。
£23 一种加密算法， 釆用 KabENC计算， 用于 UEB向
UEA传送 "建立端到端会话密钥响应" 应答时加
Ί 。
GAA 通 用 鉴 权 架 构 ( Generic Authentication
Architecture )
GBA 通 用 自 引 导 架 构 Generic Bootstrapping
Architecture
ILRA 身 份位置哥存器 ( Identification Location
Register ) ， 本文简称 "认证服务器" ， 本文主要 用其实现会话密钥生成和分发。 ILRA表示用户终 端 UEA的认证和密钥管理服务器， ILRB表示用户 终端 UEB的认证和密钥管理服务器， 当 UEA和 UEB在同一个认证服务器下时， ILRA和 ILRB可 以是同一个服务器 ILR。
ILRB ILRA表示用户终端 UEA的认证和密钥管理服务 器， ILRB表示用户终端 UEB的认证和密钥管理服 务器， 当 UEA和 UEB在同一个认证服务器下时， ILRA和 ILRB可以是同一个服务器 ILR。
Ka UEA和 ILRA共享的永久根密钥， 用于生成 UEA
的会话密钥 Kas。
Kat UEA和 ILRA的完整性校验密钥， 可以预先共享， 也可以每次从 Ka和 RANDA推导而来，也可以由 其他方式（如注册认证的时候推导）推导出来。
Kas 由 Ka生成的会话根密钥 Kas,每个以 SI为索引的 的会话生成的 Kas都不同， 此密钥保存于 UEA和 ILRA中， 后续用来根据 ANDA2B生成会话密钥
KabENC和 KablNT
KabENC UEA和 UEB会话的加密密钥。
KabINT UEA和 UEB会话的完整性校验密钥。
Kb UEB和 ILRB共享的会话根密钥， 用于生成 UEB
的会话密钥 Kbs,并且生成 UEB和 ILRB临时加密 密钥 Kbt
K UEB和 ILRB的临时加密密钥， 生成方式类似于
Kat。
KDN KDN(Key Derived Number)表示协商的会话根密 钥后续可使用的次数， 0表示可以无限制派生， 通常用于不能确定参会人数的会议会话； 1表示 只能派生一次， 通常用于 1对 1的会话； 其他大 于 1的整数， 表示有固定参会人的会议电话。 也 就是说，等于或大于 1的会话都有固定参与人数， 这样 ILR可以在密钥申请数量达到使用人数限制 时删除密钥， 使密钥管理更安全和高效。
KMS 密铜管理月良务器 ( Key Management Server )
Otway-Rees 一种密钥协商算法
RANDA 由终端 UEA生成的随机数
ANDILR 由 ILRA生成的随机数
RANDA2B 由终端 UEA生成的随机数， 传递给 UEB使用
RANDB 由终端 UEB生成的随机数， 传递给 ILRB使用
RANDB2A 由终端 UEB生成的随机数， 传递给 UEA使用
RESA 由 UEA给出的完整性校验结果， 用于 ILRA验证
"会话根密钥协商请求" 是否的确为 UEA发来 的。
RESA2B 由 UEA给出的完整性校验结果， 用于 UEB验证
"建立端到端会话密钥请求" 是否的确为 UEA 发来的。
RESB 由 UEB给出的完整性校验结果， 用于 ILRB认证
UE
RESiLR2A 由 ILRA给出的完整性校验结果， 用于 UEA验证
"会话根密钥协商响应" 是否的确为 ILRA发来 的。
RESiLR2B 由 ILRB给出的完整性校验结果， 用于 UEB验证
"获取端到端密钥响应" 是否的确为 ILRB发来 的。
RESB2A 由 UEB给出的完整性校验结果， 用于 UEA验证
"建立端到端会话密钥响应"是否的确为 UEB发 来的。
SDES 安全描述方法 ( Security Descriptions ) , 一种将 端到端密钥封装在端到端信令中的密钥协商方 法。
SI 表示会话索引 （ Session Index ) , 因为一个终端 可以有多个会话， 每个会话应协商不同的密钥， 而每个会话也可能有不同数量的被叫， 如存在会 议电话时， 在会议电话时， 主叫和被叫之间可以 有相同的密钥， 也可以有不同的密钥， SI标识用 于 UEA告诉 ILRA协商的会话密钥属于哪一个具 体的会话。
SIDA 用 户 终端 UEA 的 身 份标识（Subscriber
IDentification )
SIDB 用 户 终端 UEB 的 身 份标识（Subscriber
IDentification )
SRTP 安全实时传输协议 ( Secure Real-time Transport
Protocol )
TICKET 一种密钥协商方法， 不直接传送密钥， 而传送一 个加密的密钥索引
UEA 用户终端 (User Equipment)A
UEB 用户终端 (User Equipment)B
XRESA 由 ILRA给出的完整性校验结果， 用于 ILRA验证
"会话根密钥协商请求" 是否的确 UEA为发来 的。
XRESA2B 由 UEA给出的完整性校验结果， 用于 UEB验证
"建立端到端会话密钥请求" 是否的确为 UEA 发来的。
XRESB 由 ILRB给出的完整性校验结果， 用于 ILRB认证
UE 55 XRESiLR2A 由 ILRA给出的完整性校验结果， 用于 UEA验证
"会话根密钥协商响应" 是否的确为 ILRA发来 的。
56 XRESiLR2B 由 ILRB给出的完整性校验结果， 用于 UEB验证
"获取端到端密钥响应" 是否的确为 ILRB发来 的。
57 XRESB2A 由 UEB给出的完整性校验结果， 用于 UEA验证
"建立端到端会话密钥响应"是否的确为 UEB发 来的。
尽管为示例目的， 已经公开了本发明的优选实施例， 本领域的技术人员 将意识到各种改进、 增加和取代也是可能的， 因此， 本发明的范围应当不限 于上述实施例。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。
工业实用性
本发明避免了密钥协商随会话场景不同而流程不同， 对防止中间人攻击 有较大改进， 提高了会话密钥传递的安全性， 并可以为同一个会话的多个对 端分配相同的密钥， 改善了多会话时不同密钥导致终端性能的下降。

Claims

权 利 要 求 书
1、 一种支持合法监听的端到端会话密钥协商的方法， 其包括：
第一终端与其归属的第一身份位置寄存器 (ILR)进行会话根密钥协商， 生 成本次会话的会话根密钥 Kas并保存后，第一终端根据包含自己生成的第一随 机数的第一参数和 Kas生成会话密钥， 并向第二终端发起端到端会话密钥请 求，携带的密钥协商参数包括用 Kas加密得到的包含第一随机数信息的第一密 文以及所述会话的第一标识信息；
第二终端在第一 ILR为其归属 ILR时， 将收到的密钥协商参数直接发送 到第一 ILR, 否则经其归属的第二 ILR发送到第一 ILR; 第一 ILR利用 Kas 解密第一密文获取所述第一随机数， 用与第一终端相同的方式生成会话密钥 并保存后， 直接以密文方式发送给第二终端， 或者先发送给第二 ILR, 第二 ILR保存该会话密钥并以密文方式将该会话密钥发送给第二终端； 以及
第二终端解密所述密文， 获取其中的会话密钥， 第一终端和所述第二终 端使用该会话密钥进行会话， 该会话密钥包括会话加密密钥。
2、 如权利要求 1所述的方法， 其中， 第一终端和第一 ILR配置有共享的 永久根密钥 Ka, 所述第一终端与其归属的第一 ILR进行会话根密钥协商的步 骤包括：
第一终端生成第二随机数， 并向第一 ILR发送包含第二随机数和所述会 话的第二标识信息的会话根密钥生成参数；
第一 ILR收到后， 根据 Ka和包含第二随机数、 第二标识信息及第一 ILR 生成的第三随机数的第二参数，通过第一密钥生成算法生成 Kas并保存第二标 识信息与 Kas的映射关系后， 将第三随机数返回给第一终端； 以及
第一终端用与第一 ILR相同的方式生成 Kas, 完成会话根密钥协商。
3、 如权利要求 1所述的方法， 其中，
在密钥协商过程中存在信令交互的两个设备之间为不安全链路时， 所述 方法还包括： 该两个设备在进行密钥协商时， 还对传递的参数的完整性进行 检验， 所述两个设备包括第一终端和第一 ILR, 第二终端和其归属的 ILR, 以 及第一终端和第二终端中的一组或多组。
4、 如权利要求 2所述的方法， 其中， 所述第一终端与其归属的第一 ILR 进行会话根密钥协商的步骤还包括：
第一终端向第一 ILR发送会话根密钥生成参数时， 还将第一认证响应传 递给第一 ILR, 第一认证响应是第一终端根据 和至少部分会话根密钥生成 参数生成临时消息完整校验密钥 Kat后，以至少部分会话根密钥生成参数为第 三参数， 用 Kat通过第一完整性保护算法计算得到的；
第一 ILR收到会话根密钥生成参数和第一认证响应后， 先根据保存的 Ka 和收到的会话根密钥生成参数， 用与第一终端得到第一认证响应相同的方式 计算得到一认证响应并与第一认证响应比较， 如两者不同， 则认证失败， 结 束该会话的密钥协商过程， 如两者相同， 再执行生成 Kas的步骤。
5、 如权利要求 2所述的方法， 其中， 所述第一终端与其归属的第一 ILR 进行会话根密钥协商的步骤还包括：
第一 ILR向第一终端发送第三随机数时， 还将第二认证响应传递给第一 终端， 第二认证响应是第一 ILR根据 Kas以及包含第三随机数和至少部分会 话根密钥生成参数的第四参数， 通过第二完整性保护算法计算得到的；
该方法还包括： 第一终端生成 Kas后， 先用与第一 ILR得到第三认证响 应相同的方式计算得到一认证响应并与第二认证响应比较， 如两者不同， 则 认证失败， 结束该会话的密钥协商过程， 如两者相同， 再执行生成会话密钥 的步骤。
6、 如权利要求 2所述的方法， 其中， 所述第二标识信息包括第一终端为 本次会话分配的会话索引（SI)和第一终端的用户身份标识 (SIDA);
所述方法还包括：
第一终端同时存在的多个会话时， 为各个会话分配不同的 SI, 通过会话 根密钥协商过程为各个会话生成不同的 Ka; 以及
第一终端生成会话密钥后， 以 SI为索引保存该会话密钥。
7、 如权利要求 2所述的方法， 其中，
所述会话根密钥生成参数还包括密钥可推导次数， 用于表示设定的可利 用 Kas生成会话密钥的次数；
所述第一终端与其归属的第一 ILR进行会话根密钥协商的步骤还包括： 第一 ILR收到所述会话根密钥生成参数后， 实时控制该 Kas生成会话密钥的 次数不超过该密钥可推导次数。
8、 如权利要求 7所述的方法， 其中，
所述密钥可推导次数为 0时表示次数不限制，可利用 1^生成任意次会话 密钥； 所述密钥可推导次数为 1时表示只能有一个被叫，可利用 1^生成一次 会话密钥； 所述密钥可推导次数为 n时表示固定只能有 n个被叫， 可利用 Kas 生成 n次会话密钥。
9、 如权利要求 1或 2或 3或 4或 5所述的方法， 其中，
所述第一密文包含用 Kas加密后的第一标识信息和第一随机数，该第一标 识信息包括第一终端为本次会话分配的会话索引 SI、 第一终端的用户身份标 识 SIDA和第二终端的用户身份标识 SIDB。
10、 如权利要求 1或 8所述的方法， 其中，
第一终端生成的第一密文还包含用 Kas加密后的第三认证响应，该第三认 证响应是第一终端根据 Kas及包含第一标识信息和第一随机数的第五参数，通 过第三完整性保护算法计算得到的；
所述方法还包括： 第一 ILR收到第二终端发来的密钥协商参数， 根据其 中的第一标识信息检索到的 Kas对第一密文解密，获取第一随机参数后，先用 与第一终端得到第三认证响应相同的方式计算得到一认证响应并与第三认证 响应比较， 如两者不同， 则认证失败， 结束该会话的密钥协商过程， 如两者 相同， 再执行用与第一终端相同的方式生成所述会话密钥的步骤。
11、 如权利要求 1或 2或 3或 4或 5所述的方法， 该方法还包括： 第二终端解密第二 ILR发送的密文， 获取其中的会话密钥后， 还通过密 钥校验数据请求第一终端验证， 第一终端验证通过后， 再执行第一终端和第 二终端使用该会话密钥进行会话的步骤。
12、 如权利要求 11所述的方法， 其中， 第一终端生成的会话密钥还包括 完整性校验密钥，该完整性校验密钥是第一终端根据 Kas和包含第一随机数的 参数生成的；
所述方法还包括：
第一 ILR收到密钥协商参数后， 用与第一终端相同的方式生成该完整性 校验密钥并发送到第二终端；
第二终端通过密钥校验数据请求第一终端验证时， 根据收到的完整性校 验密钥和包含第一标识信息、 第一随机数和自己生成的第四随机数的第六参 数， 通过完整性保护算法计算得到第四认证响应， 用会话加密密钥对第四认 证响应和第四随机数加密后生成密钥校验数据， 发送到第一终端；
第一终端用会话加密密钥解密该密钥校验数据得到第四认证响应和第四 随机数， 用与第二终端得到第四认证响应相同的方式计算得到一认证响应并 与第四认证响应比较， 如两者不同， 则校验失败， 结束该会话的密钥协商过 程， 两者相同时， 校验通过。
13、 如权利要求 1或 2或 3或 4或 5所述的方法， 该方法还包括： 第一终端作为主叫终端与多个被叫终端进行会话时， 在发起与第一个被 叫终端的会话时与第一 ILR协商得到 Kas并保存， 之后发起的与其余被叫终 端的会话则直接根据该 Kas和各会话对应生成的第一随机数生成各会话的会 话密钥；
第一终端通过为不同被叫终端生成和传递不同的第一随机数， 与不同的 被叫终端协商得到不同的会话密钥； 或者， 第一终端通过为不同被叫终端生 成和传递相同的第一随机数， 与不同的被叫终端协商得到相同的会话密钥。
14、 如权利要求 1或 2或 3或 4所述的方法， 该方法还包括：
第二终端收到第一终端发来的密钥协商参数后， 生成第五随机数， 将该 第五随机数与密钥协商参数一起发送到第二终端归属的 ILR, 第二终端归属 的 ILR保存第五随机数和密钥协商参数中的第一标识信息；
第二终端归属的 ILR在收到或生成会话密钥后， 生成第六随机数， 根据 与第二终端共享的永久根密钥 Kb和包含第五随机数、第六随机数和第二终端 的用户身份标识的第七参数生成临时加密密钥 Kbt, 用 Kbt对包含会话密钥的 第八参数加密后， 将得到的密文和第六随机数发送给第二终端；
第二终端收到其归属的 ILR发来的密文和第六随机数后， 用与第二终端 归属的 ILR相同的方式生成 Kbt, 用 Kbt解密 ILR发来的密文得到会话密钥。
15、 如权利要求 14所述的方法， 该方法还包括：
第二终端还将第五认证响应和第五随机数、 密钥协商参数一起发送到第 二终端归属的 ILR, 该第五认证响应是第二终端根据 Kb和包含第一标识信息 和第五随机数的参数， 通过完整性保护算法计算得到的；
第二终端归属的 ILR收到第五认证响应、第五随机数和密钥协商参数后， 用与第二终端得到第五认证响应相同的方式计算得到一认证响应并与第五认 证响应比较， 如两者不同， 则协商失败， 结束该会话的密钥协商过程， 如两 者相同， 在第一 ILR为第二终端归属的 ILR时， 再解密该密钥协商参数中的 第一密文， 否则再将该密钥协商参数发送到第一 ILR。
16、 如权利要求 14所述的方法， 其中，
第二终端归属的 ILR用 Kbt加密的第八参数还包括第六认证响应， 该第 五认证响应是第二终端归属的 ILR根据会话加密密钥和包含第五随机数和第 六随机数的参数， 通过完整性保护算法计算得到的；
所述方法还包括： 第二终端解密第二终端归属的 ILR发来的密文， 得到 会话加密密钥后， 先用与第二终端归属的 ILR得到第六认证响应相同的方式 计算得到一认证响应并与第六认证响应比较， 如两者不同， 则协商失败， 结 束该会话的密钥协商过程， 如两者相同， 再生成密钥校验数据请求并发送到 第一终端， 第一终端验证通过后， 再执行第一终端和第二终端使用该会话密 钥进行会话的步骤。
17、 一种支持合法监听的端到端会话密钥协商的系统， 所述系统包括终 端和身份位置寄存器 (ILR)；
所述终端包括主叫密钥协商模块和被叫密钥协商模块， 所述主叫密钥协 商模块包括终端会话根密钥协商单元和终端会话密钥生成与发送单元； 被叫 密钥协商模块包括密钥协商参数收发单元和会话密钥获取单元；
所述 ILR包括主叫归属密钥协商模块和被叫归属密钥协商模块， 主叫归 属密钥协商模块包括 ILR会话根密钥协商单元和 ILR会话密钥生成与发送单 元；
所述终端会话根密钥协商单元设置为： 与所述终端归属的所述 ILR会话 根密钥协商单元进行会话根密钥协商，生成本次会话的会话根密钥 Kas并保存 后， 发送给所述终端会话密钥生成与发送单元；
所述终端会话密钥生成与发送单元设置为：接收到会话根密钥 Kas后，根 据包含自己生成的第一随机数的第一参数和 Kas生成会话密钥，并向所述密钥 协商参数收发单元发送密钥协商参数发起端到端会话密钥请求， 所述密钥协 商参数包括用 Kas加密得到的包含第一随机数信息的第一密文以及所述会话 的第一标识信息； 所述会话密钥包括会话加密密钥；
所述密钥协商参数收发单元设置为： 将收到的密钥协商参数发送到被叫 归属密钥协商模块；
所述会话密钥获取单元设置为：解密被叫归属密钥协商模块发送的密文， 获取其中的会话密钥； 所述 ILR会话根密钥协商单元设置为： 与所述终端会话根密钥协商单元 进行会话根密钥协商，生成本次会话的会话根密钥 Kas并保存后，将所述会话 根密钥 Kas发送给所述 ILR会话密钥生成与发送单元；
所述 ILR会话密钥生成与发送单元设置为： 利用所述 ILR会话根密钥协 商单元发送来的 Kas解密所述被叫归属密钥协商模块发送来的第一密文，获取 第一随机数， 并用与所述终端会话密钥生成与发送单元相同的方式生成会话 密钥并保存后， 发送给被叫归属密钥协商模块；
所述被叫归属密钥协商模块设置为： 将所述密钥协商参数收发单元发送 来的密钥协商参数发送到所述 ILR会话密钥生成与发送单元，以及将所述 ILR 会话密钥生成与发送单元发送来的会话密钥加密生成密文后发送给所述会话 密钥获取单元。
18、 如权利要求 17所述的系统， 其中， 所述终端会话根密钥协商单元和 所述 ILR会话根密钥协商单元上配置有共享的永久根密钥 Ka;
所述终端会话根密钥协商单元是设置为以如下方式与所述终端归属的所 述 ILR会话根密钥协商单元进行会话根密钥协商： 生成第二随机数， 并向所 述 ILR会话根密钥协商单元发送包含第二随机数和所述会话的第二标识信息 的会话根密钥生成参数； 以及与所述 ILR会话根密钥协商单元相同的方式生 成 Kas, 完成会话根密钥协商过程；
所述 ILR会话根密钥协商单元是设置为以如下方式与所述终端会话根密 钥协商单元进行会话根密钥协商： 在收到会话根密钥生成参数后， 根据 和 包含第二随机数、 第二标识信息及第一 ILR生成的第三随机数的第二参数， 通过第一密钥生成算法生成 Kas并保存第二标识信息与 Kas的映射关系后， 将 第三随机数返回给所述终端会话根密钥协商单元。
19、 如权利要求 17或 18所述的系统， 其中，
在密钥协商过程中存在信令交互的两个设备之间为不安全链路时， 该两 个设备在进行密钥协商时， 还设置为对传递的参数的完整性进行检验， 所述 两个设备包括主叫终端和主叫终端归属的 ILR , 被叫终端和被叫终端归属的 ILR , 以及主叫终端和被叫终端中的一组或多组。
20、 如权利要求 19所述的系统， 其中，
所述第二标识信息包括所述终端会话根密钥协商单元为本次会话分配的 会话索引（SI)和终端的用户身份标识 (SIDA);
终端同时存在的多个会话时， 还设置为： 为各个会话分配不同的 SI, 通 过会话根密钥协商过程为各个会话生成不同的 Ka; 生成会话密钥后， 以 SI 为索引保存该会话密钥。
21、 如权利要求 17或 18或 20所述的系统， 其中，
所述第一密文包含用 Kas加密后的第一标识信息和第一随机数，该第一标 识信息包括终端为本次会话分配的会话索引 SI、 主叫终端的用户身份标识 SIDA和被叫终端的用户身份标识 SIDB。
22、 如权利要求 17或 18所述的系统， 其中， 所述主叫密钥协商模块还 包括主叫密钥校验单元， 所述被叫密钥协商模块还包括被叫密钥校验单元； 所述会话密钥获取单元还设置为： 将会话密钥发送到所述被叫密钥校验 单元；
所述被叫密钥校验单元设置为： 根据所述会话密钥生成密钥校验数据， 并发送到所述主叫密钥校验单元；
所述主叫密钥校验单元， 设置为： 通过所述密钥校验数据验证所述会话 密钥。
23、 如权利要求 22所述的系统， 其中，
所述会话密钥还包括完整性校验密钥， 该完整性校验密钥是由所述终端 会话密钥生成与发送单元和所述 ILR会话密钥生成与发送单元， 根据 Kas和 包含第一随机数的参数生成的；
所述被叫密钥校验单元是设置为： 根据收到的完整性校验密钥和包含第 一标识信息、 第一随机数和自己生成的第四随机数的第六参数， 通过完整性 保护算法计算得到第四认证响应， 用会话加密密钥对第四认证响应和第四随 机数加密后生成密钥校验数据， 发送到主叫密钥校验单元；
所述主叫密钥校验单元是设置为： 用会话加密密钥解密该密钥校验数据 得到第四认证响应和第四随机数， 用与第二终端得到第四认证响应相同的方 式计算得到一认证响应并与第四认证响应比较， 如两者不同， 则校验失败， 结束该会话的密钥协商过程， 两者相同时， 校验通过。
24、 如权利要求 17或 18所述的系统， 其中，
所述终端作为主叫终端与多个被叫终端进行会话时， 在所述终端会话根 密钥协商单元发起与第一个被叫终端的会话时， 与所述 ILR会话根密钥协商 单元协商得到 Kas并保存， 之后发起的与其余被叫终端的会话则直接根据该 Kas和各会话对应生成的第一随机数生成各会话的会话密钥； 所述主叫终端通过为不同被叫终端生成和传递不同的第一随机数， 与不 同的被叫终端协商得到不同的会话密钥； 或者， 第一终端通过为不同被叫终 端生成和传递相同的第一随机数， 与不同的被叫终端协商得到相同的会话密 钥。
25、 如权利要求 17或 18所述的系统， 其中， 所述被叫归属密钥协商模 块与所述会话密钥获取单元上配置有共享的永久根密钥 Kb:
所述密钥协商参数收发单元还设置为： 收到密钥协商参数后生成第五随 机数， 将该第五随机数与密钥协商参数一起发送到被叫归属密钥协商模块， 所述被叫归属密钥协商模块还设置为： 保存所述密钥协商参数收发单元 发送来的第五随机数和密钥协商参数中的第一标识信息； 以及收到所述 ILR 会话密钥生成与发送单元发送来的会话密钥后， 生成第六随机数， 根据 Kb和 包含第五随机数、 第六随机数和被叫终端的用户身份标识的第七参数生成临 时加密密钥 Kbt, 用 Kbt对包含会话密钥的第八参数加密后， 将得到的密文和 第六随机数发送给会话密钥获取单元；
所述会话密钥获取单元还设置为： 在收到被叫归属密钥协商模块发来的 密文和第六随机数后， 用与被叫归属密钥协商模块相同的方式生成 Kbt, 用 Kbt解密被叫归属密钥协商模块发来的密文得到会话密钥。
PCT/CN2010/075904 2009-10-10 2010-08-11 一种支持合法监听的端到端会话密钥协商方法和系统 WO2011041962A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910181130.9 2009-10-10
CN200910181130.9A CN102045210B (zh) 2009-10-10 2009-10-10 一种支持合法监听的端到端会话密钥协商方法和系统

Publications (1)

Publication Number Publication Date
WO2011041962A1 true WO2011041962A1 (zh) 2011-04-14

Family

ID=43856368

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/075904 WO2011041962A1 (zh) 2009-10-10 2010-08-11 一种支持合法监听的端到端会话密钥协商方法和系统

Country Status (2)

Country Link
CN (1) CN102045210B (zh)
WO (1) WO2011041962A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120275598A1 (en) * 2011-04-29 2012-11-01 Nokia Corporation Method and apparatus for providing service provider-controlled communication security

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9544334B2 (en) * 2011-05-11 2017-01-10 Alcatel Lucent Policy routing-based lawful interception in communication system with end-to-end encryption
CN103986723B (zh) * 2014-05-28 2017-12-05 大唐移动通信设备有限公司 一种保密通信控制、保密通信方法及装置
CN105873039B (zh) * 2015-01-19 2019-05-07 普天信息技术有限公司 一种移动自组网络会话密钥生成方法及终端
CN108259428B (zh) * 2016-12-29 2020-10-09 大唐半导体设计有限公司 一种实现数据传输的系统和方法
WO2018120017A1 (en) * 2016-12-30 2018-07-05 Intel Corporation Techniques for key exchange to establish secure connection in network function virtualization environment
CN108347330A (zh) * 2017-01-24 2018-07-31 北京百度网讯科技有限公司 一种安全通信的方法和装置
CN110493774B (zh) * 2017-05-06 2023-09-26 华为技术有限公司 密钥配置方法、装置以及系统
CN107948183B (zh) * 2017-12-06 2021-02-02 深圳数字电视国家工程实验室股份有限公司 一种适用于物联网的密钥分配方法及系统
CN109495248B (zh) * 2018-11-23 2021-07-20 曹鸣佩 基于秘密共享方案的可监察隐私通信方法
CN111835691B (zh) * 2019-04-22 2022-09-27 中国移动通信有限公司研究院 一种认证信息处理方法、终端和网络设备
CN112242977A (zh) * 2019-07-18 2021-01-19 深圳市文鼎创数据科技有限公司 一种数据传输方法及数据传输系统
CN114765546B (zh) * 2020-12-30 2023-07-18 海能达通信股份有限公司 端到端硬加密方法、系统、加密设备、密钥管理服务器
CN116866909A (zh) * 2023-05-11 2023-10-10 长江量子(武汉)科技有限公司 双耳耳机密钥同步方法及双耳加密耳机

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921378A (zh) * 2006-09-28 2007-02-28 中国移动通信集团公司 一种协商新鉴权密钥的方法和系统
CN101340443A (zh) * 2008-08-28 2009-01-07 中国电信股份有限公司 一种通信网络中会话密钥协商方法、系统和服务器
WO2009005698A1 (en) * 2007-06-28 2009-01-08 Applied Identity Computer security system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101052033B (zh) * 2006-04-05 2012-04-04 华为技术有限公司 基于ttp的认证与密钥协商方法及其装置
CN100579010C (zh) * 2007-05-09 2010-01-06 中兴通讯股份有限公司 密钥生成及传输方法和系统
CN101420297B (zh) * 2008-09-08 2010-11-03 北京飞天诚信科技有限公司 协商密钥的方法和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921378A (zh) * 2006-09-28 2007-02-28 中国移动通信集团公司 一种协商新鉴权密钥的方法和系统
WO2009005698A1 (en) * 2007-06-28 2009-01-08 Applied Identity Computer security system
CN101340443A (zh) * 2008-08-28 2009-01-07 中国电信股份有限公司 一种通信网络中会话密钥协商方法、系统和服务器

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120275598A1 (en) * 2011-04-29 2012-11-01 Nokia Corporation Method and apparatus for providing service provider-controlled communication security
US9450752B2 (en) * 2011-04-29 2016-09-20 Nokia Technologies Oy Method and apparatus for providing service provider-controlled communication security

Also Published As

Publication number Publication date
CN102045210A (zh) 2011-05-04
CN102045210B (zh) 2014-05-28

Similar Documents

Publication Publication Date Title
WO2011041962A1 (zh) 一种支持合法监听的端到端会话密钥协商方法和系统
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
WO2017185999A1 (zh) 密钥分发、认证方法，装置及系统
WO2017185692A1 (zh) 密钥分发、认证方法，装置及系统
US7269730B2 (en) Method and apparatus for providing peer authentication for an internet key exchange
US7813509B2 (en) Key distribution method
CN109302412B (zh) 基于CPK的VoIP通信处理方法、终端、服务器及存储介质
US20060059344A1 (en) Service authentication
EP1374533B1 (en) Facilitating legal interception of ip connections
KR20080089500A (ko) 모바일 네트워크를 기반으로 하는 엔드 투 엔드 통신에서의 인증을 위한 방법, 시스템 및 인증 센터
JP5192077B2 (ja) Ｖｐｎによる秘匿通信方法、そのシステム、そのプログラム、並びに、そのプログラムの記録媒体
WO2011038620A1 (zh) 一种移动通讯网络中的接入认证方法、装置及系统
US20080137859A1 (en) Public key passing
CN113904809B (zh) 一种通信方法、装置、电子设备及存储介质
WO2010124482A1 (zh) Ip多媒体子系统中实现安全分叉呼叫会话的方法及系统
WO2007073659A1 (fr) Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
CN101790160A (zh) 安全协商会话密钥的方法及装置
WO2009082950A1 (fr) Procédé, dispositif et système de distribution de clés
WO2012024905A1 (zh) 一种移动通讯网中数据加解密方法、终端和ggsn
CN116321158B (zh) 基于证书的本地ue认证
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
JP4677784B2 (ja) 集合型宅内ネットワークにおける認証方法及びシステム
WO2018222133A2 (zh) 数据保护方法、装置以及系统
CN1996838A (zh) 一种多主机WiMAX系统中的AAA认证优化方法
CN110933673B (zh) 一种ims网络的接入认证方法

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

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

Country of ref document: EP

Kind code of ref document: A1