Authentication method, device, electronic device and readable storage medium

Abstract

The present invention provides an identity authentication method, device, electronic device and readable storage medium, which can provide end-to-end transmission capability based on the RTP protocol, and utilize the extended part of the RTP message header to directly realize end-to-end transmission of identity signature information and confirmation mark after identity authentication between the first terminal and the second terminal through the RTP message, thereby improving the stability and efficiency of identity authentication between terminals, and can realize direct trust between terminals, thereby improving the reliability and accuracy of identity authentication.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communication technology, and in particular to an identity authentication method, device, electronic device and readable storage medium. Background Art

[0002] Voice over Internet Protocol (VoIP) is a voice call technology based on Internet Protocol (IP), hereinafter referred to as VoIP system. VoIP system achieves voice calls and multimedia conferences via the Internet. However, compared with traditional telephone network systems, the authenticity of the caller number in VoIP system is usually difficult to guarantee.

[0003] In the prior art, the authentication server and verification server of the STIR framework are usually used to implement the authentication and verification of the caller identity. However, within a communication domain, if an authentication server fails, all outgoing calls within the communication domain cannot continue; similarly, within a communication domain, if a verification server fails, all incoming calls within the communication domain cannot continue.

[0004] It can be seen that the identity authentication system in the prior art relies on the authentication server and the verification server, and the system has poor fault tolerance and stability. Summary of the invention

[0005] The purpose of the embodiments of the present invention is to provide an identity authentication method, device, electronic device and readable storage medium, which solve the problem of poor fault tolerance and stability of existing identity authentication systems.

[0006] In order to solve the above problem, in a first aspect, an embodiment of the present invention provides an identity authentication method, which is applied to a first terminal and includes:

[0007] receiving a first real-time transport protocol message sent by a second terminal, wherein the first real-time transport protocol RTP message carries identity signature information of the second terminal;

[0008] Performing identity authentication on the second terminal according to the first RTP message;

[0009] A second RTP message is sent to the second terminal, where the second RTP message carries a confirmation identifier, and the confirmation identifier is used to indicate whether the identity authentication of the second terminal is passed.

[0010] In a second aspect, an embodiment of the present invention provides an identity authentication method, applied to a second terminal, including:

[0011] Sending a first real-time transport protocol RTP message to the first terminal, where the first RTP message carries the identity signature information of the second terminal;

[0012] A second RTP message sent by the first terminal is received, where the second RTP message carries a confirmation identifier, and the confirmation identifier is used to indicate whether the identity authentication of the second terminal is passed.

[0013] In a third aspect, an embodiment of the present invention provides an identity authentication device, including:

[0014] A first receiving module, configured to receive a first real-time transport protocol RTP message sent by a second terminal, wherein the first RTP message carries identity signature information of the second terminal;

[0015] A first processing module, configured to authenticate the second terminal according to the first RTP message;

[0016] The first sending module is used to send a second RTP message to the second terminal, where the second RTP message carries a confirmation mark, and the confirmation mark is used to indicate whether the identity authentication of the second terminal is passed.

[0017] In a fourth aspect, an embodiment of the present invention provides an identity authentication device, including:

[0018] A second sending module, configured to send a first real-time transport protocol RTP message to the first terminal, wherein the first RTP message carries the identity signature information of the second terminal;

[0019] The second receiving module is used to receive a second RTP message sent by the first terminal, where the second RTP message carries a confirmation mark, and the confirmation mark is used to indicate whether the identity authentication of the second terminal is passed.

[0020] In a fifth aspect, an embodiment of the present invention provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the identity authentication method as described above when executed by the processor.

[0021] In a sixth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the identity authentication method as described above are implemented.

[0022] One of the above technical solutions has the following advantages or beneficial effects:

[0023] The identity authentication method, device, electronic device and readable storage medium provided by the embodiment of the present invention can provide end-to-end transmission capability based on the RTP protocol, and can directly realize end-to-end transmission of identity signature information and confirmation mark after identity authentication through RTP messages between the first terminal and the second terminal by using the extended part of the RTP message header, thereby improving the stability and efficiency of identity authentication between terminals, and can realize direct trust between terminals, thereby improving the reliability and accuracy of identity authentication. In addition, no modification of the existing network is required. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a structural diagram of a network system to which an embodiment of the present invention can be applied;

[0025] Figure 2 It is a flow chart of SIP session connection in VoIP system;

[0026] Figure 3 It is a flowchart of the identity verification method based on the STIR / SHAKEN architecture;

[0027] Figure 4 It is a flowchart of the identity authentication method based on the SIP protocol;

[0028] Figure 5 This is one of the flowcharts of the identity authentication method provided by the embodiment of the present invention;

[0029] Figure 6 It is a schematic diagram of the process of performing a SIP session connection in a VoIP system provided by an embodiment of the present invention;

[0030] Figure 7 It is one of the specific message formats of an RTP message provided by an embodiment of the present invention;

[0031] Figure 8 This is the second specific message format of an RTP message provided by an embodiment of the present invention;

[0032] Fig. 9 This is a specific message format of an RTP message provided by an embodiment of the present invention;

[0033] Fig.10 This is a second flow chart of the identity authentication method provided by an embodiment of the present invention;

[0034] Fig.11 It is one of the structural diagrams of the identity authentication device provided by the embodiment of the present invention;

[0035] Fig.12 This is the second structural diagram of the identity authentication device provided by the embodiment of the present invention;

[0036] Fig.13 A structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] The terms "first", "second" etc. in the present application are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. In addition, the terms "include" and "have" and any of their variations are intended to cover non-exclusive inclusions, for example, the process, method, system, product or equipment comprising a series of steps or units need not be limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment. In addition, "and / or" is used in the present application to represent at least one of the connected objects, such as A and / or B and / or C, indicating that A alone, B alone, C alone, and A and B all exist, B and C all exist, A and C all exist, and 7 situations in which A, B and C all exist.

[0039] In the embodiments of the present invention, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present invention should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0040] See also Figure 1 , Figure 1 1 is a structural diagram of a network system to which the embodiment of the present invention can be applied. Figure 1 As shown, a first terminal 11 and a second terminal 12 are included, and the first terminal 11 and the second terminal 12 can communicate with each other.

[0041] In the embodiment of the present invention, the terminal may also be referred to as a terminal device or a user terminal (User Equipment, UE). In practical applications, the first terminal 11 and the second terminal 12 may be a mobile phone, a tablet computer (Tablet Personal Computer), a laptop computer (Laptop Computer) or a notebook computer, a personal digital assistant (Personal Digital Assistant, PDA), a handheld computer, a netbook, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a mobile Internet device (Mobile Internet Device, MID), a wearable device (Wearable Device) or a vehicle-mounted device (VUE), a pedestrian terminal (PUE), etc., and the wearable device includes: a bracelet, a headset, glasses, etc. The specific details can be determined according to the actual situation, and the embodiment of the present invention does not limit this.

[0042] For ease of understanding, some contents involved in the embodiments of the present invention are described below:

[0043] 1. VOIP system

[0044] The basic principle of the VoIP system is to compress the voice data encoding through the voice compression algorithm, then package the voice data according to the TCP / IP standard, send the data packets to the receiving place through the IP network, and then string these voice data packets together. After decompression, they are restored to the original voice signal, thereby achieving the purpose of transmitting voice over the Internet.

[0045] See also Figure 2 , Figure 2 It is a flowchart of the main protocols of VoIP, such as Figure 2 As shown:

[0046] The VOIP protocol mainly includes two parts: 1) Session Initiation Protocol (SIP), hereinafter referred to as SIP protocol, which is mainly used for the establishment and release of SIP sessions; 2) Real-time Transport Protocol (RTP), hereinafter referred to as RTP protocol, which is mainly used for the transmission of real-time streaming media information.

[0047] like Figure 2 As shown, terminal A is a calling user terminal, and terminal B is a called user terminal.

[0048] 1) A network voice session is established between terminal A and terminal B based on the SIP protocol.

[0049] Terminal A sends an invitation message (SIP message) to terminal B to establish a network call connection with terminal B. Since the SIP protocol cannot achieve end-to-end transmission capability, the invitation message needs to be forwarded by one or more proxy servers before reaching terminal B.

[0050] After receiving the invitation message, terminal B may return an invitation confirmation message (OK message) if it agrees with the invitation information. The invitation confirmation message also needs to be forwarded by one or more proxy servers before it can reach terminal A.

[0051] Based on the double confirmation mechanism, after receiving the invitation confirmation information, terminal A returns a reception confirmation message (such as an Acknowledge character (ACK)) to terminal B to inform terminal B that the invitation confirmation message sent by it has been received correctly. The reception confirmation message also needs to be forwarded by one or more proxy servers before it can reach terminal B. After terminal B receives the confirmation character, the network voice session between terminal A and terminal B is successfully established.

[0052] 2) Streaming media information is transmitted between terminal A and terminal B based on the RTP protocol.

[0053] The RTP protocol provides end-to-end transmission capabilities for streaming media information. After the SIP session between terminal A and terminal B is successfully established, terminal A can obtain the IP address of terminal B and then transmit streaming media information through RTP messages to achieve real-time SIP session connection.

[0054] As can be seen from the above, the VoIP system itself does not have the ability to authenticate the identity of the calling user. Therefore, compared with the traditional telephone network system, the authenticity of the calling user's identity is difficult to guarantee in the VoIP system. Attackers can make false calls by forging the calling number, causing phenomena such as voice spam calls, fraudulent calls, phishing, voicemail attacks, etc. that seriously affect the economy and society. In the prior art, some operators maintain blacklists to prevent calls initiated by calling numbers on the blacklist from arriving, but the blacklist needs to be updated in a timely manner and is not suitable for calls using random false numbers; some operators verify the calling number based on Secure Telephone Identity Revisited (STIR) / Securely Handled Assertion Information Using toKENs (SHAKEN) (hereinafter referred to as the STIR / SHAKEN architecture).

[0055] 2. STIR / SHAKEN Architecture

[0056] The STIR / SHAKEN structure defines a security mechanism to verify the identity of the originator of a SIP INVITE message. Figure 3 , Figure 3 This is a flowchart of STIR / SHAKEN verifying the identity of the initiator.

[0057] like Figure 3 As shown in the figure, terminal A is the calling user terminal, and terminal B is the called user terminal:

[0058] 1) Terminal A sends an invitation message (SIP message) to the authentication server.

[0059] 2) The authentication server signs the DATA field, FROM field, and TO field in the message header of the invitation message to generate identity signature information, and then puts the identity signature information and the address indicating the authentication server certificate into the IDENITY field of the message header of the invitation message. Among them, the FROM field includes the identity of terminal A (the SIP Uniform Resource Identifier (URI) of terminal A or the telephone number of terminal A); the TO field includes the identity of terminal B (the SIP Uniform Resource Identifier (URI) of terminal B or the telephone number of terminal B); the DATA field includes the timestamp of sending the invitation message.

[0060] 3) The authentication server sends the invitation message carrying the identity signature information to the verification server.

[0061] 4) The verification server links to the Public Key Infrastructure (PKI) according to the address of the authentication server certificate to obtain the authentication server certificate.

[0062] 5) The verification server verifies the identity signature information based on the public key in the authentication server certificate. After successful verification, the verification server sends an invitation message to terminal B.

[0063] From the above, we can see that the STIR / SHAKEN architecture relies on the authentication server and the verification server. All call invitation messages need to be signed by the authentication server, and the signature is verified by the verification server. In this way, within a communication domain, once the authentication server goes down, all outgoing calls within the domain cannot be made; similarly, within a communication domain, once the verification server goes down, all incoming calls within the domain cannot be made, and the system fault tolerance and stability are poor.

[0064] In addition, the STIR / SHAKEN architecture still has trust issues that need to be resolved. On the one hand, both terminal A and terminal B need to trust the authentication server, verification server, and PKI, but direct trust between terminal A and terminal B cannot be achieved; on the other hand, the STIR / SHAKEN architecture involves digital certificates to implement identity authentication. Considering the management of certificates and the requirements of different security levels, in actual applications, multiple electronic certification authorities (CAs) are usually required to ensure the normal operation of the digital certificate mechanism, which will involve the mutual trust issue between multiple CAs.

[0065] 3. Authentication method based on SIP protocol

[0066] An identity authentication method based on the SIP protocol that transmits identity signature information and signature verification information through the IDENITY field of the SIP INVITE message. Figure 4 , Figure 4 The figure is a flowchart of the identity authentication method based on the SIP protocol.

[0067] like Figure 4 As shown in the figure, terminal A is the calling user terminal, and terminal B is the called user terminal:

[0068] 1) Terminal A uses its own private key to sign the DATA field, FROM field, and TO field in the invitation message header, and writes the generated identity signature information into the IDENITY field of the invitation message. After that, the invitation message carrying the identity signature information is sent to terminal B. Since the SIP protocol cannot achieve end-to-end transmission capabilities, the invitation message needs to be transferred through one or more proxy servers before it can reach terminal B.

[0069] After receiving the invitation message, terminal B can perform identity authentication according to the identity signature information in the invitation message, and then return an invitation confirmation message, which carries signature verification information to indicate whether the identity authentication is successful. The invitation confirmation message also needs to be forwarded by one or more proxy servers before it can reach terminal A.

[0070] Based on the double confirmation mechanism, after receiving the invitation confirmation information, if the terminal A determines that the identity authentication is passed, it can return a reception confirmation message (such as an ACK confirmation character) to the terminal B to inform the terminal B that the invitation confirmation message sent by it has been received correctly. The reception confirmation message also needs to be forwarded by one or more proxy servers before it can reach the terminal B. After the terminal B receives the confirmation character, the network voice session between the terminal A and the terminal B is successfully established.

[0071] 2) Streaming media information is transmitted between terminal A and terminal B based on the RTP protocol.

[0072] As can be seen from the above, in the identity authentication method based on the SIP protocol, since the SIP invitation message needs to be routed through one or more proxy servers, if the identity signature information is written into the SIP invitation message, each proxy server needs to be adaptively adjusted and upgraded to realize the sending, receiving and parsing of the SIP invitation message carrying the identity signature message. This requires a lot of work and it is difficult to solve the compatibility problem of all proxy servers.

[0073] In addition, the identity authentication method based on the SIP protocol also has a trust problem, that is, both terminal A and terminal B need to trust each proxy server, but direct trust between terminal A and terminal B cannot be achieved.

[0074] 4. Digital Certificate

[0075] A digital certificate is a digital certificate that marks the identity information of the parties in Internet communication. People can use it to identify each other online. Digital certificates are issued by CA centers, which use digital certificate authentication technology with digital encryption technology as the core. Through digital certificates, various information transmitted on the Internet can be encrypted, decrypted, digitally signed, and authenticated.

[0076] 5. Identity-Based Cryptograph (IBC)

[0077] The main idea of ​​IBC is that there is no need to use digital certificates to transmit public keys. Instead, identity information such as name, IP address, email address, mobile phone number, etc. representing the user's identification information is used as the public key, and the private key is calculated by the Key Generate Center (KGC) based on the key center public key and identity.

[0078] See also Figure 5 , Figure 5 This is one of the flow charts of an identity authentication method provided by an embodiment of the present invention, and the identity authentication method can be executed by a first terminal.

[0079] like Figure 5 As shown, the identity authentication method includes the following steps:

[0080] Step 501: Receive a first real-time transport protocol RTP message sent by a second terminal, where the first RTP message carries identity signature information of the second terminal;

[0081] Step 502: Authenticate the identity of the second terminal according to the first RTP message;

[0082] Step 503: Send a second RTP message to the second terminal, where the second RTP message carries a confirmation flag, and the confirmation flag is used to indicate whether the identity authentication of the second terminal is passed.

[0083] It should be noted that the identity authentication method provided in the embodiment of the present invention can be applied to the SIP session connection scenario of the VoIP system, and can also be applied to other scenarios of streaming media information transmission based on the RTP protocol. The specific method can be determined according to actual conditions and is not limited in the embodiment of the present invention.

[0084] Here, the specific implementation of the embodiment of the present invention is described by taking the SIP session connection scenario of the identity authentication method applicable to the VoIP system as an example, wherein the first terminal can be understood as the called user terminal in the SIP session connection, and the second terminal can be understood as the calling user terminal in the SIP session connection.

[0085] In an embodiment of the present invention, an end-to-end transmission capability for streaming media information is provided based on the RTP protocol. After the first terminal and the second terminal establish a SIP session connection, the first terminal and the second terminal use the RTP protocol to transmit identity signature information and confirmation of the signature information.

[0086] Step 501: Receive a first real-time transport protocol RTP message sent by a second terminal, where the first RTP message carries identity signature information of the second terminal.

[0087] In specific implementation, the second terminal can perform a signature operation on the FROM field and TO field of the invitation message (SIP message) sent to the first terminal, as well as the Transmission Control Protocol (TCP) sequence number (hereinafter referred to as the sequence number) and timestamp in the fixed part of the RTP message to obtain its identity signature information.

[0088] Among them, the FROM field of the invitation message (SIP message) includes the user identification of the second terminal. As the inviter of the SIP session connection, the second terminal signs the FROM field of the invitation message (SIP message) to authenticate the authenticity of its own identity. The TO field of the invitation message (SIP message) includes the identity identification of the first terminal. As the inviter of the network voice session, the second terminal signs the TO field of the invitation message (SIP message) to ensure that the invitee of the network voice session, that is, the identity of the first terminal, is not tampered with. The second terminal signs the sequence number and timestamp in the RTP message header, which can effectively prevent replay attacks.

[0089] It should be noted that the information signed by the second terminal is not limited to this, and can be determined according to actual conditions, and the embodiment of the present invention does not limit this. In addition, the specific implementation of the signature operation by the second terminal can refer to the signature algorithm in the relevant technology, and the embodiment of the present invention will not be repeated here.

[0090] The second terminal may write the identity signature information into the extended part of the RTP message to generate a first RTP message. After establishing a network voice session with the first terminal, the second terminal does not transmit streaming media information based on the RTP protocol, but transmits the first RTP message carrying the identity signature information based on the RTP protocol.

[0091] The first terminal may receive the first RTP message.

[0092] Step 502: Perform identity authentication on the second terminal according to the first RTP message.

[0093] In a specific implementation, after receiving the first RTP message, the first terminal may obtain the identity signature information in the first RTP message for identity authentication. Specifically, the first terminal may determine the process for identity authentication according to the verification type of the identity signature information.

[0094] Exemplarily, the identity signature information is obtained by the second terminal performing a signature operation using a private key, and the first terminal may verify the identity signature information according to the public key of the second terminal.

[0095] Alternatively, exemplarily, the identity signature information is obtained by the second terminal using a private key to perform a signature operation, and the second terminal generates a digital certificate for its public key. The first terminal can obtain the public key of the second terminal by obtaining the digital certificate of the second terminal, and then verify the identity signature information.

[0096] Step 503: Send a second RTP message to the second terminal, where the second RTP message carries a confirmation flag, and the confirmation flag is used to indicate whether the identity authentication of the second terminal is passed.

[0097] In specific implementation, after the first terminal passes the identity authentication of the second terminal, the first terminal can write the confirmation identifier into the extended part of the returned RTP message to generate a second RTP message. The first terminal can transmit the second RTP message carrying the confirmation identifier based on the RTP protocol.

[0098] Among them, the confirmation mark can reuse the ACK confirmation character in the related technology. When the value of the ACK confirmation character is 1, it means that the first terminal has passed the identity authentication of the second terminal, indicating that the second terminal can start to transmit streaming media information based on the RTP protocol; when the value of the ACK confirmation character is 0, it means that the first terminal has failed to pass the identity authentication of the second terminal, indicating that the second terminal can interrupt the current connection. The confirmation mark can also introduce a new confirmation mark, which can be determined according to actual conditions, and the embodiment of the present invention is not limited here.

[0099] For ease of understanding, in the embodiment of the present invention, the complete process of performing a SIP session connection between the first terminal and the second terminal can be as follows: Figure 6 As shown:

[0100] The first terminal and the second terminal may first establish a SIP session connection based on the SIP protocol. For the specific process, please refer to Figure 2 The explanation of the process shown is not repeated here to avoid repetition; after the SIP session connection is successfully established, the first terminal and the second terminal can perform identity authentication based on the RTP protocol. For details, please refer to the above explanation of steps 501 to 503, which are not repeated here to avoid repetition; after the first terminal successfully authenticates the second terminal, the first terminal and the second terminal can transmit streaming media information based on the RTP protocol.

[0101] The identity authentication method provided in the embodiment of the present invention can provide end-to-end transmission capability based on the RTP protocol, and can directly transmit identity signature information and a confirmation mark after identity authentication between the first terminal and the second terminal through the RTP message using the extended part of the RTP message. Figure 3 For the identity authentication method shown, there is no need to rely on the authentication server and the verification server for signing and verification, which improves the stability and efficiency of identity authentication between terminals, and can achieve direct trust between terminals, thereby improving the reliability and accuracy of identity authentication. Figure 4 For the identity authentication method shown, there is no need to solve the compatibility problem of the proxy server, and no modification is required to the existing network. That is, end-to-end transmission of identity signature information and signature confirmation information between terminals can be achieved, which also improves the efficiency and reliability of identity authentication between terminals.

[0102] The first RTP message in the embodiment of the present invention is described below:

[0103] In the embodiment of the present invention, optionally, the identity signature information of the second terminal is located in an extension part of the first RTP message header.

[0104] In a specific implementation, the RTP message header includes a fixed part. In the case where the X bit in the fixed part is set to 1, the RTP message header also includes an extended part, such as Figure 7 shown.

[0105] The fixed part cannot be customized by the user.

[0106] The extension part can add user-defined content. Figure 8 As shown, the extended part includes a first field, and the first field is used to indicate the purpose of the extended part. In actual applications, the first field can be expressed as a "Defined By Profile" field; the extended part also includes a second field, and the second field is used to indicate the length of the extended part. In actual applications, the second field can be expressed as a "Length" field; the extended part also includes a third field, and the third field is used to indicate the message type of the RTP message. In actual applications, the second field can be expressed as a "Message Type" field; the extended part also includes a fourth field, and the fourth field is used to indicate the content of the extended part. In actual applications, the second field can be expressed as a "Value" field.

[0107] In this optional implementation, the second terminal can write the identity signature information into the fourth field of the extension part of the first RTP message header, and define the message type of the third field as a signature message. In actual applications, the third field of the first RTP message can be expressed as "Message Type = Signature", and the fourth field of the first RTP message can be expressed as "Signature Value".

[0108] It should be noted that the message structure of the first RTP message is not limited thereto, and can be determined according to actual conditions, and is not limited in this embodiment of the present invention.

[0109] The second RTP message in the embodiment of the present invention is described below:

[0110] In the embodiment of the present invention, optionally, the confirmation identifier is located in an extension part of the second RTP message header.

[0111] In a specific implementation, the RTP message header includes a fixed part. In the case where the X bit in the fixed part is set to 1, the RTP message header also includes an extended part, such as Figure 7 shown.

[0112] The fixed part cannot be customized by the user.

[0113] The extension part can add user-defined content. Figure 8 As shown, the extended part includes a first field, and the first field is used to indicate the purpose of the extended part. In actual applications, the first field can be expressed as a "Defined By Profile" field; the extended part also includes a second field, and the second field is used to indicate the length of the extended part. In actual applications, the second field can be expressed as a "Length" field; the extended part also includes a third field, and the third field is used to indicate the message type of the RTP message. In actual applications, the second field can be expressed as a "Message Type" field; the extended part also includes a fourth field, and the fourth field is used to indicate the content of the extended part. In actual applications, the second field can be expressed as a "Value" field.

[0114] In this optional implementation, the second terminal may write the confirmation identifier into the fourth field of the extension part of the second RTP message header, and define the message type of the third field as a signature confirmation message. In practical applications, taking the confirmation identifier multiplexing ACK confirmation character as an example, the third field of the second RTP message may be expressed as "Message Type = ACK", and the fourth field of the second RTP message may be expressed as "ACK Value".

[0115] It should be noted that the message structure of the second RTP message is not limited thereto, and can be determined according to actual conditions, and is not limited in this embodiment of the present invention.

[0116] The identity signature information of the second terminal is described below:

[0117] The determination of the identity signature information of the second terminal may include the following two implementation forms:

[0118] In a first implementation form, the identity signature information of the second terminal is obtained by performing a signature operation on a FROM field and a TO field of a Session Initiation Protocol SIP message header, and a sequence number Sequence Number and a timestamp Timestamp in the first RTP message header.

[0119] In specific implementation, the second terminal can use the private key to perform a signature operation on the FROM field and TO field of the invitation message (SIP message) sent to the first terminal, as well as the Transmission Control Protocol (TCP) sequence number (hereinafter referred to as the sequence number) and timestamp in the fixed part of the RTP message to obtain its identity signature information.

[0120] Among them, the FROM field of the invitation message (SIP message) includes the user identification of the second terminal. As the inviter of the SIP session connection, the second terminal signs the FROM field of the invitation message (SIP message) to authenticate the authenticity of its own identity. The TO field of the invitation message (SIP message) includes the identity identification of the first terminal. As the inviter of the network voice session, the second terminal signs the TO field of the invitation message (SIP message) to ensure that the invitee of the network voice session, that is, the identity of the first terminal, is not tampered with. The second terminal signs the sequence number and timestamp in the RTP message header, which can effectively prevent replay attacks.

[0121] In this implementation form, the first terminal may obtain the public key of the second terminal to verify the identity signature information of the second terminal, and the first terminal may also verify the identity signature information of the second terminal through a digital certificate.

[0122] Specifically, optionally, the performing identity authentication on the second terminal according to the first real-time transport protocol message includes:

[0123] Determining a user identifier of the second terminal according to a FROM field of the Session Initiation Protocol SIP message header;

[0124] Obtaining a blockchain certificate corresponding to the user identifier on a public chain;

[0125] When the public chain certificate corresponding to the user identifier is obtained on the public chain and the public chain certificate corresponding to the user identifier is valid, the identity of the second terminal is authenticated according to the public chain certificate corresponding to the user identifier.

[0126] In this optional implementation, the first terminal may use a digital certificate to verify the identity of the second terminal, and perform identity authentication based on a public key infrastructure PKI built on a public chain to solve the trust problem of the digital certificate.

[0127] In a specific implementation, the first terminal and the second terminal can both be terminals in a trusted public chain, and the user of the first terminal and the user of the second terminal can both apply for a public chain certificate based on the accounting and consensus mechanism of the public chain.

[0128] After receiving the first RTP message, the first terminal can determine the user identifier of the second terminal according to the FROM field in the SIP message sent by the second terminal previously received. The user identifier of the second terminal can be the telephone number of the user of the second terminal, or the SIP URI of the user of the second terminal; thereafter, the first terminal can query the public chain certificate corresponding to the user identifier on the public chain according to the user identifier of the second terminal.

[0129] The above query will result in the following three situations:

[0130] The first case: if the public chain certificate of the user identifier is not found on the public chain, the hash value of the user identifier can be used to query the public chain again for the public chain certificate corresponding to the hash value of the user identifier. If the public chain certificate corresponding to the hash value of the user identifier is not found on the public chain, it proves that the second terminal does not have a public chain certificate on the public chain. The first terminal obtains the above query result and can determine that the identity of the second terminal is in doubt and the identity authentication of the second terminal has not passed.

[0131] The second case: if the public chain certificate corresponding to the user identifier or the hash value of the user identifier is queried on the public chain, it can be checked whether the public chain certificate is valid. If it is determined that the public chain certificate is invalid, that is, the public chain certificate exists but is invalid, the identity authentication of the second terminal is also failed.

[0132] The third case: if the public chain certificate corresponding to the user identifier or the hash value of the user identifier is queried on the public chain, it can be checked whether the public chain certificate is valid. If it is determined that the public chain certificate is valid, that is, the public chain certificate exists and is valid, the first terminal obtains the above query result, and it can be determined that the identity of the second terminal is authentic and the identity authentication of the second terminal is passed.

[0133] It should be noted that, in this optional implementation, the first field of the extension part of the first RTP message and the second RTP message (used to indicate the purpose of the extension part) can be set to "0X808A" to inform the first terminal of the current identity authentication method. It can be understood that, in this optional implementation, the expression form of the first RTP message and the second RTP message is not limited to this, and can be determined according to actual conditions, and is not limited here.

[0134] In this optional implementation, identity authentication is performed based on the public key infrastructure PKI built on the public chain to solve the trust problem of digital certificates. At the same time, because the public chain certificate is self-signed rather than signed by a third party, its authenticity and reliability are guaranteed by the public chain, thereby further improving the reliability and accuracy of identity authentication between terminals.

[0135] It should be noted that in other optional implementations, the trust problem that exists when using digital certificates for identity authentication can also be solved based on other methods. The specific method can be determined based on actual conditions and is not limited in the embodiments of the present application.

[0136] In a second implementation form, the identity signature information of the second terminal is obtained by performing a signature operation on the FROM field and TO field of the SIP message header, the sequence number Sequence Number and time Timestamp in the fixed part of the first RTP message header, the key center name KGC Name in the first RTP message header, the second terminal identification sequence number SN of Identity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list.

[0137] In specific implementation, the second terminal can use the private key to perform a signature operation on the FROM field and TO field of the invitation message (SIP message) sent to the first terminal, the sequence number SequenceNumber and time Timestamp in the fixed part of the first RTP message header, the key center name KGC Name in the first RTP message header, the second terminal identification sequence number SN of Identity, and the hash algorithm name Name of HashAlgorothm used in the user identification revocation list, to obtain its identity signature information.

[0138] Among them, the FROM field of the invitation message (SIP message) includes the user identification of the second terminal. The second terminal, as the inviter of the SIP session connection, signs the FROM field of the invitation message (SIP message) to authenticate the authenticity of its own identity. The TO field of the invitation message (SIP message) includes the identity identification of the first terminal. The second terminal, as the inviter of the network voice session, signs the TO field of the invitation message (SIP message) to ensure that the invitee of the network voice session, that is, the identity of the first terminal, is not tampered with. The second terminal signs the serial number and timestamp in the RTP message header, which can effectively prevent replay attacks. The second terminal signs the key center name KGC Name in the first RTP message header, the second terminal identification serial number SN of Identity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list, which can ensure the authenticity and integrity of the above information.

[0139] In this implementation form, the first terminal may obtain the public key of the second terminal to verify the identity signature information of the second terminal, and the first terminal may also verify the identity signature information of the second terminal based on the key center KGC.

[0140] Specifically, optionally, the performing identity authentication on the second terminal according to the first real-time transport protocol message includes:

[0141] Determine the user identifier of the second terminal according to the FROM field of the Session Initiation Protocol SIP message header; obtain the key center KGC information block corresponding to the second terminal on the alliance chain according to the key center name KGC Name and the user identifier of the second terminal;

[0142] When the key center KGC information block corresponding to the second terminal is obtained on the alliance chain and the key center KGC information block corresponding to the second terminal is valid, identity authentication of the second terminal is performed according to the information in the key center KGC information block;

[0143] The information in the key center information block includes the key center public key and the signature verification algorithm.

[0144] In this optional implementation, the first terminal can authenticate the second terminal based on the key center KGC constructed by the alliance chain, and write the KGC information block and the user identification revocation list into the alliance chain through the consensus mechanism of the alliance chain, thereby solving the problem of cross-domain transmission of KGC parameters and the trust problem between multiple regions.

[0145] In specific implementation, after receiving the first RTP message, the first terminal can determine the user identification of the second terminal according to the FROM field in the SIP message sent by the second terminal previously received. The user identification of the second terminal can be the telephone number of the user of the second terminal, or the SIP URI of the user of the second terminal; then, the first terminal can obtain the user identification and KGCName of the second terminal carried in the first RTP message. The user identification of the second terminal can be composed of the user identification and the serial number of the second terminal. The serial number of the second terminal can be the serial number generated by the key center KGC for the second terminal in order to manage it.

[0146] The first terminal may query the KGC information block corresponding to the second terminal on the alliance chain according to the user identifier and KGCName of the second terminal. The query may result in the following three situations:

[0147] The first case: if the KGC information block corresponding to the second terminal is not found on the alliance chain, it proves that the second terminal is not on the alliance chain, the first terminal cannot obtain the public key and signature verification algorithm, the identity of the second terminal is in doubt, and the identity verification of the second terminal fails.

[0148] The second case: if the KGC information block corresponding to the second terminal is found on the alliance chain, it can be checked whether the KGC information block corresponding to the second terminal is valid. If it is determined that the KGC information block corresponding to the second terminal is invalid, the identity authentication of the second terminal also fails.

[0149] The third case: If the KGC information block corresponding to the second terminal is queried on the alliance chain, it can be checked whether the KGC information block corresponding to the second terminal is valid. If it is determined that the KGC information block corresponding to the second terminal is valid, the first terminal obtains the above query result, and it can be determined that the identity of the second terminal is authentic and the identity authentication of the second terminal is passed.

[0150] It should be noted that, in this optional implementation, the first field of the extended part of the first RTP message and the second RTP message (used to indicate the purpose of the extended part) can be set to "0X808B" to inform the first terminal of the current identity authentication method.

[0151] like Fig. 9As shown, the extended part of the first RTP message may also include a fifth field, and the fifth field is used to indicate the KGC Name. In actual applications, the fifth field can be expressed as a "KGC Name" field; the extended part may also include a sixth field, and the sixth field is used to indicate the serial number of the second terminal. In actual applications, the sixth field can be expressed as a "SN of Identity" field; the extended part may also include a seventh field, and the seventh field is used to indicate a hash value of the identity of the second terminal. In actual applications, the second field can be expressed as a "Name of Hash algorithm" field.

[0152] It can be understood that, in this optional implementation, the presentation forms of the first RTP message and the second RTP message are not limited thereto, and can be determined based on actual conditions, and are not limited here.

[0153] Further, optionally, after determining the user identifier of the second terminal according to the FROM field of the session initiation protocol SIP message header, and before authenticating the second terminal according to the information in the key center KGC information block, the method further includes:

[0154] Calculating a hash value corresponding to the user identifier of the second terminal;

[0155] determining, according to the hash value corresponding to the user identifier of the second terminal, whether the hash value corresponding to the user identifier of the second terminal is stored in the user identifier revocation list, the user identifier revocation list storing the hash value corresponding to the revoked user identifier;

[0156] The performing identity authentication on the second terminal according to the information in the key center information block includes:

[0157] In a case where the hash value corresponding to the user identifier of the second terminal is not stored in the user identifier revocation list, the identity of the second terminal is authenticated according to the information in the key center KGC information block.

[0158] In this optional implementation, the key center KGC can maintain a user identity revocation list, which stores hash values ​​corresponding to revoked user identities. According to the user identity revocation list, it can be determined which terminals have been revoked, which can further improve the accuracy of identity authentication.

[0159] In specific implementation, after receiving the first RTP message, the first terminal can calculate the hash value of the user identifier of the second terminal carried therein. Afterwards, the first terminal can query the KGC information block corresponding to the second terminal on the alliance chain based on the hash value of the user identifier and the key center name KGC Name. When the KGC information block corresponding to the second terminal is queried and the KGC information block corresponding to the second terminal is valid, the first terminal also needs to further determine whether the hash value of the user identifier of the second terminal is on the user identifier revocation list.

[0160] When the following three conditions are all met, the first terminal may authenticate the second terminal according to the information in the KGC information block corresponding to the second terminal:

[0161] 1) The alliance chain stores a KGC information block corresponding to the second terminal;

[0162] 2) The KGC information block corresponding to the second terminal is valid;

[0163] 3) The user ID of the second terminal is not on the user ID revocation list.

[0164] In this optional implementation, a key center KGC is built based on the alliance chain for identity authentication, and the KGC information block and the user identification revocation list are written into the alliance chain through the consensus mechanism of the alliance chain. This solves the problem of cross-domain transmission of KGC parameters and the trust problem between multiple regions, and further improves the scope of application and reliability of identity authentication between terminals.

[0165] It should be noted that in other optional implementations, the problem of cross-domain transmission of KGC parameters and the trust problem between multiple regions that exist when remembering KGC for identity authentication can also be solved based on other methods. The specific method can be determined based on actual conditions and is not limited in the embodiments of the present application.

[0166] See also Fig.10 , Fig.10 This is a second flow chart of an identity authentication method provided by an embodiment of the present invention, and the identity authentication method can be executed by a second terminal.

[0167] like Fig.10 As shown, the identity authentication method includes the following steps:

[0168] Step 1001: Send a first real-time transport protocol message to a first terminal, wherein the first real-time transport protocol message carries identity signature information of the second terminal;

[0169] Step 1002: Receive a second real-time transport protocol message sent by the first terminal, where the second real-time transport protocol message carries a confirmation flag, and the confirmation flag is used to indicate whether the identity authentication of the second terminal is passed.

[0170] Optionally, the first real-time transport protocol message includes a first field, and the first field is used to indicate identity signature information of the second terminal.

[0171] Optionally, the second real-time transport protocol message includes a second field, and the second field is used to indicate the confirmation identifier.

[0172] Optionally, before sending the first real-time transport protocol RTP message to the first terminal, the method further includes:

[0173] A signature operation is performed on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the sequence number Sequence Number and the timestamp Timestamp in the first RTP message header to obtain the identity signature information of the second terminal.

[0174] Optionally, before sending the first real-time transport protocol RTP message to the first terminal, the method further includes:

[0175] A signature operation is performed on the FROM field and TO field of the SIP message header, the sequence number Sequence Number and time Timestamp in the fixed part of the first RTP message header, the key center name KGCName in the first RTP message header, the second terminal identification sequence number SN of Identity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list to obtain the identity signature information of the second terminal.

[0176] It should be noted that this embodiment is an implementation of the second terminal corresponding to the above method embodiment, and therefore, reference may be made to the relevant description in the above method embodiment, and the same beneficial effects can be achieved. To avoid repeated description, it will not be repeated here.

[0177] The identity authentication method provided in the embodiment of the present invention can provide end-to-end transmission capability based on the RTP protocol, and can directly transmit identity signature information and a confirmation mark after identity authentication between the first terminal and the second terminal through the RTP message using the extended part of the RTP message. Figure 3For the identity authentication method shown, there is no need to rely on the authentication server and the verification server for signing and verification, which improves the stability and efficiency of identity authentication between terminals, and can achieve direct trust between terminals, thereby improving the reliability and accuracy of identity authentication. Figure 4 For the identity authentication method shown, there is no need to solve the compatibility problem of the proxy server, and no modification is required to the existing network. That is, end-to-end transmission of identity signature information and signature confirmation information between terminals can be achieved, which also improves the efficiency and reliability of identity authentication between terminals.

[0178] See also Fig.11 , Fig.11 FIG. 1 is one of the structural diagrams of the identity authentication device provided by the embodiment of the present invention. Fig.11 As shown, the identity verification device 1100 includes:

[0179] The first receiving module 1101 is configured to receive a first real-time transport protocol message sent by a second terminal, wherein the first real-time transport protocol RTP message carries identity signature information of the second terminal;

[0180] A first processing module 1102, configured to authenticate the second terminal according to the first RTP message;

[0181] The first sending module 1103 is used to send a second RTP message to the second terminal, where the second RTP message carries a confirmation flag, and the confirmation flag is used to indicate whether the identity authentication of the second terminal is passed.

[0182] Optionally, the identity signature information of the second terminal is located in an extended part of the first RTP message header.

[0183] Optionally, the confirmation identifier is located in an extended part of the second RTP message header.

[0184] Optionally, the identity signature information of the second terminal is obtained by performing a signature operation on a FROM field and a TO field of a Session Initiation Protocol SIP message header, and a sequence number Sequence Number and a timestamp Timestamp in the first RTP message header;

[0185] The first processing module 1102 includes:

[0186] A first determining unit, configured to determine a user identifier of the second terminal according to a FROM field of the Session Initiation Protocol SIP message header;

[0187] A first acquisition unit, configured to acquire a blockchain certificate corresponding to the user identifier on a public chain;

[0188] The first verification unit is used to obtain the public chain certificate corresponding to the user identifier on the public chain, and if the public chain certificate corresponding to the user identifier is valid, perform identity authentication on the second terminal according to the public chain certificate corresponding to the user identifier.

[0189] Optionally, the first RTP message also carries a key center name KGC Name, a second terminal identification serial number SN of Identity, and a hash algorithm name Name of Hash Algorothm used in a user identification revocation list; the identity signature information of the second terminal is obtained by performing a signature operation on a FROM field and a TO field of a SIP message header, a sequence number Sequence Number and a time Timestamp in a fixed part of the first RTP message header, and a key center name KGC Name in the first RTP message header, a second terminal identification serial number SN of Identity, and a hash algorithm name Name of Hash Algorothm used in a user identification revocation list;

[0190] The first processing module 1102 includes:

[0191] A second determining unit, configured to determine a user identifier of the second terminal according to a FROM field of the Session Initiation Protocol SIP message header;

[0192] A second acquisition unit, configured to acquire a key center KGC information block corresponding to the second terminal on the alliance chain according to the key center name KGC Name and the user identifier of the second terminal;

[0193] A second verification unit is configured to obtain a key center KGC information block corresponding to the second terminal on the alliance chain, and if the key center KGC information block corresponding to the second terminal is valid, authenticate the identity of the second terminal according to the information in the key center KGC information block;

[0194] The information in the key center information block includes the key center public key and the signature verification algorithm.

[0195] Optionally, the first processing module 1102 further includes:

[0196] A calculation unit, configured to calculate a hash value corresponding to a user identifier of the second terminal;

[0197] a third determining unit, configured to determine, according to the hash value corresponding to the user identifier of the second terminal, whether the hash value corresponding to the user identifier of the second terminal is stored in the user identifier revocation list, wherein the user identifier revocation list stores the hash value corresponding to the revoked user identifier;

[0198] The second verification unit is specifically used for:

[0199] In the case where the hash value corresponding to the user identifier of the second terminal is not stored in the user identifier revocation list, the second terminal is authenticated according to the information in the key center KGC information block. The identity authentication device 1100 can implement the various processes that the first terminal can implement in the embodiment of the method of the present invention, and achieve the same beneficial effects. To avoid repetition, it will not be repeated here.

[0200] See also Fig.12 , Fig.12 FIG. 2 is a structural diagram of the identity authentication device provided by an embodiment of the present invention. Fig.12 As shown, the identity verification device 1200 includes:

[0201] The second sending module 1201 is used to send a first real-time transport protocol RTP message to the first terminal, where the first RTP message carries the identity signature information of the second terminal;

[0202] The second receiving module 1202 is used to receive a second RTP message sent by the first terminal, where the second RTP message carries a confirmation flag, and the confirmation flag is used to indicate whether the identity authentication of the second terminal is passed.

[0203] Optionally, the identity signature information of the second terminal is located in an extended part of the first RTP message header.

[0204] Optionally, the confirmation identifier is located in an extended part of the second RTP message header.

[0205] Optionally, the identity verification device 1200 further includes:

[0206] The first signature module is used to perform a signature operation on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the sequence number Sequence Number and the timestamp Timestamp in the first RTP message header to obtain the identity signature information of the second terminal.

[0207] Optionally, the identity verification device 1200 further includes:

[0208] The second signature module is used to perform a signature operation on the FROM field and TO field of the SIP message header, the sequence number Sequence Number and the time Timestamp in the fixed part of the first RTP message header, the key center name KGC Name in the first RTP message header, the second terminal identification sequence number SN of Identity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list to obtain the identity signature information of the second terminal.

[0209] The identity authentication device 1200 can implement each process that the second terminal in the method embodiment of the present invention can implement, and achieve the same beneficial effects. To avoid repetition, it will not be described here.

[0210] The embodiment of the present invention also provides an electronic device. Fig.13 The electronic device may include a processor 1301, a memory 1302, and a computer program 13021 stored in the memory 1302 and executable on the processor 1301. When the computer program 13021 is executed by the processor 1301, Figure 5 or Fig.10 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0211] A person skilled in the art can understand that all or part of the steps of implementing the above-mentioned embodiment method can be completed by hardware related to program instructions, and the program can be stored in a computer-readable medium. The embodiment of the present invention also provides a computer-readable storage medium, on which a third computer program is stored, and when the third computer program is executed by a fourth processor, the above-mentioned Figure 5 or Fig.10 Any steps in the corresponding method embodiments can achieve the same technical effect and will not be repeated here to avoid repetition.

[0212] The storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0213] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. An identity authentication method, applied to a first terminal, characterized in that: include: receiving a first real-time transport protocol message sent by a second terminal, wherein the first real-time transport protocol RTP message carries identity signature information of the second terminal; Performing identity authentication on the second terminal according to the first RTP message; Sending a second RTP message to the second terminal, where the second RTP message carries a confirmation identifier, where the confirmation identifier is used to indicate whether the identity authentication of the second terminal is passed; The identity signature information of the second terminal is obtained by performing a signature operation on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the Sequence Number and the timestamp in the first RTP message header; and authenticating the second terminal according to the first real-time transport protocol message includes: Determining a user identifier of the second terminal according to a FROM field of the Session Initiation Protocol SIP message header; Obtaining a blockchain certificate corresponding to the user identifier on a public chain; When the public chain certificate corresponding to the user identifier is obtained on the public chain and the public chain certificate corresponding to the user identifier is valid, the identity of the second terminal is authenticated according to the public chain certificate corresponding to the user identifier.

2. The method according to claim 1, characterized in that The identity signature information of the second terminal is located in the extension part of the first RTP message header.

3. The method according to claim 1, characterized in that The confirmation identifier is located in the extension part of the second RTP message header.

4. The method according to claim 1, characterized in that: The first RTP message also carries a key center name KGC Name, a second terminal identification serial number SN ofIdentity, and a hash algorithm name Name of Hash Algorothm used in a user identification revocation list; the identity signature information of the second terminal is obtained by performing a signature operation on the FROM field and the TO field of the SIP message header, the sequence number Sequence Number and the time Timestamp in the fixed part of the first RTP message header, the key center name KGC Name in the first RTP message header, the second terminal identification serial number SN ofIdentity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list; the identity authentication of the second terminal according to the first real-time transport protocol message includes: Determine the user identifier of the second terminal according to the FROM field of the Session Initiation Protocol SIP message header; obtain the key center KGC information block corresponding to the second terminal on the alliance chain according to the key center name KGC Name and the user identifier of the second terminal; When the key center KGC information block corresponding to the second terminal is obtained on the alliance chain and the key center KGC information block corresponding to the second terminal is valid, identity authentication of the second terminal is performed according to the information in the key center KGC information block; The information in the key center information block includes the key center public key and the signature verification algorithm.

5. The method according to claim 4, characterized in that After determining the user identification of the second terminal according to the FROM field of the Session Initiation Protocol SIP message header, and before performing identity authentication on the second terminal according to the information in the key center KGC information block, the method further includes: Calculating a hash value corresponding to the user identifier of the second terminal; determining, according to the hash value corresponding to the user identifier of the second terminal, whether the hash value corresponding to the user identifier of the second terminal is stored in the user identifier revocation list, the user identifier revocation list storing the hash value corresponding to the revoked user identifier; The performing identity authentication on the second terminal according to the information in the key center information block includes: In a case where the hash value corresponding to the user identifier of the second terminal is not stored in the user identifier revocation list, the identity of the second terminal is authenticated according to the information in the key center KGC information block.

6. An identity authentication method, applied to a second terminal, characterized in that: include: Sending a first real-time transport protocol RTP message to the first terminal, where the first RTP message carries the identity signature information of the second terminal; receiving a second RTP message sent by the first terminal, where the second RTP message carries a confirmation identifier, and the confirmation identifier is used to indicate whether the identity authentication of the second terminal is passed; Before sending the first real-time transport protocol RTP message to the first terminal, the method further includes: A signature operation is performed on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the sequence number Sequence Number and the timestamp Timestamp in the first RTP message header to obtain the identity signature information of the second terminal.

7. The method according to claim 6, characterized in that The identity signature information of the second terminal is located in the extension part of the first RTP message header.

8. The method according to claim 6, characterized in that The confirmation identifier is located in the extension part of the second RTP message header.

9. The method according to claim 6, characterized in that Before sending the first real-time transport protocol RTP message to the first terminal, the method further includes: A signature operation is performed on the FROM field and TO field of the SIP message header, the sequence number Sequence Number and time Timestamp in the fixed part of the first RTP message header, the key center name KGCName in the first RTP message header, the second terminal identification sequence number SN of Identity, and the hash algorithm name Name of Hash Algorothm used in the user identification revocation list to obtain the identity signature information of the second terminal.

10. An identity verification device, characterized in that: include: A first receiving module, configured to receive a first real-time transport protocol RTP message sent by a second terminal, wherein the first RTP message carries identity signature information of the second terminal; A first processing module, configured to authenticate the second terminal according to the first RTP message; A first sending module, configured to send a second RTP message to the second terminal, wherein the second RTP message carries a confirmation mark, and the confirmation mark is used to indicate whether the identity authentication of the second terminal is passed; The identity signature information of the second terminal is obtained by performing a signature operation on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the sequence number Sequence Number and the timestamp Timestamp in the first RTP message header; the first processing module includes: A first determining unit, configured to determine a user identifier of the second terminal according to a FROM field of the Session Initiation Protocol SIP message header; A first acquisition unit, configured to acquire a blockchain certificate corresponding to the user identifier on a public chain; The first verification unit is used to obtain the public chain certificate corresponding to the user identifier on the public chain, and if the public chain certificate corresponding to the user identifier is valid, perform identity authentication on the second terminal according to the public chain certificate corresponding to the user identifier.

11. An identity verification device, characterized in that: include: A second sending module, configured to send a first real-time transport protocol RTP message to the first terminal, wherein the first RTP message carries identity signature information of the second terminal; A second receiving module, used to receive a second RTP message sent by the first terminal, where the second RTP message carries a confirmation mark, and the confirmation mark is used to indicate whether the identity authentication of the second terminal is passed; The device also includes: The first signature module is used to perform a signature operation on the FROM field and the TO field of the Session Initiation Protocol SIP message header, and the sequence number Sequence Number and the timestamp Timestamp in the first RTP message header to obtain the identity signature information of the second terminal.

12. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the method according to any one of claims 1 to 9 when executed by the processor.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images