CN114726958A

CN114726958A - Identity authentication method and device, electronic equipment and readable storage medium

Info

Publication number: CN114726958A
Application number: CN202110005426.6A
Authority: CN
Inventors: 刘福文; 杨波; 王珂; 阎军智; 粟栗
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2021-01-05
Filing date: 2021-01-05
Publication date: 2022-07-08

Abstract

The invention provides an identity verification method, an identity verification device, electronic equipment and a readable storage medium, which can provide end-to-end transmission capability based on an RTP protocol, and can directly realize end-to-end transmission of identity signature information and a confirmation identifier after identity verification between a first terminal and a second terminal through an RTP message by utilizing an extension part of an RTP message header, thereby improving the stability and the efficiency of identity verification between the terminals, realizing direct trust between the terminals and improving the reliability and the accuracy of the identity verification.

Description

Identity authentication method and device, electronic equipment and readable storage medium

Technical Field

The embodiment of the invention relates to the technical field of communication, in particular to an identity authentication method, an identity authentication device, electronic equipment and a readable storage medium.

Background

Voice over Internet Protocol (VoIP) is a Voice call technology based on Internet Protocol (IP), and is hereinafter referred to as a VoIP system. The VoIP system achieves voice conversation and multimedia conference via the internet. However, VoIP systems are often difficult to guarantee caller number authenticity compared to conventional telephone network systems.

In the prior art, the authentication server and the verification server of the STIR framework are usually used to realize the authentication and verification of the calling identity. However, in a communication domain, if an authentication server goes down, all outgoing calls in the communication domain cannot continue; similarly, if an authentication server goes down in a communication domain, all incoming calls in the communication domain cannot continue.

Therefore, the identity verification system in the prior art depends on the authentication server and the verification server, and the fault tolerance and the stability of the system are poor.

Disclosure of Invention

Embodiments of the present invention provide an identity authentication method, an identity authentication device, an electronic device, and a readable storage medium, which solve the problem that the existing identity authentication system is poor in fault tolerance and stability.

In order to solve the above problem, in a first aspect, an embodiment of the present invention provides an identity authentication method, applied to a first terminal, including:

receiving 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;

according to the first RTP message, performing identity authentication on the second terminal;

and sending a second RTP message to the second terminal, wherein the second RTP message carries an acknowledgement identifier, and the acknowledgement identifier is used for indicating whether the identity authentication of the second terminal passes or not.

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

sending a first real-time transport protocol (RTP) message to a first terminal, wherein the first RTP message carries identity signature information of the second terminal;

and receiving a second RTP message sent by the first terminal, wherein the second RTP message carries a confirmation identifier, and the confirmation identifier is used for indicating whether the identity authentication of the second terminal passes or not.

In a third aspect, an embodiment of the present invention provides an identity authentication apparatus, including:

a first receiving module, configured to 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;

the first processing module is used for carrying out identity authentication on the second terminal according to the first RTP message;

a first sending module, configured to send a second RTP message to the second terminal, where the second RTP message carries an acknowledgement identifier, and the acknowledgement identifier is used to indicate whether the authentication of the second terminal passes or not.

In a fourth aspect, an embodiment of the present invention provides an identity authentication apparatus, including:

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

a second receiving module, configured to receive a second RTP message sent by the first terminal, where the second RTP message carries an acknowledgement identifier, and the acknowledgement identifier is used to indicate whether the authentication of the second terminal passes or not.

In a fifth aspect, an embodiment of the present invention provides an electronic device, which includes a processor, a memory, and a computer program stored on the memory and executable on the processor, and when executed by the processor, the computer program implements the steps of the authentication method described above.

In a sixth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the authentication method as described above.

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

the identity verification method, the identity verification device, the electronic equipment and the readable storage medium provided by the embodiment of the invention can provide end-to-end transmission capability based on an RTP protocol, and can directly realize end-to-end transmission of identity signature information and a confirmation identifier after identity verification between the first terminal and the second terminal through an RTP message by utilizing an extension part of an RTP message header, so that the stability and the efficiency of identity verification between the terminals are improved, the direct trust between the terminals can be realized, and the reliability and the accuracy of the identity verification are improved. In addition, no modification of the existing network is required.

Drawings

Fig. 1 is a block diagram of a network system to which an embodiment of the present invention is applicable;

fig. 2 is a schematic flow chart of SIP session connection in a VoIP system;

FIG. 3 is a flow chart illustrating an authentication method based on STIR/SHAKEN architecture;

fig. 4 is a flow chart diagram of an authentication method based on the SIP protocol;

fig. 5 is a flowchart illustrating an authentication method according to an embodiment of the present invention;

fig. 6 is a schematic flow chart illustrating SIP session connection in a VoIP system according to an embodiment of the present invention;

fig. 7 is one of specific message formats of an RTP message according to an embodiment of the present invention;

fig. 8 is a second specific message format of an RTP message according to the embodiment of the present invention;

fig. 9 is a third specific message format of an RTP message according to an embodiment of the present invention;

fig. 10 is a second flowchart illustrating an authentication method according to an embodiment of the present invention;

fig. 11 is one of the structural diagrams of an authentication apparatus provided in the embodiment of the present invention;

fig. 12 is a second structural diagram of an authentication apparatus according to an embodiment of the present invention;

fig. 13 is a structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The terms "first," "second," and the like in this application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Further, as used herein, "and/or" means at least one of the connected objects, e.g., a and/or B and/or C, means 7 cases including a alone, B alone, C alone, and both a and B present, B and C present, both a and C present, and A, B and C present.

In the embodiments of the present invention, words such as "exemplary" or "for example" are used to mean serving as examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "e.g.," an embodiment of the present invention is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.

Referring to fig. 1, fig. 1 is a block diagram of a network system to which an embodiment of the present invention is applicable. As shown in fig. 1, a first terminal 11 and a second terminal 12 are included, and communication can be performed between the first terminal 11 and the second terminal 12.

In the embodiment of the present invention, a terminal may also be referred to as a terminal device or a User Equipment (UE). In practical applications, the first terminal 11 and the second terminal 12 may be a Mobile phone, a Tablet Personal Computer (Tablet Personal Computer), a Laptop Computer (Laptop Computer) or a notebook Computer, a Personal Digital Assistant (PDA), a palm top Computer, a netbook, an ultra-Mobile Personal Computer (UMPC), a Mobile Internet Device (MID), a Wearable Device (Wearable Device) or a vehicle-mounted Device (VUE), a pedestrian terminal (PUE), and the like, and the Wearable Device includes: bracelets, earphones, glasses and the like. The present invention can be determined by practical situations, and is not limited in this respect.

For convenience of understanding, some contents related to the embodiments of the present invention are explained below:

VOIP system

The basic principle of the VoIP system is to compress the voice data code by the voice compression algorithm, then pack the voice data according to TCP/IP standard, send the data packet to the receiving place through IP network, then concatenate the voice data packets, and recover the original voice signal after decompression processing, thereby achieving the purpose of transmitting voice through Internet.

Referring to fig. 2, fig. 2 is a schematic flow chart of a main protocol of VoIP, as shown in fig. 2:

the protocol of VOIP mainly consists of two parts: 1) session Initiation Protocol (SIP), hereinafter referred to as SIP Protocol, which is mainly used for establishing and releasing SIP sessions; 2) real-time Transport Protocol (RTP), hereinafter referred to as RTP Protocol, is mainly used for transmitting Real-time streaming media information.

As shown in fig. 2, terminal a is a calling user terminal, and terminal B is a called user terminal.

1) And a network voice session is established between the terminal A and the terminal B based on the SIP protocol.

Terminal a establishes a network telephony connection with terminal B by sending an invite message (SIP message) to terminal B. Since the SIP protocol cannot realize the end-to-end transmission capability, the invite message needs to be forwarded through one or more proxy servers to reach the terminal B.

After receiving the invitation message, the terminal B may return an invitation confirmation message (OK message) if agreeing to the invitation message. The invite acknowledgement message also needs to be forwarded through one or more proxy servers to reach terminal a.

Based on the double acknowledgement mechanism, terminal a, after receiving the invitation acknowledgement information, returns a reception acknowledgement message (e.g., an Acknowledgement Character (ACK)) to terminal B to inform terminal B that the invitation acknowledgement message it sent has been received without error. The reception acknowledgement message also needs to be forwarded via one or more proxy servers to reach terminal B. And after the terminal B receives the confirmation character, the network voice conversation between the terminal A and the terminal B is successfully established.

2) And transmitting the stream media information between the terminal A and the terminal B based on the RTP protocol.

The RTP protocol provides end-to-end transport capabilities for streaming media information. After the SIP session between the terminal A and the terminal B is successfully established, the terminal A can acquire the IP address of the terminal B, and then transport stream media information through RTP message, so as to realize real-time SIP session connection.

Therefore, the VoIP system does not have the capability of verifying the identity of the calling party, so that the authenticity of the identity of the calling party is difficult to ensure compared with the traditional telephone network system. An attacker can make false calls by forging a calling number, so that phenomena such as voice spam calls, fraud calls, phishing, voice mail attacks and the like seriously affect the economic society are caused. In the prior art, some operators prevent calls initiated by calling numbers on a blacklist from arriving by maintaining the blacklist, but the blacklist needs to be updated in time and is not suitable for calls using random false numbers; some operators authenticate the calling number based on Secure Telephone Identity Revisit (STIR)/using toKENs security process claim message (SHAKEN) (hereinafter referred to as STIR/SHAKEN architecture).

Second, STIR/SHAKEN architecture

The STIR/SHAKEN structure defines a security mechanism to verify the identity of the originator of the SIP INVITE message. Referring to fig. 3, fig. 3 is a schematic flow chart of STIR/shift for verifying the identity of the initiator.

As shown in fig. 3, terminal a is a calling user terminal, and terminal B is a called user terminal:

1) terminal a sends an invite message (SIP message) to the authentication server.

2) The authentication server signs the DATA field, the FROM field and the TO field in the message header of the invitation message TO generate identity signature information, and then the identity signature information and the address indicating the certificate of the authentication server are put into the identity field of the message header of the invitation message. Wherein, the FROM field includes an identity of the terminal a (a SIP Uniform Resource Identifier (URI) of the terminal a or a phone number of the terminal a); the TO field includes an identity of terminal B (SIP Uniform Resource Identifier (URI) of terminal B or a phone number of terminal B); the DATA field includes a timestamp of the sending of the invite message.

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

4) The verification server obtains an authentication server certificate by linking to a Public Key Infrastructure (PKI) according to an address of the authentication server certificate.

5) And the verification server verifies the identity signature information according to the public key in the certificate of the authentication server. And after the verification is successful, the verification server sends the invitation message to the terminal B.

As can be seen from the above, the STIR/shift architecture relies on an authentication server and a verification server, and all call invite messages need to be signed by the authentication server and the signature verified by the verification server. Thus, once the authentication server is down in a communication domain, outgoing calls in all the domains cannot be carried out; similarly, in a communication domain, once the verification server goes down, all incoming calls in the domain cannot be processed, and the fault tolerance and stability of the system are poor.

In addition, the STIR/shift architecture also presents trust issues that need to be addressed. On one hand, both the terminal A and the terminal B need to trust an authentication server, a verification server and a PKI, but direct trust between the terminal A and the terminal B cannot be realized; on the other hand, the STIR/shift architecture relates to the digital Certificate to realize identity verification, and in practical applications, multiple electronic Certificate Authorities (CAs) are usually required to ensure the normal operation of the digital Certificate mechanism in consideration of the management of the Certificate and the requirements of different security levels, which may involve mutual trust between multiple CAs.

Identity authentication method based on SIP protocol

The identity authentication method based on the SIP protocol transmits identity signature information and signature authentication information through an identity field of an SIP invite message. Referring to fig. 4, fig. 4 is a flow chart illustrating an authentication method based on the SIP protocol.

As shown in fig. 4, terminal a is a calling user terminal, and terminal B is a called user terminal:

1) the terminal A signs the DATA field, the FROM field and the TO field in the invitation message header by using a private key of the terminal A, and writes the generated identity signature information into the identity field of the invitation message. And then sending the invitation message carrying the identity signature information to the terminal B. Since the SIP protocol cannot realize the end-to-end transmission capability, the invite message needs to be forwarded through one or more proxy servers to reach the terminal B.

After receiving the invitation message, the terminal B may perform identity verification according to the identity signature information in the invitation message, and then return an invitation confirmation message, where the invitation confirmation message carries the signature verification information and is used to indicate whether the identity verification passes. The invite acknowledgement message also needs to be forwarded through one or more proxy servers to reach terminal a.

Based on the double acknowledgement mechanism, after receiving the invitation acknowledgement information, terminal a may return a receipt acknowledgement message (e.g., an ACK acknowledgement character) to terminal B if it determines that the authentication passes, so as to inform terminal B that the invitation acknowledgement message sent by terminal B has been received without errors. The reception acknowledgement message also needs to be forwarded via one or more proxy servers to reach terminal B. And after the terminal B receives the confirmation character, the network voice conversation between the terminal A and the terminal B is successfully established.

Therefore, in the identity verification method based on the SIP protocol, since the SIP invite message needs to be routed through one or more proxy servers, if the identity signature information is written into the SIP invite message, each proxy server needs to be adaptively adjusted and upgraded to implement the transceiving and parsing of the SIP invite message carrying the identity signature message, which requires more work and is difficult to solve the compatibility problem of all the proxy servers.

In addition, the authentication method based on the SIP protocol also has a trust problem, that is, both the terminal a and the terminal B need to trust each proxy server, but cannot realize direct trust between the terminal a and the terminal B.

Four, digital certificate

The digital certificate is a digital certificate which marks identity information of each communication party in internet communication and can be used by people on the internet to identify the identity of the other party. The digital certificate is issued by a CA center, the CA center adopts a digital certificate authentication technology taking a digital encryption technology as a core, and various information transmitted on the Internet can be encrypted, decrypted, digitally signed, signed and authenticated by the digital certificate.

Fifthly, a password system Based on identification (Identity-Based cryptography, IBC)

The main idea of IBC is that a digital certificate is not used to transmit a public Key, but identification information representing a user, such as a name, an IP address, an email address, a mobile phone number, etc., is used as a public Key, and a private Key is calculated by a Key Center (KGC) according to the public Key of the Key Center and the identification.

Referring to fig. 5, fig. 5 is a flowchart illustrating an authentication method according to an embodiment of the present invention, where the authentication method can be executed by a first terminal.

As shown in fig. 5, the authentication method includes the following steps:

step 501, receiving 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;

step 502, according to the first RTP message, performing identity authentication on the second terminal;

step 503, sending a second RTP message to the second terminal, where the second RTP message carries an acknowledgement identifier, and the acknowledgement identifier is used to indicate whether the authentication of the second terminal passes or not.

It should be noted that the identity authentication method provided in the embodiment of the present invention may be applicable to an SIP session connection scenario of a VoIP system, and may also be applicable to other scenarios in which streaming media information is transmitted based on an RTP protocol, which may be determined specifically according to actual situations, and the embodiment of the present invention is not limited herein.

The specific implementation of the embodiment of the present invention is described herein by taking an SIP session connection scenario in which the authentication method is applied to a VoIP system as an example. The first terminal may be understood as a called subscriber terminal in an SIP session connection, and the second terminal may be understood as a calling subscriber terminal in the SIP session connection.

In the embodiment of the present invention, an end-to-end transmission capability for streaming media information is provided based on an RTP protocol, and after an SIP session connection is established between the first terminal and the second terminal, the first terminal and the second terminal transmit identity signature information and confirmation of the signature information by using the RTP protocol.

Step 501, receiving 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.

In specific implementation, the second terminal may perform signature operation on a FROM field and a TO field of an invite message (SIP message) sent TO the first terminal, and a Transmission Control Protocol (TCP) sequence number (hereinafter, referred TO as a sequence number) and a timestamp in a fixed part of an RTP message TO obtain identity signature information thereof.

The FROM field of the invitation message (SIP message) comprises the user identification of the second terminal, the second terminal is used as an inviter of the SIP session connection, and the authenticity of the identity of the second terminal can be authenticated by signing the FROM field of the invitation message (SIP message). The TO field of the invitation message (SIP message) comprises the identity of the first terminal, and the second terminal serves as an inviter of the network voice session and signs the TO field of the invitation message (SIP message), so that the identity of the invitee of the network voice session, namely the first terminal, can be ensured not TO be tampered. The second terminal signs the sequence number and the time stamp in the RTP message header, so that replay attack can be effectively prevented.

The information for signing by the second terminal is not limited to this, and may be determined according to actual situations, and the embodiment of the present invention is not limited herein. In addition, the specific implementation manner of the second terminal performing the signature operation may refer to a signature algorithm in the related art, and details of the embodiment of the present invention are not described herein again.

The second terminal may write the identity signature information into an extension portion of an RTP message to generate a first RTP message. After the network voice session is established with the first terminal, the second terminal does not transmit streaming media information based on an RTP protocol, but transmits a first RTP message carrying identity signature information based on the RTP protocol.

The first terminal may receive the first RTP message.

Step 502, according to the first RTP message, performing identity authentication on the second terminal.

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

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

Or, for example, the identity signature information is obtained by the second terminal performing signature operation by using a private key, and the second terminal generates a digital certificate for a public key thereof, and the first terminal may obtain the public key of the second terminal by obtaining the digital certificate of the second terminal, so as to verify the identity signature information.

In a specific implementation, after the first terminal passes the authentication of the second terminal, the first terminal may write the confirmation identifier into an extension portion of the returned RTP message, so as to generate a second RTP message. The first terminal may transmit a second RTP message carrying the acknowledgement identifier based on an RTP protocol.

Wherein, the acknowledgement identification can multiplex ACK acknowledgement characters in the related art. When the value of the ACK confirmation character is 1, the authentication of the first terminal to the second terminal is passed, and the second terminal is indicated to start to transmit streaming media information based on an RTP protocol; and when the value of the ACK confirmation character is 0, the authentication of the first terminal to the second terminal is not passed, and the second terminal is indicated to be capable of interrupting the current connection. The confirmation identifier may also introduce a new confirmation identifier, which may be determined according to actual situations, and the embodiment of the present invention is not limited herein.

For convenience of understanding, in the embodiment of the present invention, a complete flow of performing SIP session connection between the first terminal and the second terminal may be as shown in fig. 6:

the first terminal and the second terminal may first establish an SIP session connection based on an SIP protocol, and for a specific flow, reference may be made to the explanation of the flow shown in fig. 2, which is not described herein again to avoid repetition; after the SIP session connection is successfully established, the first terminal and the second terminal may perform identity authentication based on an RTP protocol, which may specifically refer to the explanation of steps 501 to 503, and no further description is given here to avoid repetition; after the first terminal successfully authenticates the second terminal, the first terminal and the second terminal may transmit streaming media information based on an RTP protocol.

The identity authentication method provided by the embodiment of the invention can provide end-to-end transmission capability based on an RTP protocol, and identity signature information and a confirmation identifier after identity authentication can be directly transmitted between the first terminal and the second terminal through the RTP message by utilizing an extension part of the RTP message. Compared with the identity verification method shown in fig. 3, the method does not need to rely on the authentication server and the verification server to carry out signature and signature verification, improves the stability and efficiency of identity verification between terminals, can realize direct trust between terminals, and improves the reliability and accuracy of identity verification. Compared with the identity authentication method shown in fig. 4, the method does not need to solve the compatibility problem of the proxy server, does not need to modify the existing network, can realize end-to-end transmission of identity signature information and signature confirmation information between terminals, and also improves the efficiency and reliability of identity authentication between terminals.

The following describes a first RTP message in the embodiment of the present invention:

in this embodiment of the present invention, optionally, the identity signature information of the second terminal is located in an extension portion of the first RTP message header.

In a specific implementation, the RTP message header includes a fixed part, and in the case that the X bit is set to 1 in the fixed part, the RTP message header further includes an extension part, as shown in fig. 7.

Wherein the fixed portion is not customizable by a user.

The extension portion may add custom content for the user. As shown in fig. 8, the extension part includes a first field for indicating the purpose of the extension part, and in actual application, the first field may be represented as a "Defined By Profile" field; the extension part further comprises a second field, wherein the second field is used for indicating the Length of the extension part, and in practical application, the second field can be expressed as a "Length" field; the extension part further comprises a third field, the third field is used for indicating the Message Type of the RTP Message, and in practical application, the second field may be represented as a "Message Type" field; the extension part further comprises a fourth field for indicating the content of the extension part, and in practical application, the second field may be represented as a "Value" field.

In this optional embodiment, the second terminal may write the identity signature information into a fourth field of the extension portion of the first RTP message header, and define the message type of the third field as a signature message. In practical applications, the third field of the first RTP Message may be represented as "Message Type ═ Signature", and the fourth field of the first RTP Message may be represented as "Signature Value".

It should be noted that the message structure of the first RTP message is not limited to this, and may be determined according to actual situations, and the embodiment of the present invention is not limited herein.

The following describes the second RTP message in the embodiment of the present invention:

in this embodiment of the present invention, optionally, the acknowledgement flag is located in an extension portion of the header of the second RTP message.

Wherein the fixed portion is not customizable by a user.

The extension portion may add custom content for the user. As shown in fig. 8, the extension part includes a first field for indicating the purpose of the extension part, and in actual application, the first field may be represented as a "Defined By Profile" field; the extension part also comprises a second field, wherein the second field is used for indicating the Length of the extension part, and in practical application, the second field can be expressed as a 'Length' field; the extension part further comprises a third field, the third field is used for indicating the Message Type of the RTP Message, and in practical application, the second field may be represented as a "Message Type" field; the extension part further comprises a fourth field for indicating the content of the extension part, and in practical application, the second field may be represented as a "Value" field.

In this optional embodiment, the second terminal may write the acknowledgement flag into a fourth field of the extension portion of the second RTP message header, and define a message type of the third field as a signature acknowledgement message. In practical applications, taking the ACK identification multiplexing ACK acknowledgement 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".

It should be noted that, the message structure of the second RTP message is not limited to this, and may be determined according to actual situations, and the embodiment of the present invention is not limited herein.

The identity signature information of the second terminal is explained as follows:

the determination of the identity signature information of the second terminal may include the following two implementation forms:

in a first implementation form, the identity signature information of the second terminal is obtained by performing signature operation on a FROM field and a TO field of a session initiation protocol SIP message header, and a Sequence Number and a Timestamp in the first RTP message header.

In specific implementation, the second terminal may perform signature operation on a FROM field and a TO field of an invite message (SIP message) sent TO the first terminal, and a Transmission Control Protocol (TCP) sequence number (hereinafter, referred TO as a sequence number) and a timestamp in a fixed part of an RTP message by using a private key TO obtain identity signature information thereof.

The FROM field of the invitation message (SIP message) comprises the user identification of the second terminal, the second terminal is used as an inviter of the SIP session connection, and the authenticity of the identity of the second terminal can be authenticated by signing the FROM field of the invitation message (SIP message). The TO field of the invitation message (SIP message) comprises the identity of the first terminal, and the second terminal serves as an inviter of the network voice session and signs the TO field of the invitation message (SIP message), so that the identity of the invitee of the network voice session, namely the first terminal, can be ensured not TO be tampered. The second terminal signs the serial number and the time stamp in the RTP message header, so that replay attack can be effectively prevented.

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.

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

determining the user identification of the second terminal according to the FROM field of the SIP message header;

acquiring a block chain certificate corresponding to the user identifier on a public chain;

and under the condition that the public chain certificate corresponding to the user identifier is obtained from the public chain and is valid, performing identity verification on the second terminal according to the public chain certificate corresponding to the user identifier.

In this optional embodiment, the first terminal may verify the identity of the second terminal by using a digital certificate, and perform identity verification based on a public key infrastructure PKI constructed by a public chain to solve the trust problem of the digital certificate.

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

After receiving the first RTP message, the first terminal may determine a user identifier of the second terminal according to a FROM field in a previously received SIP message sent by the second terminal, where the user identifier of the second terminal may be a phone number of the second terminal user or an SIP URI of the second terminal user; then, the first terminal may query, according to the user identifier of the second terminal, a public chain certificate corresponding to the user identifier on the public chain.

The above query will have the following three cases:

in the first case: if the public chain certificate of the user identifier is not inquired on the public chain, the public chain certificate corresponding to the hash value of the user identifier can be inquired on the public chain again by using the hash value of the user identifier. And if the public chain certificate corresponding to the hash value of the user identifier is not inquired on the public chain, the second terminal is proved to have no public chain certificate on the public chain. And the first terminal acquires the query result, and can determine that the identity of the second terminal is in doubt and the identity verification of the second terminal is not passed.

In the second case: if the user identifier or the public chain certificate corresponding to the hash value of the user identifier is inquired on the public chain, whether the public chain certificate is valid or not can be checked. If it is determined that the public chain certificate is invalid, i.e. the public chain certificate exists but is invalid, the authentication of the second terminal is also not passed.

In the third case: if the user identifier or the public chain certificate corresponding to the hash value of the user identifier is inquired on the public chain, whether the public chain certificate is valid or not can be checked. If the public chain certificate is determined to be valid, that is, the public chain certificate exists and is valid, the first terminal obtains the query result, the identity of the second terminal can be determined to be real, and the identity of the second terminal passes authentication.

It should be noted that, in this alternative embodiment, the first field (for indicating the purpose of the extension) of the extension of the first RTP message and the second RTP message may be set to "0X 808A" to inform the first terminal of the current authentication manner. It is to be understood that, in this alternative embodiment, the representation forms of the first RTP message and the second RTP message are not limited thereto, and may be determined according to actual situations, and are not limited herein.

In this optional embodiment, the public key infrastructure PKI constructed based on the public chain performs authentication to solve the trust problem of the digital certificate, and meanwhile, since the public chain certificate uses self-signature instead of third-party signature, the authenticity and reliability of the public chain certificate are ensured by the public chain, the reliability and accuracy of authentication between terminals can be further improved.

It should be noted that, in other alternative embodiments, the trust problem existing in the authentication by using a digital certificate may also be solved based on other ways, which may be determined according to actual situations, and the examples of this application are not limited herein.

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

In specific implementation, the second terminal may perform signature operation on a FROM field and a TO field of an invite message (SIP message) sent TO the first terminal, a Sequence Number and a time Timestamp in a fixed part of the first RTP message header, a key center Name KGC Name in the first RTP message header, a second terminal identification Sequence Number SN of Identity, and a Hash algorithm Name of Hash algorohm used by the user identification revocation list by using a private key TO obtain Identity signature information thereof.

The FROM field of the invitation message (SIP message) comprises the user identification of the second terminal, the second terminal is used as an inviter of the SIP session connection, and the authenticity of the identity of the second terminal can be authenticated by signing the FROM field of the invitation message (SIP message). The TO field of the invitation message (SIP message) comprises the identity of the first terminal, and the second terminal serves as an inviter of the network voice session and signs the TO field of the invitation message (SIP message), so that the identity of the invitee of the network voice session, namely the first terminal, can be ensured not TO be tampered. The second terminal signs the serial number and the time stamp in the RTP message header, so that replay attack can be effectively prevented. The second terminal signs the Name KGC Name of the key center in the first RTP message header, the serial number SN of the Identity of the second terminal, and the Name of the Hash algorithm used by the user identifier revocation list, of Hash Algorothm, so that the authenticity and the integrity of the information can be ensured.

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.

determining the user identification of the second terminal according to the FROM field of the SIP message header; acquiring a key center KGC information block corresponding to the second terminal on a alliance chain according to the key center Name KGC Name and the user identification of the second terminal;

under the condition that a key center KGC information block corresponding to the second terminal is obtained on the alliance chain and is valid, performing identity authentication on the second terminal according to information in the key center KGC information block;

the information in the key center information block comprises a key center public key and a signature verification algorithm.

In this optional embodiment, the first terminal may perform identity authentication on the second terminal based on a key center KGC constructed by the federation chain, and write the KGC information block and the user identifier revocation list into the federation chain through a consensus mechanism of the federation chain, thereby solving the problem of cross-domain transfer of KGC parameters and the problem of trust between multiple domains.

In a specific implementation, after receiving the first RTP message, the first terminal may determine a user identifier of the second terminal according to a FROM field in an SIP message sent by the second terminal, where the user identifier of the second terminal may be a phone number of the second terminal user or an SIP URI of the second terminal user; then, the first terminal may obtain the user identifier and KGCName of the second terminal, which are carried in the first RTP message. The user identifier of the second terminal may be composed of a user identifier and a serial number of the second terminal, and the serial number of the second terminal may be a serial number generated by the key center KGC for the second terminal, so as to manage the second terminal.

The first terminal may query, according to the user identifier and the KGCName of the second terminal, a KGC information block corresponding to the second terminal on the federation chain, where the querying may occur in the following three cases:

in the first case: if the KGC information block corresponding to the second terminal is not queried in the federation chain, it is proved that the second terminal is not uplinked in the federation chain, the first terminal cannot obtain a public key for signature verification and an algorithm for signature verification, the identity of the second terminal is in doubt, and the identity verification of the second terminal fails.

In the second case: if the KGC information block corresponding to the second terminal is queried in the federation chain, it may be checked whether the KGC information block corresponding to the second terminal is valid. And if the KGC information block corresponding to the second terminal is determined to be invalid, the identity authentication of the second terminal is also failed.

In the third case: if the KGC information block corresponding to the second terminal is queried in the federation chain, it may be checked whether the KGC information block corresponding to the second terminal is valid. And if the KGC information block corresponding to the second terminal is determined to be valid, the first terminal acquires the query result, the identity of the second terminal can be determined to be real, and the identity verification of the second terminal is passed.

It should be noted that, in this alternative embodiment, the first field (for indicating the purpose of the extension) of the extension of the first RTP message and the second RTP message may be set to "0X 808B" to inform the first terminal of the current authentication manner.

As shown in fig. 9, the extension portion of the first RTP message may further include a fifth field, where the fifth field is used to indicate the KGC Name, and in practical applications, the fifth field may be represented as a "KGC Name" field; the extended part may further include a sixth field, where the sixth field is used to indicate a sequence number of the second terminal, and in practical applications, the sixth field may be represented as an "SN of Identity" field; the extension part may further include a seventh field, where the seventh field is used to indicate a Hash value of the identity of the second terminal, and in practical applications, the second field may be represented as a "Name of Hash algorithm" field.

It is to be understood that, in this alternative embodiment, the representation forms of the first RTP message and the second RTP message are not limited thereto, and may be determined according to actual situations, and are not limited herein.

Further, optionally, after determining the user identifier of the second terminal according to the FROM field of the SIP message header, before performing identity authentication on the second terminal according to the information in the KGC information block of the key center, the method further includes

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

determining whether a hash value corresponding to the user identifier of the second terminal is stored in the user identifier revocation list according to the hash value corresponding to the user identifier of the second terminal, wherein the hash value corresponding to the revoked user identifier is stored in the user identifier revocation list;

the authentication of the second terminal according to the information in the key center information block includes:

and under the condition that the hash value corresponding to the user identifier of the second terminal is not stored in the user identifier revocation list, performing identity authentication on the second terminal according to the information in the key center KGC information block.

In this optional embodiment, the key center KGC may maintain a user identifier revocation list in which hash values corresponding to revoked user identifiers are stored, and may determine which terminals have been revoked according to the user identifier revocation list, so as to further improve accuracy of the identity authentication.

In a specific implementation, after receiving the first RTP message, the first terminal may calculate a hash value of the user identifier of the second terminal carried in the first RTP message. Then, the first terminal may query, on the basis of the hash value of the user identifier and the key center Name KGC Name, a KGC information block corresponding to the second terminal on a federation chain. When the KGC information block corresponding to the second terminal is found and the KGC information block corresponding to the second terminal is valid, the first terminal further needs to further determine whether the hash value of the user identifier of the second terminal is on the user identifier revocation list.

Under the condition that the following three conditions are all satisfied, the first terminal may perform authentication on the second terminal according to information in the KGC information block corresponding to the second terminal:

1) the alliance chain stores a KGC information block corresponding to the second terminal;

2) the KGC information block corresponding to the second terminal is valid;

3) the subscriber identity of the second terminal is not on the subscriber identity revocation list.

In this optional embodiment, a key center KGC is constructed based on a federation chain to perform identity authentication, and KGC information blocks and a user identifier revocation list are written into the federation chain through a consensus mechanism of the federation chain, so that the problem of KGC parameter cross-domain transmission and the trust problem between multiple regions are solved, and the application range and reliability of identity authentication between terminals are further improved.

It should be noted that, in other alternative embodiments, the problem of cross-domain transfer of KGC parameters and the trust problem between multiple regions, which exist when performing identity authentication based on memory KGC, may also be solved based on other manners, which may be determined according to practical situations, and the embodiments of the present application are not limited herein.

Referring to fig. 10, fig. 10 is a second flowchart illustrating an authentication method according to an embodiment of the present invention, where the authentication method can be executed by a second terminal.

As shown in fig. 10, the authentication method includes the following steps:

1001, sending a first real-time transport protocol message to a first terminal, where the first real-time transport protocol message carries identity signature information of the second terminal;

step 1001, receiving a second real-time transport protocol message sent by the first terminal, where the second real-time transport protocol message carries a confirmation identifier, and the confirmation identifier is used to indicate whether the authentication of the second terminal passes or not.

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.

Optionally, the second real-time transport protocol message includes a second field, and the second field is used to indicate the acknowledgement flag.

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

and performing signature operation on the FROM field and the TO field of the SIP message header, as well as the Sequence Number and the Timestamp in the first RTP message header TO obtain the identity signature information of the second terminal.

and performing signature operation on a FROM field and a TO field of an SIP message header, a Sequence Number and a time Timestamp in a fixed part of the first RTP message header, a key center Name KGC Name in the first RTP message header, a second terminal identification Sequence Number SN of Identity, and a Hash algorithm Name of Hash Algorothm used by a user identification revocation list TO obtain Identity signature information of the second terminal.

It should be noted that, this embodiment is implemented as a second terminal corresponding to the foregoing method embodiment, and therefore, reference may be made to the relevant description in the foregoing method embodiment, and the same beneficial effects may be achieved. To avoid repetition of the description, the description is omitted.

Referring to fig. 11, fig. 11 is a diagram illustrating one of the structures of an authentication apparatus according to an embodiment of the present invention. As shown in fig. 11, the authentication apparatus 1100 includes:

a first receiving module 1101, configured to receive a first real-time transport protocol message sent by a second terminal, where the first real-time transport protocol RTP message carries identity signature information of the second terminal;

a first processing module 1102, configured to perform identity authentication on the second terminal according to the first RTP message;

a first sending module 1103, configured to send a second RTP message to the second terminal, where the second RTP message carries an acknowledgement identifier, and the acknowledgement identifier is used to indicate whether the authentication of the second terminal passes or not.

Optionally, the identity signature information of the second terminal is located in an extension portion of the header of the first RTP message.

Optionally, the acknowledgement identifier is located in an extension of the header of the second RTP message.

Optionally, the identity signature information of the second terminal is obtained by performing signature operation on an FROM field and a TO field of a session initiation protocol SIP message header, and a Sequence Number and a Timestamp in the first RTP message header;

the first processing module 1102 includes:

a first determining unit, configured to determine a user identifier of the second terminal according to a FROM field of the SIP message header;

a first obtaining unit, configured to obtain, on a public chain, a block chain certificate corresponding to the user identifier;

and the first verification unit is used for acquiring the public chain certificate corresponding to the user identifier on the public chain, and performing identity verification on the second terminal according to the public chain certificate corresponding to the user identifier under the condition that the public chain certificate corresponding to the user identifier is valid.

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

the first processing module 1102 includes:

a second determining unit, configured to determine, according to a FROM field of the SIP message header, a user identifier of the second terminal;

a second obtaining unit, configured to obtain, in a federation chain, a key center KGC information block corresponding to the second terminal according to the key center Name KGC Name and the user identifier of the second terminal;

the second verification unit is configured to, when a 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, perform identity verification on the second terminal according to information in the key center KGC information block;

Optionally, the first processing module 1102 further includes:

the calculating unit is used for calculating a hash value corresponding to the user identifier of the second terminal;

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

the second verification unit is specifically configured to:

and under the condition that the hash value corresponding to the user identifier of the second terminal is not stored in the user identifier revocation list, performing identity verification on the second terminal according to the information in the key center KGC information block.

The identity authentication apparatus 1100 can implement each process that can be implemented by the first terminal in the method embodiment of the present invention, and achieve the same beneficial effects, and for avoiding repetition, details are not described here.

Referring to fig. 12, fig. 12 is a second structural diagram of an authentication apparatus according to an embodiment of the present invention. As shown in fig. 12, the authentication apparatus 1200 includes:

Optionally, the identity signature information of the second terminal is located in an extension of the header of the first RTP message.

Optionally, the identity verification apparatus 1200 further includes:

and the first signature module is used for performing signature operation on an FROM field and a TO field of a Session Initiation Protocol (SIP) message header, as well as a Sequence Number and a Timestamp in the first RTP message header TO obtain identity signature information of the second terminal.

Optionally, the identity verification apparatus 1200 further includes:

and the second signature module is used for performing signature operation on an FROM field and a TO field of an SIP message header, a Sequence Number and a time Timestamp in a fixed part of the first RTP message header, a key center Name KGC Name in the first RTP message header, a second terminal identification Sequence Number SN of Identity and a Hash algorithm Name of Hash Algorothm used by a user identification revocation list TO obtain Identity signature information of the second terminal.

The identity authentication apparatus 1200 can implement each process that can be implemented by the second terminal in the method embodiment of the present invention, and achieve the same beneficial effects, and for avoiding repetition, details are not described here again.

The embodiment of the invention also provides the electronic equipment. Referring to fig. 13, the electronic device 1300 may include a processor 1301, a memory 1302, and a computer program 13021 stored in the memory 1302 and capable of running on the processor 1301, where when the computer program 13021 is executed by the processor 1301, any step in the method embodiment corresponding to fig. 5 or fig. 10 may be implemented and the same beneficial effect may be achieved, and details are not described here.

Those skilled in the art will appreciate that all or part of the steps of the method described above can be implemented by hardware associated with program instructions, and the program can be stored in a computer readable medium. An embodiment of the present invention further provides a computer-readable storage medium, where a third computer program is stored on the computer-readable storage medium, and when the third computer program is executed by a fourth processor, any step in the method embodiment corresponding to fig. 5 or fig. 10 may be implemented, and the same technical effect may be achieved, and in order to avoid repetition, details are not repeated here.

The storage medium may be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.

While the foregoing is directed to the preferred embodiment of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. An identity authentication method is applied to a first terminal, and is characterized by comprising the following steps:

2. The method of claim 1, wherein the identity signature information of the second terminal is located in an extension of the header of the first RTP message.

3. The method of claim 1, wherein the acknowledgement identification is located in an extension of a header of the second RTP message.

4. The method of claim 1, wherein the identity signature information of the second terminal is obtained by performing signature operation on a FROM field, a TO field of a Session Initiation Protocol (SIP) message header, and a Sequence Number and a Timestamp in the first RTP message header; the performing identity authentication on the second terminal according to the first real-time transport protocol message includes:

acquiring a block chain certificate corresponding to the user identification on a public chain;

5. The method according to claim 1, wherein the first RTP message further carries a key center Name KGC Name, a second terminal identifier serial number SN of Identity, and a Hash algorithm Name of Hash Algorothm used for a user identifier revocation list; the Identity signature information of the second terminal is obtained by performing signature operation on a FROM field and a TO field of an SIP message header, a serial Number (Sequence Number) and a time Timestamp in a fixed part of the first RTP message header, a key center Name (KGC Name) in the first RTP message header, a serial Number (SN of Identity) of the second terminal, and a Name of a Hash algorithm used by a user Identity revocation list; the performing identity authentication on the second terminal according to the first real-time transport protocol message includes:

6. The method according to claim 5, wherein after said determining the user identity of the second terminal according to the FROM field of the SIP header, and before said authenticating the second terminal according to the information in the KGC information block, further comprising:

7. An identity authentication method applied to a second terminal is characterized by comprising the following steps:

8. The method of claim 7, wherein the identity signature information of the second terminal is located in an extension of the header of the first RTP message.

9. The method of claim 7, wherein the acknowledgement flag is located in an extension of a header of the second RTP message.

10. The method of claim 7, wherein prior to said sending the first real-time transport protocol (RTP) message to the first terminal, the method further comprises:

11. The method of claim 7, wherein prior to said sending the first real-time transport protocol (RTP) message to the first terminal, the method further comprises:

12. An authentication apparatus, comprising:

13. An authentication apparatus, comprising:

14. An electronic device, comprising a processor, a memory and a computer program stored on the memory and executable on the processor, the computer program, when executed by the processor, implementing the steps of the method according to any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 11.