Method, apparatus and device for establishing session initiation protocol communication, and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for establishing a session initiation protocol communication, relating to the field of communication security technology. The method includes: obtaining elliptic curve parameters, generators, and a hash function; generating a server key pair based on the elliptic curve parameters and generators; receiving a registration request carrying a user identifier and a user public key; assigning a salt value to the user identifier; and generating a verification credential based on the user public key, server private key, salt value, and hash function; receiving an authentication request carrying a user-side temporary public key and a user-side signature; verifying the user-side signature based on the user public key; generating a server-side temporary public key upon successful verification; and generating a session key based on the user-side temporary public key and server private key using a hash function; returning an authentication response carrying the server-side temporary public key and server-side signature; and establishing an encrypted session based on the session key after receiving a confirmation message. This application can improve the security of session initiation protocol communication.

Description

Technical Field

[0001] This application relates to the field of communication security technology, and in particular to a method, apparatus, device, and storage medium for establishing session initiation protocol communication. Background Technology

[0002] The existing authentication scheme of the Session Initiation Protocol (SIP) is vulnerable to security attacks such as offline password guessing, resulting in security risks in SIP communication. Therefore, improving the security of SIP communication remains an issue that needs to be addressed.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, and storage medium for establishing session initiation protocol communication, aiming to solve the technical problem of how to improve the security of session initiation protocol communication.

[0005] To achieve the above objectives, this application proposes a method for establishing session initiation protocol communication, the method comprising: Obtain the elliptic curve parameters, generators, and hash function, and generate a server private key and a server public key based on the elliptic curve parameters and the generators; The system receives a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assigns a salt value to the user identifier, and generates a verification credential based on the user public key, the server private key, the salt value, and the hash function. When a session is established, an authentication request sent by the user terminal is received. The authentication request carries a user-side temporary public key and a user-side signature. The validity of the user-side signature is verified based on the user-side public key. If the verification is successful, a server-side temporary public key is generated. A session key is generated based on the user-side temporary public key, the server private key, and the hash function. An authentication response is returned to the user terminal, a confirmation message is received from the user terminal, the validity of the confirmation message is verified, and an encrypted session is established based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

[0006] In one embodiment, the step of generating verification credentials based on the user's public key, the server's private key, the salt value, and the hash function includes: Concatenate the user's public key, the server's private key, and the salt value into a first byte string in sequence; The first byte string is hashed using the hash function to obtain the verification credential.

[0007] In one embodiment, the step of verifying the legality of the user-side signature based on the user's public key includes: The user identifier, the user-side temporary public key, the server public key, and the salt value are hashed using the hash function to obtain the user-side authentication message; Determine whether the dot product of the user-side signature and the generator is equal to the dot product of the user's public key and the user-side authentication message. If they are equal, the user-side signature is valid.

[0008] In one embodiment, the step of generating a session key based on the user-side temporary public key, the server private key, and the hash function includes: The first shared secret is obtained by performing a dot product operation between the user-side temporary public key and the server private key; The second shared secret is obtained by multiplying the server-side random number with the user's public key. The first shared secret, the second shared secret, the user-side temporary public key, and the server-side temporary public key are concatenated in sequence into a second byte string. The second byte string is then hashed using the hash function to obtain the session key.

[0009] In one embodiment, before the step of returning an authentication response to the user terminal, the method further includes: The session key, the server-side temporary public key, the verification credential, and the user identifier are concatenated in sequence into a third byte string. The hash function is then used to hash the third byte string to obtain the server-side authentication message. The server's private key is multiplied by the server-side authentication message to obtain the server-side signature.

[0010] In one embodiment, the step of verifying the legality of the confirmation message includes: The session key, the user-side temporary public key, and the server-side temporary public key are concatenated in sequence into a fourth byte string; The fourth byte string is hashed using the hash function to obtain an acknowledgment digest. Determine whether the confirmation message is equal to the confirmation digest; if they are equal, the confirmation message is valid.

[0011] In one embodiment, after the step of establishing an encrypted session based on the session key, the method further includes: Receive a password update request sent by the user terminal, the password update request carrying a new user public key and an update signature; The validity of the updated signature is verified based on the user's public key. If the verification is successful, the current user's public key is updated to the new user's public key. The hash function is used to process the new user's public key, the server's private key, and the salt value to generate the current verification credential.

[0012] Furthermore, to achieve the above objectives, this application also proposes a session initiation protocol communication establishment apparatus, which includes: The acquisition module is used to acquire elliptic curve parameters, generators, and hash functions, and generate server private keys and server public keys based on the elliptic curve parameters and generators. The receiving module is used to receive a registration request sent by a user terminal. The registration request carries a user identifier and a user public key. A salt value is assigned to the user identifier, and a verification credential is generated based on the user public key, the server private key, the salt value, and the hash function. The authentication module is used to receive an authentication request sent by the user terminal when the session is established. The authentication request carries a user-side temporary public key and a user-side signature. The module verifies the legality of the user-side signature based on the user-side public key. After successful verification, it generates a server-side temporary public key and generates a session key based on the user-side temporary public key, the server private key, and the hash function. The module is configured to return an authentication response to the user terminal, receive a confirmation message returned by the user terminal, verify the legality of the confirmation message, and establish an encrypted session based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

[0013] In addition, to achieve the above objectives, this application also proposes a device for establishing session initiation protocol communication, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the session initiation protocol communication establishment method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the session initiation protocol communication establishment method as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the session initiation protocol communication establishment method as described above.

[0016] This application provides a method for establishing session initiation protocol communication. The method involves obtaining elliptic curve parameters, generators, and a hash function, and generating a server private key and a server public key based on the elliptic curve parameters and the generators. It receives a registration request from a user terminal, the registration request carrying a user identifier and a user public key. A salt value is assigned to the user identifier, and a verification credential is generated based on the user public key, the server private key, the salt value, and the hash function. During session establishment, the method receives an authentication request from the user terminal, the authentication request carrying a user-side temporary public key and a user-side signature. The method verifies the legality of the user-side signature based on the user public key. Upon successful verification, a server-side temporary public key is generated, and a session key is generated based on the user-side temporary public key, the server private key, and the hash function. An authentication response is returned to the user terminal, and a confirmation message returned by the user terminal is received. The legality of the confirmation message is verified. Upon successful verification, an encrypted session is established based on the session key. The authentication response carries the server-side temporary public key and the server-side signature. This application generates verification credentials using the user's public key and the server's private key during the registration phase to achieve passwordless storage on the server. During the authentication phase, it verifies the user's identity based on elliptic curve signature and negotiates a dynamic session key, thereby effectively ensuring the legitimacy of two-way identity and improving the security of the initial protocol communication in the session. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the method for establishing session initialization protocol communication in this application (Example 1); Figure 2 A schematic diagram of the user registration process provided in Embodiment 1 of the method for establishing session initial protocol communication in this application; Figure 3 A schematic diagram of the session authentication and key negotiation process provided in Embodiment 1 of the method for establishing session initial protocol communication in this application; Figure 4 A flowchart illustrating the second embodiment of the method for establishing session initialization protocol communication in this application; Figure 5 A schematic diagram of the password update process provided in Embodiment 2 of the method for establishing session initialization protocol communication in this application; Figure 6 This is a schematic diagram of the module structure of the device for establishing session initiation protocol communication according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the method for establishing session initiation protocol communication in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] This application obtains elliptic curve parameters, generators, and hash functions, and generates a server private key and a server public key based on the elliptic curve parameters and generators; receives a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assigns a salt value to the user identifier, and generates a verification credential based on the user public key, the server private key, the salt value, and the hash function; receives an authentication request sent by the user terminal when a session is established, the authentication request carrying a user-side temporary public key and a user-side signature, verifies the legality of the user-side signature based on the user public key, generates a server-side temporary public key after successful verification, and generates a session key based on the user-side temporary public key, the server private key, and the hash function; returns an authentication response to the user terminal, receives a confirmation message returned by the user terminal, verifies the legality of the confirmation message, and establishes an encrypted session based on the session key after successful verification, the authentication response carrying the server-side temporary public key and the server-side signature.

[0024] The existing authentication scheme of the Session Initiation Protocol (SIP) is vulnerable to security attacks such as offline password guessing, resulting in security risks in SIP communication. Therefore, improving the security of SIP communication remains an issue that needs to be addressed.

[0025] This application generates verification credentials using the user's public key and the server's private key during the registration phase to achieve passwordless storage on the server. During the authentication phase, it verifies the user's identity based on elliptic curve signature and negotiates a dynamic session key, thereby effectively ensuring the legitimacy of two-way identity and improving the security of the initial protocol communication in the session.

[0026] All user-related data involved in this application were obtained with the user's permission or consent; that is, when this application is applied to specific products or technologies, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0027] Based on this, embodiments of this application provide a method for establishing session initiation protocol communication, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for establishing session initialization protocol communication according to this application.

[0028] In this embodiment, the method for establishing the session initiation protocol communication includes steps S10 to S40: Step S10: Obtain the elliptic curve parameters, generators, and hash function, and generate a server private key and a server public key based on the elliptic curve parameters and the generators; It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or session initiation protocol server capable of performing the above functions. The following description uses a session initiation protocol server as an example to illustrate this embodiment and the subsequent embodiments.

[0029] It should be noted that this application employs Elliptic Curve Cryptography (ECC) to implement the core encryption operations during session initiation protocol communication. ECC is a public-key cryptosystem based on the Elliptic Curve Discrete Logarithm Problem (ECDLP). Compared to traditional RSA (Rivest-Shamir-Adleman) or the Diffie-Hellman algorithm based on finite field discrete logarithms, ECC requires a shorter key length, less computation, faster processing speed, and lower storage and communication bandwidth requirements while maintaining the same security strength. Therefore, ECC is particularly suitable for terminal devices with limited computing power and power constraints, such as mobile phones, IP phones, and IoT devices, and can meet the application requirements of lightweight and low-latency SIP protocols.

[0030] It should be noted that elliptic curve parameters are the set of mathematical constants required for a specific elliptic curve, including the prime modulus p of the finite field, and the coefficients a and b of the curve equation. A generator is a selected public base point on the elliptic curve, usually denoted by the letter G. The generator G is used to convert a private key into a public key. A hash function is a one-way function that maps input data of arbitrary length to a fixed-length output (called a hash value or digest), possessing collision resistance and irreversibility. In this embodiment, a Secure Hash Algorithm 256-bit (SHA-256) can be used, with an output length of 256 bits (32 bytes), which can be used to derive keys and generate authentication messages.

[0031] Specifically, the SIP server performs system initialization operations, which allows it to obtain the elliptic curve parameters (p, a, b), the generator G, and the hash function SHA-256. The server also generates a random number as its private key sk_S, with a value ranging from [1, q-1], where q is the order of the generator G. Then, the server performs an elliptic curve multiplication operation between the private key sk_S and the generator G: pk_S = sk_S·G Obtain the server's public key pk_S. The dot product operation means adding the generator G consecutively by sk_S times; the result is still a point on the elliptic curve. The server's private key sk_S is stored securely by the server, while the server's public key pk_S is a public parameter that can be broadcast to all user terminals or published in the system parameters.

[0032] Next, the server initializes the user database, creating a data table to store user registration information, which includes at least the following fields: user identifier (U_ID), user public key (pk_U), server salt (s), and verification credential (V_S). The database is empty after initialization and will be filled in during subsequent registrations.

[0033] Finally, the server broadcasts publicly available system parameters to all SIP user agents (UAs) across the network, including elliptic curve parameters, generator G, hash function identifier, and server public key pk_S, so that user agents can use them during registration and authentication.

[0034] Step S20: Receive a registration request sent by a user terminal. The registration request carries a user identifier and a user public key. Assign a salt value to the user identifier and generate a verification credential based on the user public key, the server private key, the salt value, and the hash function. It should be noted that this can be used as a reference. Figure 2 , Figure 2 This is a diagram illustrating the user registration process. Figure 2The user terminal inputs a user identifier and password, generates a temporary user salt, a derived key, and a user key pair, and sends a registration request carrying the user identifier, user public key, and user temporary salt. The server registration module then verifies the uniqueness of the user identifier, generates a server salt and verification credentials, stores the user identifier, user public key, server salt, and verification credentials, and returns a confirmation response carrying the server salt. Finally, the user terminal stores the server salt and deletes the temporary user salt, thus completing the registration.

[0035] It should be noted that the user identifier refers to the identity information used to uniquely identify the user terminal. The user public key, on the other hand, is a public key generated by the user terminal, calculated by multiplying the user's private key sk_U by the generator G, i.e.: pk_U = sk_U·G The user's private key is stored locally on the user's terminal and is not sent to the server.

[0036] A salt is a randomly generated, unpredictable string of bytes used to enhance the randomness of password derivations. In this embodiment, the salt is generated by a cryptographically secure pseudo-random number generator (CSPRNG), and each user has a unique server salt s. The purpose of the salt is to ensure that even if two users set the same password, their password derivations will be different.

[0037] Verification credentials refer to the hash values ​​stored on the server that are used for auxiliary authentication.

[0038] Specifically, the user terminal first generates a private key sk_U (a random number) and a public key pk_U locally. Next, the user terminal sends a registration request (REGISTER request) to the SIP server. The request header includes the user identifier U_ID and the public key pk_U. Upon receiving the registration request, the SIP server extracts the user identifier U_ID and the public key pk_U from the request. The server first checks if U_ID has already been registered; if so, it returns a registration failure response. If not, the server assigns a unique server salt s to the user identifier. The salt can be generated using a cryptographically secure random number generator, with a length of 16 bytes (128 bits) to ensure unpredictability.

[0039] The server generates a verification credential V_S based on the user's public key pk_U, the server's private key sk_S, the salt s, and the SHA-256 hash function. The server stores the user identifier U_ID, the user's public key pk_U, the salt s, and the verification credential V_S in its local database. The server does not store the user's password, nor does it store any verifier that can be used to reverse-engineer the password, thus fundamentally reducing the security risks associated with database leaks. Finally, the server returns a registration success response to the user terminal, which includes the server's salt s (optional, for local storage by the user). After receiving and storing the server's salt s, the user terminal deletes the temporary salt generated during registration, completing the registration process.

[0040] In one feasible approach, the step of generating a verification credential based on the user's public key, the server's private key, the salt value, and the hash function includes: concatenating the user's public key, the server's private key, and the salt value in sequence into a first byte string; and performing hash processing on the first byte string using the hash function to obtain the verification credential.

[0041] It should be noted that, specifically, the server concatenates pk_U, sk_S, and s into a single byte string in sequence, then inputs this byte string into the SHA-256 hash function. The resulting hash value is the verification credential V_S. The calculation formula is: V_S = H(pk_U∥sk_S∥s) Here, ∥ represents byte string concatenation. The verification credentials do not contain the user's password, nor can the password be derived from them; therefore, even if the database is compromised, attackers cannot impersonate users using the verification credentials.

[0042] Step S30: When a session is established, receive an authentication request sent by the user terminal. The authentication request carries a user-side temporary public key and a user-side signature. Verify the legality of the user-side signature based on the user public key. If the verification is successful, generate a server-side temporary public key. Generate a session key based on the user-side temporary public key, the server private key, and the hash function. It should be noted that this can be used as a reference. Figure 3 , Figure 3 This is a diagram illustrating the session authentication and key negotiation process. Figure 3In the process, the user terminal generates a user-side random number, a user-side temporary public key, a user-side authentication message, and a user-side signature; and sends an authentication request. The server authentication module queries the database based on the user identifier to obtain the user's public key, salt value, and verification credentials; it recalculates the user-side authentication message and verifies the validity of the user-side signature. Upon successful verification, it generates a server-side random number, a server-side temporary public key, a session key, a server-side authentication message, and a server-side signature. It then returns an authentication response carrying the server-side temporary public key and server-side signature. The user terminal then calculates the session key, verifies the server-side signature, generates a confirmation message, and sends the confirmation message. Finally, the server authentication module verifies the validity of the confirmation message. Upon successful verification, it establishes an encrypted session based on the session key, thus completing the encrypted session establishment.

[0043] It should be noted that the user-side temporary public key refers to the public key of a key pair temporarily generated by the user terminal for each session. The user-side signature is the result of the user terminal signing the authentication message using its own user private key sk_U, used to prove that the authentication request was indeed initiated by a legitimate user and that the message content has not been tampered with. The server-side temporary public key is the public key of a key pair temporarily generated by the server for each session. The temporary public key is used to negotiate the session key. The session key is the temporary key used for symmetric encrypted communication during this session.

[0044] Specifically, when a user needs to establish a SIP session, the user terminal generates a random number r1 (within the range [1, q-1]) and uses the random number r1 and the generator G to calculate the user-side temporary public key R1: R1 = r1·G The user terminal uses locally stored information such as the user's private key sk_U, the server's salt value s, and the server's public key pk_S to construct an authentication message M1 according to a predetermined format: M1 = H(U_ID∥R1∥pk_S∥s) Then calculate the user-side signature σ1: σ1 = sk_U·M1 The user terminal sends an authentication request to the server, with the message header of the authentication request including the user's temporary public key R1 and user signature σ1. Upon receiving the authentication request, the SIP server extracts the user's temporary public key R1 and user signature σ1 from the request. The server then queries the database for the user's public key pk_U and salt value s based on the user identifier U_ID. If the information is not found, the server returns an authentication failure message.

[0045] The server verifies the validity of the user's signature σ1 based on the user's public key pk_U. If the verification fails, the server returns a 401 Unauthorized response and terminates the authentication; if the verification succeeds, the user's identity is confirmed as legitimate. After successful verification, the server generates a random number r2 (server-side random number) and calculates the server-side temporary public key R2 = r2·G. The server generates a session key K based on the user's temporary public key R1, the server's private key sk_S, and the hash function SHA-256. This session key K is used for encrypted communication in this session.

[0046] In one feasible approach, the step of verifying the legality of the user-side signature based on the user's public key includes: hashing the user identifier, the user-side temporary public key, the server public key, and the salt value using the hash function to obtain a user-side authentication message; determining whether the dot product of the user-side signature and the generator is equal to the dot product of the user's public key and the user-side authentication message; if they are equal, the user-side signature is legal.

[0047] It should be noted that the server extracts the user identifier U_ID and the user-side temporary public key R1 from the authentication request. The server queries the user's salt value s from the local database and obtains the server public key pk_S from the system's public parameters. The server concatenates these four pieces of data in sequence: the byte string of U_ID, the byte representation of R1, the byte representation of pk_S, and the byte string of s. The concatenated result is input into the SHA-256 hash function, and the calculated 32-byte hash value is denoted as the user-side authentication message M1. This M1 should be completely consistent with the M1 calculated by the user terminal when initiating the authentication request; otherwise, it indicates that the message has been tampered with during transmission. The verification formula is: σ1·G = pk_U·M1 Where σ1 is the user-side signature, G is the generator, pk_U is the user's public key, and M1 is the user-side authentication message. The server calculates the left-hand side value L = σ1·G, which is an elliptic curve product of the user-side signature σ1 and the generator G, resulting in an elliptic curve point. The server calculates the right-hand side value R = pk_U·M1, which is an elliptic curve product of the user's public key pk_U and the user-side authentication message M1, also resulting in an elliptic curve point. The server checks whether L equals R. If they are equal, it proves that σ1 = sk_U·M1 is true, that is, the user-side signature was indeed signed by a legitimate user holding the user's private key sk_U. The verification principle is as follows: σ1 = sk_U·M1 L = (sk_U·M1)·G = M1·(sk_U·G) = M1·pk_U = R If the equation is not true, the signature is invalid, and the server returns an authentication failure response.

[0048] In one feasible approach, the step of generating a session key based on the user-side temporary public key, the server private key, and the hash function includes: performing a dot product operation on the user-side temporary public key and the server private key to obtain a first shared secret; performing a dot product operation on the server-side random number and the user public key to obtain a second shared secret; concatenating the first shared secret, the second shared secret, the user-side temporary public key, and the server-side temporary public key in sequence into a second byte string, and hashing the second byte string using the hash function to obtain the session key.

[0049] It should be noted that the server calculates the first shared secret S1 by multiplying its own private key sk_S by the user's temporary public key R1: S1 = sk_S·R1 This operation is a dot product on an elliptic curve, and the result S1 is a point on the elliptic curve. Since R1 = r1·G According to the commutative law of scalar multiplication for elliptic curves, we can obtain: S1 = sk_S·(r1·G) = r1·(sk_S·G) = r1·pk_S Therefore, S1 depends on both the server's private key sk_S and the user's random number r1. The server multiplies its own generated server-side random number r2 by the user's public key pk_U to calculate the second shared secret S2 = r2·pk_U. As a result, S2 is a point on the elliptic curve. Because: pk_U = sk_U·G S2 = r2·(sk_U·G) = sk_U·(r2·G) = sk_U·R2 Therefore, S2 depends on both the user terminal's private key sk_U and the server's random number r2.

[0050] The server concatenates the first shared secret S1, the second shared secret S2, the user-side temporary public key R1, and the server-side temporary public key R2 into a single byte string, called the second byte string. This second byte string is then input into the SHA-256 hash function, and the resulting hash value is the session key K. The user terminal can calculate the same K in a corresponding manner; that is, the user terminal also calculates S1 and S2, then concatenates the four values ​​in the same order and hashes them. Since both parties can independently calculate S1 and S2, they can obtain the same session key K. This session key is different for each session and has perfect forward security.

[0051] Step S40: Return an authentication response to the user terminal, receive the confirmation message returned by the user terminal, verify the legality of the confirmation message, and establish an encrypted session based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

[0052] It should be noted that the server-side signature is the result of the server signing the server-side authentication message M2 using its own private key sk_S. This signature is used to prove the server's legitimate identity to the user terminal, preventing server impersonation attacks and man-in-the-middle attacks. The confirmation message is an acknowledgment message sent by the user terminal to the server after verifying the server's successful signature, informing the server that the user terminal has successfully calculated the same session key K. The encrypted session is a secure communication channel between the server and the user terminal after mutual authentication and key negotiation, using the session key K to perform symmetric encryption for subsequent SIP signaling and media stream transmission.

[0053] Specifically, after generating the session key K and the server-side temporary public key R2, the server generates a server-side signature σ2. The server returns an authentication response (401 Unauthorized response) to the user terminal, which includes the server-side temporary public key R2 and the server-side signature σ2 in its header. Upon receiving the authentication response, the user terminal verifies the validity of the server-side signature σ2 using the server's public key pk_S and calculates the session key K using the same algorithm as the server. K = H(r1·pk_S∥r2·pk_U∥R1∥R2) User terminal calculates confirmation message M3: M3 = H(K∥R1∥R2) And return M3 to the server via a confirmation request.

[0054] The SIP server receives the acknowledgment message M3 from the user terminal and verifies its validity. Upon successful verification, the server confirms that the user terminal has successfully calculated the same session key K, and both parties have completed mutual authentication and key negotiation. The server establishes an encrypted session based on the session key K, and all subsequent SIP signaling and media streams between the server and the user terminal are symmetrically encrypted using the session key K, thereby ensuring the confidentiality and integrity of the communication content.

[0055] In one feasible approach, before the step of returning an authentication response to the user terminal, the method further includes: concatenating the session key, the server-side temporary public key, the verification credential, and the user identifier into a third byte string in sequence; hashing the third byte string using the hash function to obtain a server-side authentication message; and multiplying the server private key with the server-side authentication message to obtain a server-side signature.

[0056] It should be noted that the server concatenates the calculated session key K, the server-side temporary public key R2, the verification credential V_S read from the database, and the user identifier U_ID into a single byte string, called the third byte string. This third byte string is then input into a SHA-256 hash function, and the resulting hash value serves as the server-side authentication message M2. M2 binds the session key, temporary public key, verification credential, and user identity; any tampering with any of these will change M2, which will be detected by the user terminal. The server then multiplies its private key sk_S with the server-side authentication message M2, i.e.: σ² = sk_S × M² Here, σ2 represents the server-side signature. Due to the difficulty of the elliptic curve discrete logarithm problem, only the entity holding the server's private key sk_S can generate the correct σ2. The server includes σ2 and R2 in the authentication response and returns it to the user terminal. Upon receiving it, the user terminal can use the server's public key pk_S to verify whether σ2·G is equal to pk_S·M2, thereby confirming the server's identity.

[0057] In one feasible approach, the step of verifying the legitimacy of the confirmation message includes: concatenating the session key, the user-side temporary public key, and the server-side temporary public key in sequence into a fourth byte string; hashing the fourth byte string using the hash function to obtain a confirmation digest; and determining whether the confirmation message is equal to the confirmation digest. If they are equal, the confirmation message is considered legitimate.

[0058] It should be noted that the server uses the negotiated session key K, the user-side temporary public key R1 received from the authentication request, and its own generated server-side temporary public key R2, concatenating these three into a single byte string, called the fourth byte string. The server then inputs this fourth byte string into a SHA-256 hash function to calculate the hash value, which serves as the acknowledgment digest M3_calc. Furthermore, the user terminal also calculates this before sending the acknowledgment message: M3 = H(K∥R1∥R2) The server then sends M3 as an acknowledgment message to the user terminal. The server compares the received acknowledgment message (M3 sent by the user terminal) with the locally calculated acknowledgment digest M3_calc. If they are equal, it proves that the user terminal has successfully calculated the same session key K, and the acknowledgment message has not been tampered with during transmission; the server confirms that the two-way authentication is successful. If they are not equal, the server refuses to establish a session and returns an error response.

[0059] This embodiment obtains elliptic curve parameters, generators, and a hash function, and generates a server private key and a server public key based on the elliptic curve parameters and the generators; receives a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assigns a salt value to the user identifier, and generates a verification credential based on the user public key, the server private key, the salt value, and the hash function; receives an authentication request sent by the user terminal when a session is established, the authentication request carrying a user-side temporary public key and a user-side signature, verifies the legality of the user-side signature based on the user public key, generates a server-side temporary public key after successful verification, and generates a session key based on the user-side temporary public key, the server private key, and the hash function; returns an authentication response to the user terminal, receives a confirmation message returned by the user terminal, verifies the legality of the confirmation message, and establishes an encrypted session based on the session key after successful verification, the authentication response carrying the server-side temporary public key and the server-side signature. In this embodiment, during the registration phase, verification credentials are generated using the user's public key and the server's private key to achieve passwordless storage on the server. During the authentication phase, the user's identity is verified based on elliptic curve signature and a dynamic session key is negotiated, thereby effectively ensuring the legitimacy of two-way identity and improving the security of the initial protocol communication in the session.

[0060] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 After step S40, the method for establishing the session initialization protocol communication further includes steps S401 to S403: Step S401: Receive a password update request sent by the user terminal, the password update request carrying the new user public key and the update signature; It should be noted that when a user needs to change their password, the user terminal prompts the user to enter both the old and new passwords. The user terminal verifies the validity of the old password locally. After successful verification, the user terminal generates a new derived key x_new using a hash function based on the new password, the user identifier U_ID, and the server salt value s (the salt value stored locally during registration). This, in turn, generates a new user private key sk_U_new and a new user public key pk_U_new. pk_U_new = sk_U_new·G Where G is the generator. The user terminal signs the update information using the old user's private key sk_U, obtaining the update signature σ_update: σ_update = sk_U · H(U_ID∥pk_U_new∥s) The user terminal sends a new user public key pk_U_new and an update signature σ_update to the server via a password update request. The server receives the request and extracts the new user public key pk_U_new and the update signature σ_update from it. Step S402: Verify the legality of the updated signature based on the user's public key. If the verification is successful, update the current user's public key to the new user's public key. It should be noted that the server retrieves the user's current public key pk_U (old public key) and salt value s from the database based on the user identifier U_ID. Then, the server calculates the base hash M_update. M_update = H(U_ID∥pk_U_new∥s) The baseline hash is used to bind the new public key to the user's identity, preventing attackers from forging update requests.

[0061] Then, the server performs ECC signature verification, using the following formula: σ_update· G=pk_U·M_update Where σ_update is the update signature sent by the user terminal, G is the generator, pk_U is the user's current public key (old public key) stored on the server, and M_update is the base hash.

[0062] If the equation holds true, it proves that the update request was initiated by a legitimate user holding the old private key sk_U, and the server accepts the password update. The server updates the user's public key field in the database from the old value pk_U to the new value pk_U_new.

[0063] Step S403: Use the hash function to process the new user's public key, the server's private key, and the salt value to generate the current verification credential.

[0064] It's important to note that the server uses the SHA-256 hash function to hash the new user public key pk_U_new, its own server private key sk_S, and the unchanged salt value s to regenerate new authentication credentials. The server updates the authentication credentials in the database from the old value V_S to V_S_new and returns a successful update response to the user terminal. Upon receiving the response, the user terminal securely stores the new private key sk_U_new locally, deletes the old private key sk_U, and the password update process ends. Throughout the entire process, the server never accesses the user's new password or the plaintext of the old password.

[0065] For reference Figure 5 , Figure 5 This is a diagram illustrating the password update process. Figure 5The user terminal receives the old and new passwords and verifies the validity of the old password; it generates a new user private key and a new user public key based on the new password, and generates an update signature; then it sends a password update request. The server password update module then queries the database based on the user identifier to obtain the current user public key and salt value; it verifies the validity of the update signature based on the user public key; if verification is successful, it updates the current user public key to the new user public key; it regenerates the verification credential based on the new user public key, the server private key, and the salt value; and returns a success update response. Finally, the user terminal stores the new user private key, deletes the old user private key, and the password update is complete.

[0066] This embodiment receives a password update request sent by the user terminal. The password update request carries a new user public key and an update signature. Based on the user public key, the validity of the update signature is verified. If the verification is successful, the current user public key is updated to the new user public key. The hash function is used to process the new user public key, the server private key, and the salt value to generate the current verification credential. This embodiment verifies the update request by signing with the old private key, allowing for online password updates without re-registration and without transmitting plaintext passwords throughout the process, thus improving the security of password updates.

[0067] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method of establishing session initiation protocol communication in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0068] This application also provides a device for establishing session initiation protocol communication, please refer to... Figure 6 The device for establishing the session initiation protocol communication includes: The acquisition module 10 is used to acquire elliptic curve parameters, generators, and hash functions, and generate server private keys and server public keys based on the elliptic curve parameters and generators. The receiving module 20 is used to receive a registration request sent by a user terminal. The registration request carries a user identifier and a user public key. A salt value is assigned to the user identifier, and a verification credential is generated based on the user public key, the server private key, the salt value, and the hash function. The authentication module 30 is used to receive an authentication request sent by the user terminal when the session is established. The authentication request carries a user-side temporary public key and a user-side signature. The module verifies the legality of the user-side signature based on the user public key. After successful verification, the module generates a server-side temporary public key and generates a session key based on the user-side temporary public key, the server private key, and the hash function. The module 40 is used to return an authentication response to the user terminal, receive a confirmation message returned by the user terminal, verify the legality of the confirmation message, and establish an encrypted session based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

[0069] This application obtains elliptic curve parameters, generators, and hash functions, and generates a server private key and a server public key based on the elliptic curve parameters and generators; receives a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assigns a salt value to the user identifier, and generates a verification credential based on the user public key, the server private key, the salt value, and the hash function; receives an authentication request sent by the user terminal when a session is established, the authentication request carrying a user-side temporary public key and a user-side signature, verifies the legality of the user-side signature based on the user public key, generates a server-side temporary public key after successful verification, and generates a session key based on the user-side temporary public key, the server private key, and the hash function; returns an authentication response to the user terminal, receives a confirmation message returned by the user terminal, verifies the legality of the confirmation message, and establishes an encrypted session based on the session key after successful verification, the authentication response carrying the server-side temporary public key and the server-side signature. This application generates verification credentials using the user's public key and the server's private key during the registration phase to achieve passwordless storage on the server. During the authentication phase, it verifies the user's identity based on elliptic curve signature and negotiates a dynamic session key, thereby effectively ensuring the legitimacy of two-way identity and improving the security of the initial protocol communication in the session.

[0070] In one embodiment, the receiving module 20 is further configured to concatenate the user public key, the server private key, and the salt value in sequence into a first byte string; and use the hash function to perform hash processing on the first byte string to obtain the verification credential.

[0071] In one embodiment, the authentication module 30 is further configured to use the hash function to hash the user identifier, the user-side temporary public key, the server public key, and the salt value to obtain a user-side authentication message; and to determine whether the dot product of the user-side signature and the generator is equal to the dot product of the user public key and the user-side authentication message. If they are equal, the user-side signature is valid.

[0072] In one embodiment, the authentication module 30 is further configured to perform a dot product operation on the user-side temporary public key and the server-side private key to obtain a first shared secret; perform a dot product operation on the server-side random number and the user-side public key to obtain a second shared secret; concatenate the first shared secret, the second shared secret, the user-side temporary public key, and the server-side temporary public key in sequence into a second byte string, and perform hash processing on the second byte string using the hash function to obtain a session key.

[0073] In one embodiment, the establishment module 40 is further configured to concatenate the session key, the server-side temporary public key, the verification credential, and the user identifier into a third byte string in sequence, perform hash processing on the third byte string using the hash function to obtain a server-side authentication message, and perform a multiplication operation between the server private key and the server-side authentication message to obtain a server-side signature.

[0074] In one embodiment, the establishment module 40 is further configured to concatenate the session key, the user-side temporary public key, and the server-side temporary public key in sequence into a fourth byte string; perform hash processing on the fourth byte string using the hash function to obtain an acknowledgment digest; and determine whether the acknowledgment message is equal to the acknowledgment digest. If they are equal, the acknowledgment message is valid.

[0075] In one embodiment, the establishment module 40 is further configured to receive a password update request sent by the user terminal, the password update request carrying a new user public key and an update signature; verify the legality of the update signature based on the user public key, and update the current user public key to the new user public key after successful verification; and process the new user public key, the server private key, and the salt value using the hash function to generate the current verification credential.

[0076] The session initiation protocol communication establishment apparatus provided in this application, employing the session initiation protocol communication establishment method in the above embodiments, can solve the technical problem of how to improve the security of session initiation protocol communication. Compared with the prior art, the beneficial effects of the session initiation protocol communication establishment apparatus provided in this application are the same as those of the session initiation protocol communication establishment method provided in the above embodiments, and other technical features in the session initiation protocol communication establishment apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0077] This application provides a device for establishing session initiation protocol communication. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the session initiation protocol communication establishment method in the above embodiment 1.

[0078] The following is for reference. Figure 7 This document illustrates a structural diagram of a device suitable for establishing session initiation protocol communication in the embodiments of this application. The device for establishing session initiation protocol communication in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The device for establishing session initiation protocol communication shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0079] like Figure 7As shown, the device for establishing session initiation protocol communication may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the device for establishing session initiation protocol communication. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the session initiation protocol communication establishment device to exchange data wirelessly or via wired communication with other devices. Although session initiation protocol communication establishment devices with various systems are shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0080] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0081] The session initiation protocol communication establishment device provided in this application, employing the session initiation protocol communication establishment method in the above embodiments, can solve the technical problem of how to improve the security of session initiation protocol communication. Compared with the prior art, the beneficial effects of the session initiation protocol communication establishment device provided in this application are the same as those of the session initiation protocol communication establishment method provided in the above embodiments, and other technical features in this session initiation protocol communication establishment device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0082] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0083] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0084] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the session initiation protocol communication establishment method in the above embodiments.

[0085] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0086] The aforementioned computer-readable storage medium may be included in the device for establishing session initiation protocol communication; or it may exist independently and not be assembled into the device for establishing session initiation protocol communication.

[0087] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a session initiation protocol communication establishment device, cause the session initiation protocol communication establishment device to: acquire elliptic curve parameters, generators, and hash functions, and generate a server private key and a server public key based on the elliptic curve parameters and the generators; receive a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assign a salt value to the user identifier, and generate a verification credential based on the user public key, the server private key, the salt value, and the hash function; receive an authentication request sent by the user terminal during session establishment, the authentication request carrying a user-side temporary public key and a user-side signature, verify the legality of the user-side signature based on the user public key, generate a server-side temporary public key after successful verification, and generate a session key based on the user-side temporary public key, the server private key, and the hash function; return an authentication response to the user terminal, receive a confirmation message returned by the user terminal, verify the legality of the confirmation message, and establish an encrypted session based on the session key after successful verification, the authentication response carrying the server-side temporary public key and the server-side signature.

[0088] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0090] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0091] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for establishing session initiation protocol communication, thereby solving the technical problem of how to improve the security of session initiation protocol communication. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the session initiation protocol communication establishment method provided in the above embodiments, and will not be repeated here.

[0092] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the session initiation protocol communication establishment method as described above.

[0093] The computer program product provided in this application solves the technical problem of how to improve the security of session initiation protocol communication. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the session initiation protocol communication establishment method provided in the above embodiments, and will not be repeated here.

[0094] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for establishing session initiation protocol communication, characterized in that, The method includes: Obtain the elliptic curve parameters, generators, and hash function, and generate a server private key and a server public key based on the elliptic curve parameters and the generators; The system receives a registration request sent by a user terminal, the registration request carrying a user identifier and a user public key, assigns a salt value to the user identifier, and generates a verification credential based on the user public key, the server private key, the salt value, and the hash function. When a session is established, an authentication request sent by the user terminal is received. The authentication request carries a user-side temporary public key and a user-side signature. The validity of the user-side signature is verified based on the user-side public key. If the verification is successful, a server-side temporary public key is generated. A session key is generated based on the user-side temporary public key, the server private key, and the hash function. An authentication response is returned to the user terminal, a confirmation message is received from the user terminal, the validity of the confirmation message is verified, and an encrypted session is established based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

2. The method as described in claim 1, characterized in that, The step of generating verification credentials based on the user's public key, the server's private key, the salt value, and the hash function includes: Concatenate the user's public key, the server's private key, and the salt value into a first byte string in sequence; The first byte string is hashed using the hash function to obtain the verification credential.

3. The method as described in claim 1, characterized in that, The step of verifying the legality of the user-side signature based on the user's public key includes: The user identifier, the user-side temporary public key, the server public key, and the salt value are hashed using the hash function to obtain the user-side authentication message; Determine whether the dot product of the user-side signature and the generator is equal to the dot product of the user's public key and the user-side authentication message. If they are equal, the user-side signature is valid.

4. The method as described in claim 1, characterized in that, The step of generating a session key based on the user-side temporary public key, the server private key, and the hash function includes: The first shared secret is obtained by performing a dot product operation between the user-side temporary public key and the server private key; The second shared secret is obtained by multiplying the server-side random number with the user's public key. The first shared secret, the second shared secret, the user-side temporary public key, and the server-side temporary public key are concatenated in sequence into a second byte string. The second byte string is then hashed using the hash function to obtain the session key.

5. The method as described in claim 1, characterized in that, Before the step of returning an authentication response to the user terminal, the method further includes: The session key, the server-side temporary public key, the verification credential, and the user identifier are concatenated in sequence into a third byte string. The hash function is then used to hash the third byte string to obtain the server-side authentication message. The server's private key is multiplied by the server-side authentication message to obtain the server-side signature.

6. The method as described in claim 1, characterized in that, The steps for verifying the validity of the confirmation message include: The session key, the user-side temporary public key, and the server-side temporary public key are concatenated in sequence into a fourth byte string; The fourth byte string is hashed using the hash function to obtain an acknowledgment digest. Determine whether the confirmation message is equal to the confirmation digest; if they are equal, the confirmation message is valid.

7. The method as described in claim 1, characterized in that, Following the step of establishing an encrypted session based on the session key, the method further includes: Receive a password update request sent by the user terminal, the password update request carrying a new user public key and an update signature; The validity of the updated signature is verified based on the user's public key. If the verification is successful, the current user's public key is updated to the new user's public key. The hash function is used to process the new user's public key, the server's private key, and the salt value to generate the current verification credential.

8. A device for establishing session initiation protocol communication, characterized in that, The device includes: The acquisition module is used to acquire elliptic curve parameters, generators, and hash functions, and generate server private keys and server public keys based on the elliptic curve parameters and generators. The receiving module is used to receive a registration request sent by a user terminal. The registration request carries a user identifier and a user public key. A salt value is assigned to the user identifier, and a verification credential is generated based on the user public key, the server private key, the salt value, and the hash function. The authentication module is used to receive an authentication request sent by the user terminal when the session is established. The authentication request carries a user-side temporary public key and a user-side signature. The module verifies the legality of the user-side signature based on the user-side public key. After successful verification, it generates a server-side temporary public key and generates a session key based on the user-side temporary public key, the server private key, and the hash function. The module is configured to return an authentication response to the user terminal, receive a confirmation message returned by the user terminal, verify the legality of the confirmation message, and establish an encrypted session based on the session key after successful verification. The authentication response carries the server-side temporary public key and the server-side signature.

9. A device for establishing session initiation protocol communication, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for establishing session initiation protocol communication as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the method for establishing session initiation protocol communication as described in any one of claims 1 to 7.

Images