Password authentication key exchange method and device, computer equipment and storage medium

Abstract

The invention discloses a password authentication key exchange method and device, computer equipment and a storage medium, and belongs to the technical field of Internet. In the application, a first account in a login request sent by a first client is an account registered in a first server, and a first PAKE parameter is generated based on a temporary private key of the first client and a first password corresponding to the first account. On the basis, the second server side can generate a second PAKE parameter corresponding to the second server side, and performs identity authentication and key negotiation with the first client side by using a first verification fragment, the second PAKE parameter, the first account and the first PAKE parameter allocated to the second server side by the first server side according to the identifier of the second server side and the password verification information of the first password; and cross-domain password authentication key negotiation is realized. Moreover, due to the key negotiation between the second server and the first client, the third party cannot obtain the finally negotiated key, and the key security is ensured.

Description

Technical Field

[0001] This application relates to the field of Internet technologies, and in particular, to a password authentication key exchange method, apparatus, computer device, and storage medium. Background Art

[0002] Key exchange refers to the process in which two communication parties negotiate a shared session key. Using the negotiated session key, the two communication parties can encrypt the session data to be transmitted to each other, thereby improving the security of communication. During the key exchange process, to ensure that the two communication parties are trustworthy, the two communication parties can perform mutual identity authentication and key negotiation based on the password authenticated key exchange (PAKE) protocol. The so-called PAKE protocol refers to implementing identity authentication and key negotiation using a registered user account and user password. Currently, the PAKE protocol does not support cross-domain scenarios. That is, after a user completes account registration in a first server, the client can only perform identity authentication and key negotiation with the first server based on the PAKE protocol using the registered user account and user password, but cannot perform identity authentication and key negotiation with a second server based on the PAKE protocol using the user account and user password registered in the first server. Summary of the Invention

[0003] This application provides a password authentication key exchange method, apparatus, computer device, and storage medium, which can implement cross-network domain password authentication key exchange and improve the security of the negotiated session key.

[0004] To achieve the above object, this application adopts the following technical solutions:

[0005] In a first aspect, a password authentication key exchange method is provided. The method includes: receiving a login request sent by a first client, where the login request includes a first account and first PAKE parameters, the first PAKE parameters are generated based on a first password corresponding to the first account and a temporary private key of the first client, and the first account and the first password are the account and password registered in a first server; generating second PAKE parameters based on a temporary private key of the second server; performing identity authentication and key negotiation with the first client based on the first account, the first PAKE parameters, the second PAKE parameters, and a first verification shard stored in the second server, where the first verification shard is allocated by the first server for the second server based on an identifier of the second server and password verification information of the first account.

[0006] In this application, the first account in the login request sent by the first client is an account registered in the first server, and the first PAKE parameter in the login request is generated based on the temporary private key of the first client and the first password corresponding to the first account. On this basis, the second server can generate its corresponding second PAKE parameter, and use the first verification shard allocated by the first server for the second server according to the identification of the second server and the password verification information of the first password, its corresponding second PAKE parameter, the first account, and the first PAKE parameter to perform identity authentication and key negotiation with the first client. That is, the first client can log in to the second server through the account and password registered in the first server, and use the PAKE protocol to perform identity authentication and key negotiation with the second server, realizing cross-domain password authentication key negotiation. Moreover, since the key negotiation is performed between the second server and the first client, a third party including the first server cannot obtain the finally negotiated key between the first client and the second server, ensuring the security of the negotiated key, thereby improving the security of communication.

[0007] Optionally, the password verification information includes the public key corresponding to the second private key. The implementation process of performing identity authentication and key negotiation with the first client based on the first account, the first PAKE parameter, the second PAKE parameter, and the first verification shard stored in the second server may include: sending an authentication assistance request to the first server, where the authentication assistance request includes the first account, the identification of the second server, the client PAKE parameter to be processed, and the second PAKE parameter, and the client PAKE parameter to be processed is obtained based on the first PAKE parameter; receiving the first assistance information sent by the first server, where the first assistance information is obtained based on the password verification information, the identification of the second server, the client PAKE parameter to be processed, and the second PAKE parameter, and the first assistance information includes the first processed client PAKE parameter, the first processed server PAKE parameter, and the public key information, and the public key information is obtained based on the public key corresponding to the second private key; performing identity authentication and key negotiation with the first client based on the first assistance information and the first verification shard.

[0008] In this application, the first verification shard allocated by the first server for the second server may contain partial information in the password verification information of the first account. On this basis, the second server can realize password authentication key exchange with the first client with the assistance of the complete password verification information stored in the first server. Since the first verification shard allocated by the first server to the second server only contains partial information in the password verification information, the security of the password verification information of the first account can be better guaranteed.

[0009] Optionally, the implementation process of performing identity authentication and key negotiation with the first client based on the first auxiliary information and the first verification shard may include: obtaining a second processing server PAKE parameter based on the first processing server PAKE parameter; generating a server session key and a server MAC key based on the first auxiliary information, the second processing server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter; generating a first MAC based on the server MAC key and the first PAKE parameter; and sending the first MAC and second auxiliary information to the first client, where the second auxiliary information includes the identifier of the second server and the second processing server PAKE parameter.

[0010] Optionally, the password verification information further includes a first private key, and the first verification shard is obtained based on the identifier of the second server and the first private key; the method further includes: generating a third PAKE parameter based on the first verification shard and the first PAKE parameter; where the client PAKE parameter to be processed is the third PAKE parameter, the first processing client PAKE parameter and the first processing server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter respectively based on a second verification shard of the password verification information, the second verification shard is generated based on the first private key and the identifier of the second server, and the second verification shard is different from the first verification shard.

[0011] In this application, when both the first verification shard and the second verification shard are obtained based on the identifier of the second server and the first private key and the second verification shard is different from the first verification shard, the sum of the first verification shard and the second verification shard modulo p is equal to the first private key, where p is the order of the preset group G. On this basis, the second server can process the first PAKE parameter using the first verification shard to obtain the client PAKE parameter to be processed. After receiving the client PAKE parameter to be processed, the first server uses the second verification shard to process the client PAKE parameter to be processed to obtain the first processing client PAKE parameter. In this way, the first processing client PAKE parameter will contain the information of the complete first private key.

[0012] Optionally, the implementation process of generating the third PAKE parameter based on the first verification shard and the first PAKE parameter may specifically include: processing the first PAKE parameter based on the first verification shard and the first blinding factor to obtain the third PAKE parameter, and generating a first blinding value based on the first blinding factor; wherein, the authentication assistance request further includes the first blinding value, and the first processed client PAKE parameter is obtained by processing the third PAKE parameter based on the second verification shard and the first blinding value.

[0013] In the present application, the first PAKE parameter is processed by the first blinding factor and the first verification shard. In this way, even if X0 and X1 are obtained by a third party during transmission, the third party cannot obtain the information item w00*M containing the first verification shard through X1 and X0. In this way, the third party cannot impersonate the second server to perform identity authentication and key negotiation with the first client, ensuring the security of identity authentication and key negotiation between the second server and the first client.

[0014] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on a second blinding factor, and the first processed client PAKE parameter and the first processed server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter respectively based on the second verification shard and the second blinding factor.

[0015] In the present application, the first server can transmit the public key corresponding to the second private key included in the password verification information to the second server after blinding processing, so that the public key corresponding to the second private key can be prevented from being leaked during transmission, thereby ensuring the security of the password verification information. In addition, the third PAKE parameter and the second PAKE parameter are processed by the second verification shard and the second blinding factor to obtain the first processed client PAKE parameter and the first processed server PAKE parameter, so that the information item containing the second verification shard can be prevented from being leaked during the subsequent transmission of the first processed client PAKE parameter and the first processed server PAKE parameter, thereby ensuring the security of identity authentication and key negotiation between the second server and the first client.

[0016] Optionally, the implementation process of obtaining the second processed server PAKE parameter based on the first processed server PAKE parameter may include: processing the first processed server PAKE parameter based on the first verification shard and a third blinding factor to obtain the second processed server PAKE parameter, and generating a second blinding value based on the third blinding factor, wherein the second auxiliary information further includes the second blinding value.

[0017] In this application, after the second server obtains the PAKE parameter of the first processing server, it can further process the PAKE parameter of the first processing server through the first verification shard and the third blinding factor. After that, the PAKE parameter of the second processing server obtained through blinding processing is sent to the first client. In this way, it is possible to avoid the leakage of the information item of the first verification shard contained in the process of transmitting the PAKE parameter of the second processing server, thereby ensuring the security of the password verification information.

[0018] Optionally, the implementation process of generating the server session key and the server MAC key based on the first auxiliary information, the PAKE parameter of the second processing server, the temporary private key of the second server, the first verification shard, and the first PAKE parameter may include: generating the server secret information based on the third blinding factor, the PAKE parameter of the first processing client, the public key information, and the temporary private key of the second server; generating the server session key and the server MAC key based on the server secret information, the PAKE parameter of the second processing server, the first verification shard, and the first PAKE parameter.

[0019] Optionally, the password verification information further includes a first private key. The first verification shard is obtained based on the public key corresponding to the second private key and the identifier of the second server. The client PAKE parameter to be processed is the first PAKE parameter. The PAKE parameter of the first processing client and the PAKE parameter of the first processing server are obtained by processing the first PAKE parameter and the second PAKE parameter respectively based on the first private key.

[0020] In this application, when the first verification shard is obtained based on the public key corresponding to the second private key and the identifier of the second server, the first server can use the first private key to process the client PAKE parameter to be processed and the second PAKE parameter, so that the first auxiliary information returned to the second server can implicitly contain the complete password verification information.

[0021] Optionally, the implementation process of generating the second PAKE parameter based on the temporary private key of the second server may include: generating the second PAKE parameter based on the temporary private key of the second server and the first verification shard; wherein, the PAKE parameter of the first processing server is obtained by processing the second PAKE parameter based on the first private key and the second verification shard, and the second verification shard is the same as the first verification shard.

[0022] In this implementation, the first verification shard and the second verification shard can be the same. Since the second PAKE parameter contains the information of the first verification shard, after receiving the second PAKE parameter, the first server can use the second verification shard to offset the first verification shard in the second PAKE parameter and implicitly hide the first private key in the second PAKE parameter.

[0023] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on the second blinding factor. The first processed client PAKE parameter is obtained by processing the first PAKE parameter based on the first private key and the second blinding factor. The first processed server PAKE parameter is obtained by processing the second PAKE parameter based on the first private key, the second blinding factor, and the second verification shard.

[0024] In this application, the first server can blind the public key corresponding to the second private key included in the password verification information and then transmit it to the second server. In this way, the public key corresponding to the second private key can be prevented from being leaked during the transmission process, thus ensuring the security of the password verification information. On this basis, in order to negotiate the correct key, the second blinding factor can be used to process the client PAKE parameter to be processed and the second PAKE parameter.

[0025] Optionally, the implementation process of generating the server session key and the server MAC key based on the first auxiliary information, the second processed server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter may include: generating the server secret information based on the first processed client PAKE parameter, the public key information, and the temporary private key of the second server; generating the server session key and the server MAC key based on the server secret information, the first verification shard, the second processed server PAKE parameter, and the first PAKE parameter.

[0026] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on a second blinding factor and a second verification shard. The second verification shard is obtained based on the public key corresponding to the second private key and the identifier of the second server, and the second verification shard is different from the first verification shard. The implementation process of generating a server session key and a server MAC key based on the first auxiliary information, the second processing server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter may include: generating the server secret information based on the first verification shard, the first processing client PAKE parameter, the public key information, and the temporary private key of the second server; generating the server session key and the server MAC key based on the server secret information, the second processing server PAKE parameter, the first verification shard, and the first PAKE parameter.

[0027] In this implementation manner, the first verification shard is different from the second verification shard. For example, the first verification shard may be the multiplicative inverse of the second verification shard modulo p. Since the public key information is obtained using the second verification shard, when calculating the server secret information, the first verification shard can also be used while using the public key information, so that the second server can perform authentication and key negotiation using the complete public key corresponding to the second private key.

[0028] Optionally, both the first auxiliary information and the second auxiliary information include a random salt value provided by the first server, and the second private key is generated based on the random salt value and the first password.

[0029] In this application, the second private key is calculated based on the first password and the random salt value provided by the first server, and the first client can calculate the second private key by the method of sending the random salt value to the first client. This implementation manner can be compatible with the traditional password authentication method that obtains the second private key in the same way, thereby improving the applicability of the password authentication key exchange method provided by the embodiments of this application.

[0030] Optionally, the method further includes: receiving a second MAC sent by the first client. The second MAC is generated by the first client based on the client MAC key and the second processing server PAKE parameter after passing the identity authentication of the second server based on the first MAC. The client MAC key is generated based on the second auxiliary information, the temporary private key of the first client, the password verification information, and the first PAKE parameter; generating a third MAC based on the server MAC key and the second processing server PAKE parameter; performing identity authentication on the first client based on the second MAC and the third MAC.

[0031] Optionally, the method further includes: receiving a federated registration request sent by the first client, where the federated registration request includes the first account number and a fourth PAKE parameter, and the fourth PAKE parameter is generated based on the first password and a temporary private key of the first client; sending the federated registration request and an identifier of the second server to the first server, where the first server is used to perform identity authentication with the first client based on the first account number and the fourth PAKE parameter; receiving and storing the first account number and the first verification shard sent by the first server after the identity authentication between the first server and the first client is passed; and sending a registration success response to the first client.

[0032] In this application, a user can use the first account number and the first password already registered in the first server to perform federated registration in the second server. In this way, the user can use the first account number and the first password to log in to the second server. Compared with the user registering a new account number in the second server, the registration operation is simplified, and the number of account numbers and passwords that the user needs to remember is reduced. In addition, the first verification shard sent by the first server is generated using the identifier of the second server, that is, the first verification shard contains the identity information of the second server, ensuring that the first verification shards of different second servers are different. When logging in to the second server and performing password authentication and key negotiation with the second server subsequently, the risk of the second server being impersonated can be reduced.

[0033] In a second aspect, a password authentication key exchange method is provided. The method includes: in response to a login instruction, obtaining a first account number and a first password input by a user, where the first account number and the first password are the account number and password registered in the first server; generating a first PAKE parameter based on the first password and a temporary private key of the first client; and performing identity authentication and key negotiation with a second server based on the first account number and the first PAKE parameter.

[0034] Optionally, the implementation method of performing identity authentication and key negotiation with the second server based on the first account and the first PAKE parameter may include the following steps: sending a login request to the second server, where the login request includes the first account and the first PAKE parameter; receiving a first MAC and second auxiliary information sent by the second server, where the second auxiliary information includes an identifier of the second server and a second processing server PAKE parameter, the first MAC is generated based on a server MAC key and the first PAKE parameter, and the server MAC key is generated based on first auxiliary information, the second processing server PAKE parameter, a temporary private key of the second server, a first check fragment of a password verification information of the first account, and the first PAKE parameter; generating a client session key and a client MAC key based on the second auxiliary information, the password verification information of the first account, a temporary private key of the first client, and the first PAKE parameter; generating a fourth MAC based on the client MAC key and the first PAKE parameter; and performing identity authentication on the second server based on the first MAC and the fourth MAC.

[0035] Optionally, the method further includes: after the identity authentication of the second server passes, generating a second MAC based on the client MAC key and the second processing server PAKE parameter; and sending the second MAC to the second server.

[0036] Optionally, the method further includes: in response to a registration instruction, obtaining the first account and the first password input by the user; generating a fourth PAKE parameter based on the first password and a temporary private key of the first client; sending a federated registration request to the first server through the second server, where the federated registration request includes the first account and the fourth PAKE parameter, and the first account and the fourth PAKE parameter are used for identity authentication with the first server; and after passing the authentication with the first server, receiving a registration success response sent by the second server.

[0037] The beneficial effects corresponding to the various implementation methods included in the password authentication key verification method provided in the second aspect above may refer to the beneficial effects corresponding to the corresponding implementation methods in the first aspect, and will not be elaborated here.

[0038] In a third aspect, a password authentication key exchange method is provided. The method includes: receiving an authentication assistance request sent by a second server, where the authentication assistance request includes a first account, an identifier of the second server, client PAKE parameters to be processed, and second PAKE parameters provided by the second server. The first account is an account registered in a first server, and the client PAKE parameters to be processed are obtained based on first PAKE parameters provided by a first client; obtaining first assistance information based on password verification information of the first account, the identifier of the second server, the client PAKE parameters to be processed, and the second PAKE parameters. The first assistance information includes first processed client PAKE parameters, first processed server PAKE parameters, and public key information, and the public key information is obtained based on the public key corresponding to a second private key in the password verification information; sending the first assistance information to the second server, where the second server is configured to perform identity authentication and key negotiation with the first client based on the first assistance information and a first verification shard, and the first verification shard is allocated to the second server based on the identifier of the second server and the password verification information.

[0039] Optionally, the implementation process of obtaining the first assistance information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameters to be processed, and the second PAKE parameters may include: generating a second verification shard based on the password verification information and the identifier of the second server; obtaining the first assistance information based on the password verification information, the second verification shard, the client PAKE parameters to be processed, and the second PAKE parameters.

[0040] Optionally, the password verification information further includes a first private key. Both the first verification shard and the second verification shard are generated based on the identifier of the second server and the first private key, and the second verification shard is different from the first verification shard. The implementation process of obtaining the first assistance information based on the password verification information, the second verification shard, the client PAKE parameters to be processed, and the second PAKE parameters may include: processing the client PAKE parameters to be processed and the second PAKE parameters respectively based on the second verification shard and a second blinding factor to obtain the first processed client PAKE parameters and the first processed server PAKE parameters; generating the public key information based on the public key corresponding to the second private key and the second blinding factor.

[0041] Optionally, both the first verification shard and the second verification shard are generated based on the identifier of the second server and the public key corresponding to the second private key.

[0042] Optionally, the password verification information further includes a first private key, and the second verification shard is different from the first verification shard. The implementation process of obtaining the first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter may include: respectively processing the client PAKE parameter to be processed and the second PAKE parameter based on the first private key and the second blinding factor to obtain the first processed client PAKE parameter and the first processed server PAKE parameter; generating the public key information based on the second blinding factor, the second verification shard, and the public key corresponding to the second private key.

[0043] Optionally, the second verification shard is the same as the first verification shard. The implementation process of obtaining the first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter may include: processing the client PAKE parameter to be processed based on the first private key and the second blinding factor to obtain the first processed client PAKE parameter; processing the second PAKE parameter based on the first private key, the second verification shard, and the second blinding factor to obtain the first processed server PAKE parameter; generating the public key information based on the public key corresponding to the second private key and the second blinding factor.

[0044] Among them, the beneficial effects corresponding to the various implementation manners included in the password authentication key verification method provided in the third aspect may refer to the beneficial effects corresponding to the corresponding implementation manners in the first aspect, and will not be elaborated here.

[0045] In a fourth aspect, a password authentication key exchange device is provided. The password authentication key exchange device includes at least one module, and the at least one module is configured to execute the password authentication key exchange method described in the first aspect or the second aspect or the third aspect above.

[0046] In a fifth aspect, a computer device is provided. The computer device includes a processor, and the processor is configured to execute at least one program instruction or code stored in a memory to implement the password authentication key exchange method described in the first aspect or the second aspect or the third aspect above.

[0047] In a sixth aspect, a computer-readable storage medium is provided. Instructions are stored in the computer-readable storage medium, and when the instructions are run on a computer device, the computer device is caused to execute the password authentication key exchange method described in the first aspect or the second aspect or the third aspect above.

[0048] In a seventh aspect, a computer program product including instructions is provided. When the computer program product runs on a computer device, the computer device is caused to execute the password authentication key exchange method described in the first aspect, the second aspect, or the third aspect above.

[0049] The technical effects obtained in the fourth aspect, the fifth aspect, the sixth aspect, and the seventh aspect above are similar to the technical effects obtained by the corresponding technical means in the first aspect, the second aspect, and the third aspect, and will not be elaborated here.

[0050] In an embodiment of the present application, the first account in the login request sent by the first client is an account registered in the first server, and the first PAKE parameter in the login request is generated based on the temporary private key of the first client and the first password corresponding to the first account. On this basis, the second server can generate its own corresponding second PAKE parameter, and use the first verification shard allocated to the second server by the first server according to the identification of the second server and the password verification information of the first password, its own corresponding second PAKE parameter, the first account, and the first PAKE parameter to perform identity authentication and key negotiation with the first client. That is, the first client can log in to the second server through the account and password registered in the first server, and use the PAKE protocol to perform identity authentication and key negotiation with the second server, realizing cross-domain password authentication key negotiation. Moreover, since the key negotiation is performed between the second server and the first client, a third party including the first server cannot obtain the finally negotiated key between the first client and the second server, ensuring the security of the negotiated key, thereby improving the security of communication. Description of the Drawings

[0051] Figure 1 It is a schematic diagram of a password authentication key exchange system provided by an embodiment of the present application;

[0052] Figure 2 It is a schematic diagram of the structure of a computer device provided by an embodiment of the present application;

[0053] Figure 3 It is a flowchart of federated registration of the first account in the second server provided by an embodiment of the present application;

[0054] Figure 4 It is a flowchart of another federated registration of the first account in the second server provided by an embodiment of the present application;

[0055] Figure 5 It is a flowchart of another federated registration of the first account in the second server provided by an embodiment of the present application;

[0056] Figure 6Flowchart of a method for a first client to perform password authentication key exchange with a second server using a first account and a first password provided by an embodiment of the present application;

[0057] Figure 7 Another flowchart of a method for a first client to perform password authentication key exchange with a second server using a first account and a first password provided by an embodiment of the present application;

[0058] Figure 8 Flowchart of a method for a first client, a second server, and a first server to interact to achieve password authentication key exchange provided by an embodiment of the present application;

[0059] Figure 9 Another flowchart of a method for a first client, a second server, and a first server to interact to achieve password authentication key exchange provided by an embodiment of the present application;

[0060] Figure 10 Another flowchart of a method for a first client, a second server, and a first server to interact to achieve password authentication key exchange provided by an embodiment of the present application;

[0061] Figure 11 Another flowchart of a method for a first client, a second server, and a first server to interact to achieve password authentication key exchange provided by an embodiment of the present application;

[0062] Figure 12 Another flowchart of a method for a first client, a second server, and a first server to interact to achieve password authentication key exchange provided by an embodiment of the present application;

[0063] Figure 13 Structural schematic diagram of a password authentication key exchange device provided by an embodiment of the present application;

[0064] Figure 14 Another structural schematic diagram of a password authentication key exchange device provided by an embodiment of the present application;

[0065] Figure 15 Another structural schematic diagram of a password authentication key exchange device provided by an embodiment of the present application. Detailed implementation manners

[0066] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0067] Before explaining the embodiments of the present application in detail, the application scenarios involved in the embodiments of the present application will be introduced first.

[0068] Key exchange refers to the process by which two communicating parties negotiate a shared session key. Using the negotiated session key, the two communicating parties can encrypt the session data to be transmitted to each other, thereby improving the security of communication. However, the key exchange protocol itself cannot authenticate the identities of the two communicating parties, so there may be security threats posed by man-in-the-middle attacks. In practical applications, identity authentication is usually combined with key exchange, that is, during the key exchange process, the two communicating parties can authenticate each other's identities to ensure the authenticity of both parties. Currently, there are two common identity authentication methods during the key exchange process. One is to implement identity authentication based on the public key infrastructure (PKI), and the other is to implement identity authentication based on user passwords. Among them, the method of implementing identity authentication based on PKI involves complex digital certificate management, and its security depends on a trusted third party, presenting certain security risks. The password-based authentication method does not require PKI and has advantages such as small data volume and fast authentication speed. Therefore, in scenarios where digital certificates are not available, the method of performing identity authentication and key negotiation based on the PAKE protocol is widely used.

[0069] In the current PAKE protocol, the user can first register a first account and a first password in the first server through the client. After the registration is completed, subsequently, when the user wants to log in to the first server, the user can enter the first account and the first password in the client. After receiving the first account and the first password, the client can use the PAKE protocol to mutually authenticate with the first server based on the first account and the first password, and perform key negotiation. After successful authentication, the client and the first server can communicate using the negotiated session key.

[0070] It should be noted that since the first account and the first password are registered in the first server, that is, the registration information corresponding to the first account and the first password is stored in the first server. Therefore, in the current PAKE protocol, the client can only perform identity authentication and key negotiation with the first server by using the first account and the first password. However, various application services are emerging in an endless stream currently. Based on the current PAKE protocol, users need to register different accounts and passwords in different servers to implement password-authenticated key exchange, so as to obtain corresponding services. And for each registration operation, the user has to input a large amount of personal information, the operation is cumbersome, and the user has to remember the accounts registered in different servers and the corresponding passwords, which is prone to problems such as confusion or even forgetting of the accounts and passwords. Based on this, the user may want to use the first account and the first password registered in the first server to log in to the second server that belongs to a different domain from the first server. In this case, how to implement secure cross-domain password-authenticated key exchange is an urgent problem to be solved. Based on this, the embodiments of the present application provide a key exchange method for implementing cross-domain password-authenticated key negotiation. And, in the embodiments of the present application, when the first client logs in to the second server by using the first account and the first password registered in the first server, the second server negotiates a key with the first client. Therefore, a third party including the first server cannot obtain the key finally negotiated between the first client and the second server, which ensures the security of the negotiated session key, thereby improving the security of communication.

[0071] Next, the system architecture involved in the password-authenticated key exchange method provided by the embodiments of the present application will be introduced.

[0072] Figure 1 It is a schematic structural diagram of a password-authenticated key exchange system provided by the embodiments of the present application. As Figure 1 shown, the key exchange system includes a first server 101, a second server 102, and a first client 103. Among them, a communication connection is established between the first server 101 and the second server 102, and a communication connection is established between the second server 102 and the first client 103.

[0073] In the embodiments of the present application, the first client 103 can be a general client, such as a browser, or it can also be a client corresponding to the second server 102. For example, it can be an application client corresponding to the second server 102. And, the first server 101 and the second server 102 belong to different domains. Among them, different domains may mean that the first server 101 and the second server 102 belong to different networks or different computer groups. For example, the domain names of the first server 101 and the second server 102 may be different.

[0074] A user can register a first account and a first password in the first server 101 in advance through the client corresponding to the first server 101. After the registration is completed, if the user wants to use the first account and the first password to log in to the second server 102, the first server 101 can allocate a first verification shard for the second server 102 based on the password verification information of the first account and the identifier of the second server 102. Then, when the user logs in to the second server 102, the first account and the first password can be entered in the first client 103, and the first client 103 can generate a first PAKE parameter based on the first password and the temporary private key of the first client. Then, a login request including the first account and the first PAKE parameter is sent to the second server 102.

[0075] After receiving the login request sent by the first client 103, the second server 102 can generate its corresponding second PAKE parameter. Then, based on the first account, the first PAKE parameter, the second PAKE parameter, and the first verification shard allocated by the first server 101 for it, it performs identity authentication and key negotiation with the first client 103.

[0076] It should be noted that in the embodiments of the present application, both the first server 101 and the second server 102 are used to provide application services. In a possible scenario, the first server 101 can be an identity provider (IDP), which is specifically used to create, maintain, and manage user identity information, and provide auxiliary information for identity authentication to a relying party (RP) in a federation or distributed network. The second server 102 can be an RP, which relies on the auxiliary information provided by the IDP to perform identity authentication and key negotiation on the user, and perform data transmission with the client based on the negotiated key after the identity authentication is passed, so as to provide application services for the user.

[0077] In addition, in the embodiments of the present application, the server and the client can refer to software devices deployed in hardware devices, or can also refer to hardware devices capable of implementing corresponding functions. For example, a chip system or a computer device such as a server or a server cluster used to implement the functions of the server can be called a server, and a chip system or a computer device such as a terminal used to implement the functions of the client can be called a client. Or, an application software used to implement the functions of the server can be called a server, and an application software used to implement the functions of the client can be called a client. Figure 1 The first server and the second server are exemplified by servers, and the first client is exemplified by a terminal, but this does not limit the first server, the second server, and the first client.

[0078] It is also worth noting that the client and server are named after the functions implemented by the corresponding devices, that is, the party providing the service can be called the server, and the party receiving the service can be called the client. Based on this, in some scenarios, the client can also become the server of other service recipients, and the server can also accept the services of other servers and become the client, that is, the roles of the client and the server are not absolute. Therefore, the client and the server involved in the embodiments of the present application are named based on the roles of the parties in the key exchange method of the embodiments of the present application, and do not constitute a limitation on the corresponding devices that implement the functions of the client or the server.

[0079] Figure 2 The client or server involved in the embodiment of the present application can be deployed on Figure 2 On the computer device shown, or, the client and server involved in the embodiment of the present application can be Figure 2 The computer device shown is implemented. Figure 2 As shown, the computer device may include at least one processor 201, a communication bus 202, a memory 203, and at least one communication interface 204. It should be noted that: Figure 2 The device structure shown does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently, which is not limited in the embodiments of the present application. Figure 2 A detailed introduction to the various components of computer equipment:

[0080] The processor 201 is the control center of the computer device, which can be a processor or a general term for multiple processing elements. For example, the processor 201 can be a general-purpose central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application, such as: one or more microprocessors (digital signal processors, DSP), or, one or more field programmable gate arrays (FPGA). Among them, the processor 201 can perform various functions of the computer device by running or executing software programs stored in the memory 203, and calling data stored in the memory 203. For example, the actions of the client or server in each embodiment described below can be executed by the processor of the computer device calling the data in the memory.

[0081] As an example, the processor 201 may include one or more CPUs, such as Figure 2 CPU0 and CPU1 shown in

[0082] As an example, a computer device may include multiple processors, such as Figure 2 the processor 201 and the processor 205 shown in . Each of these processors may be a single-CPU processor or a multi-CPU processor. The processors here may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0083] The communication bus 202 may include a path for transmitting information among the above components. The communication bus 202 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 2 only a thick line is shown in , but it does not mean that there is only one bus or one type of bus.

[0084] The memory 203 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), or other types of dynamic storage devices that can store information and instructions. It may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 203 may exist independently and be connected to the processor 201 through the communication bus 202. The memory 203 may also be integrated with the processor 201. Among them, the memory 203 is used to store the software program for implementing the solution provided in the embodiments of the present application and is controlled by the processor 201 for execution.

[0085] A communication interface 204 for communicating with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc. The communication interface 204 may include a receiving unit to implement the receiving function and a transmitting unit to implement the transmitting function.

[0086] As an embodiment, the computer device may further include an output device 206 and an input device 207. The output device 206 communicates with the processor 201 and can display information in various ways. For example, the output device 206 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 207 communicates with the processor 201 and can receive inputs in various ways. For example, the input device 207 may be a mouse, a keyboard, a touch screen device, or a sensing device, etc.

[0087] The above computer device may be a general-purpose computer device or a special-purpose computer device. For example, it may be a desktop computer, a laptop computer, a network server, etc., and the embodiments of the present application do not limit this.

[0088] Next, a detailed explanation of the password authentication key exchange method provided by the embodiments of the present application will be given.

[0089] In the embodiments of the present application, the user can pre-register a first account and a first password in the first server through the client corresponding to the first server. In this way, the first server will store the first account and the password verification information of the first account. In the embodiments of the present application, there are two different implementation manners for the password verification information of the first account stored in the first server.

[0090] In the first implementation manner, the password verification information of the first account may include a first private key and a public key corresponding to a second private key. Among them, the first private key and the second private key can be calculated through the following formula 1 by using a password-based key derivation function (PBKDF), and the public key corresponding to the second private key can be calculated through the following formula 2.

[0091] w0 || w1 = PBKDF(pw, idC || idS1) (1)

[0092] L = w1*P (2)

[0093] Wherein, w0 is the first private key in the password verification information, w1 is the second private key in the password verification information, pw is the first password, idC is the first account number, idS1 is the identifier of the first server, || represents concatenating the two strings before and after, P is the generator of the specified group G, and L is the public key corresponding to the second private key. Among them, the group G can be an elliptic curve group or a finite field group.

[0094] It can be seen from the above formula 1 that the string generated by PBKDF is the concatenated string of the first private key and the second private key. Based on this, this string can be divided into two parts, one part is the first private key, and the other part is the second private key. For example, if a 256-bit string is generated, the high 128 bits can be used as the first private key, and the low 128 bits can be used as the second private key.

[0095] In the second implementation manner, the password verification information of the first account can include the first private key, the public key corresponding to the second private key, and a random salt value. Among them, the first private key can be calculated by the following formula 3, the second private key can be calculated by the following formula 4, and the public key corresponding to the second private key can be calculated by the above formula 2. The salt in the following formula 4 is the random salt value.

[0096] w0 = PBKDF(pw, idC || idS1) (3)

[0097] w1 = PBKDF(pw, salt) (4)

[0098] Based on the above introduction, subsequently, if the user wants to use the first account and the first password to log in to the second server, that is, if cross-domain password authentication key exchange is to be realized, the user can use the first account and the first password to perform federated registration in the second server, and the first server will send the first verification shard to the second server based on the password verification information of the first account stored in itself. In this way, subsequently, after the second server receives the login request carried by the first client with the first account, it can use this first verification shard to perform identity authentication and key negotiation with the first client. Based on this, the process of the user performing federated registration in the second server using the first account and the first password is introduced first in the embodiments of the present application. See Figure 3 , this process includes the following steps:

[0099] Step 301: In response to the registration instruction, the first client obtains the first account number and the first password input by the user.

[0100] In an embodiment of the present application, a user can select a federal registration option on the display page of the first client. In response to the selection instruction for this federal registration option, the first client can display a federal registration page. The user can enter a first account number and a first password on this federal registration page and perform a confirmation operation to trigger a registration instruction. In response to the user's registration instruction, the first client can obtain the first account number and the first password entered by the user.

[0101] Among them, the first account number and the first password are the account number and password that have been registered in the first server.

[0102] In addition, the federal registration option on the display page of the first client can be a general federal registration option. In this case, the first account number can include indication information capable of indicating the identifier of the first server. In this way, after the first client obtains the first account number, it can also obtain the identifier of the first server based on the indication information included in the first account number. For example, the first account number can be an email account number that has been registered in the first server, and the sub-domain name of this email account number can be used as the indication information indicating the identifier of the first server.

[0103] Alternatively, the federal registration option can include an identifier related to the server that supports cross-domain password authentication key exchange. For example, the federal registration option can include the identifier of the client corresponding to the first server or the identifier of the first server. The user can trigger federal registration by selecting the identifier related to the first server. In this way, the first client can obtain the identifier of the first server based on the identifier related to the first server selected by the user.

[0104] Step 302: The first client generates a fourth PAKE parameter based on the first password and the temporary private key of the first client.

[0105] According to the two implementation manners of the password verification information of the first account number stored in the first server introduced above, this step can also have two different implementation manners.

[0106] Manner 1: If the password verification information of the first account number stored in the first server adopts the first implementation manner introduced above, the first client can generate a first private key and a second private key based on the first password, the first account number, and the identifier of the first server by using the foregoing formula 1. After that, the first client can generate a fourth PAKE parameter based on the first private key and the temporary private key of the first client. Among them, this fourth PAKE parameter is used for identity authentication with the first server.

[0107] Exemplarily, the first client can generate a fourth PAKE parameter through the following formula 5 based on the first private key and the temporary private key of the first client.

[0108] X = x0*P + w0*M (5)

[0109] Wherein, X is the fourth PAKE parameter, x0 is the temporary private key of the first client, P is the generator of the specified group G, w0 is the first private key, and M is a random element in the pre-specified group G. It should be noted that the temporary private key of the first client can be a string randomly generated by the first client.

[0110] Method 2: If the password verification information of the first account stored in the first server adopts the second implementation method introduced above, the first client can generate the first private key based on the first password, the first account, and the identifier of the first server using the foregoing formula 3. After that, the first client can generate the fourth PAKE parameter based on the first private key and the temporary private key of the first client with reference to the method of the foregoing Method 1.

[0111] Step 303: The first client sends a federated registration request to the second server, and the federated registration request includes the first account and the fourth PAKE parameter.

[0112] After generating the fourth PAKE parameter, the first client can send a federated registration request to the second server, and the federated registration request includes the first account and the fourth PAKE parameter, which is used to request to register the first account in the second server.

[0113] Step 304: The second server sends the federated registration request and the identifier of the second server to the first server.

[0114] After receiving the federated registration request sent by the first client, the second server can send the federated registration request and its own identifier to the first server together, so as to request the first server to authenticate the first client.

[0115] Optionally, this step can also be replaced by the second server adding its own identifier to the federated registration request and then sending the federated registration request to the first server.

[0116] Step 305: The first server authenticates the first client using the PAKE protocol based on the first account and the fourth PAKE parameter.

[0117] In the embodiment of the present application, since the first account and the first password have been registered in the first server, the first server stores the password verification information of the first account in advance. Based on this, the first server can use the pre-stored password verification information of the first account and the fourth PAKE parameter to authenticate the first client using the PAKE protocol.

[0118] In the first possible case, the password verification information of the first account stored in the first server adopts the first implementation method introduced above. In this case, after receiving the federated registration request, the first server can obtain the public keys corresponding to the first private key and the second private key according to the first account carried in the federated registration request. Then, based on the first private key and the temporary private key of the first server, the fifth PAKE parameter is generated. Based on the public key corresponding to the second private key, the first private key, the temporary private key of the first server, the fourth PAKE parameter, and the fifth PAKE parameter, the fifth MAC is generated. Then, the fifth MAC and the fifth PAKE parameter are transparently transmitted to the first client through the second server.

[0119] Exemplarily, the first server can calculate the fifth PAKE parameter through the following formula 6.

[0120] Y = y0*P+w0*N (6)

[0121] Where Y is the fifth PAKE parameter, y0 is the temporary private key of the first server, and N is a random element different from M in the pre-specified group G. And when the group G is an elliptic curve group, N can be the identity element of the group G, that is, the infinite point. Of course, it can also be other elements in the group G. This application embodiment does not make a limit on this.

[0122] In addition, the first server can calculate the secret information of the first server based on the public key corresponding to the second private key, the first private key, the temporary private key of the first server, and the fourth PAKE parameter. Then, based on the secret information of the first server, the session key and the MAC key of the first server are generated. Then, based on the MAC key of the first server and the fourth PAKE parameter, the fifth MAC is generated.

[0123] As an example, the first server can calculate the first secret information Z1 of the first server through the following formula 7 based on the first private key, the temporary private key of the first server, and the fourth PAKE parameter, and calculate the second secret information V1 of the first server through the following formula 8 based on the temporary private key of the first server and the public key corresponding to the second private key. The secret information of the first server includes Z1 and V1.

[0124] Z1 = y0*(X–w0*M) (7)

[0125] V1 = y0*L (8)

[0126] After obtaining the secret information of the first server, the first server can generate the session key and the MAC key of the first server through the following formula 9 based on the secret information of the first server, the identifier of the first server, the first account, the fourth PAKE parameter, the fifth PAKE parameter, and the first private key.

[0127] k1 || h1 = Hash(idC, idS1, X, Y, Z1, V1, w0) (9)

[0128] Among them, k1 is the session key of the first server, h1 is the MAC key of the first server, and Hash represents a preset hash function. It can be seen from the above formula (9) that the string generated by the hash function is the concatenation of the session key and the MAC key. Based on this, in the embodiments of the present application, the first server can divide the string based on a predetermined rule, with a part as the session key and the other part as the MAC key.

[0129] After obtaining the MAC key of the first server, the first server can calculate the fifth MAC by using the MAC key and the fourth PAKE parameter. Among them, the fifth MAC can be mac5 = MAC(h1, X). Then, the first server sends the fifth MAC and the fifth PAKE parameter to the second server. After receiving the fifth MAC and the fifth PAKE parameter, the second server forwards the fifth MAC and the fifth PAKE parameter to the first client.

[0130] After receiving the fifth MAC and the fifth PAKE parameter, the first client generates the session key and the MAC key of the first client based on the fifth PAKE parameter, the first private key and the second private key calculated by itself, the temporary private key of the first client, and the fourth PAKE parameter. Then, the first client can calculate the sixth MAC based on its own MAC key and the fourth PAKE parameter, and authenticate the identity of the first server based on the fifth MAC and the sixth MAC.

[0131] Among them, the first client can first calculate the secret information of the first client based on the first private key, the second private key, the temporary private key of the first client, and the fifth PAKE parameter calculated by itself, and then generate the session key and the MAC key of the first client based on the secret information of the first client.

[0132] As an example, the first client can first calculate the first secret information Z2 of the first client through the following formula (10) based on the first private key, the temporary private key of the first client, and the fifth PAKE parameter, and calculate the second secret information V2 of the first client through the following formula (11) based on the first private key, the second private key, and the fifth PAKE parameter. Among them, the secret information of the first client includes Z2 and V2.

[0133] Z2 = x0 * (Y – w0 * N) (10)

[0134] V2 = w1 * (Y – w0 * N) (11)

[0135] After obtaining the secret information of the first client, the first client can generate the session key k2 and the MAC key h2 of the first client based on the secret information, the first account, the identifier of the first server, the fourth PAKE parameter, the fifth PAKE parameter, and the first private key through the following formula (12).

[0136] k2 || h2 = Hash(idC, idS1, X, Y, Z2, V2, w0) (12)

[0137] After obtaining the MAC key of the first client, the first client can generate the sixth MAC by using the MAC key and the fourth PAKE parameter. Among them, the sixth MAC can be mac6 = MAC(h2, X). Then, compare the sixth MAC with the fifth MAC sent by the first server. If the sixth MAC is different from the fifth MAC, the authentication of the first server fails, and the federated registration fails. The first client can end the operation. If the sixth MAC is the same as the fifth MAC, the authentication of the first server by the first client passes. In this case, the first client can generate the seventh MAC based on its own MAC key and the fifth PAKE parameter. Among them, the seventh MAC can be mac7 = MAC(h2, Y). Then, the first client transparently transmits the seventh MAC to the first server through the second server so that the first server can authenticate the first client based on the seventh MAC.

[0138] Correspondingly, the first server can calculate the eighth MAC based on the MAC key and the fifth PAKE parameter calculated by itself. Among them, the eighth MAC can be mac8 = MAC(h1, Y). Based on this, after receiving the seventh MAC sent by the first client, the first server can compare the seventh MAC with the eighth MAC. If the seventh MAC is different from the eighth MAC, the authentication of the first client fails, and the federated registration fails. The first server can send a registration failure response to the first client through the second server. If the seventh MAC is the same as the eighth MAC, the authentication of the first client passes. In this case, the first server can execute step 306.

[0139] In the second possible scenario, the password verification information of the first account pre-stored in the first server adopts the second implementation method introduced above. In this case, after receiving the federated registration request, the first server can obtain the public keys corresponding to the first private key and the second private key, as well as the random salt value based on the first account carried in the federated registration request; afterwards, based on the first private key and the temporary private key of the first server, the fifth PAKE parameter is generated. Based on the public key corresponding to the second private key, the first private key, the temporary private key of the first server, the fourth PAKE parameter, the fifth PAKE parameter, and the random salt value, the fifth MAC is generated. Afterwards, the fifth MAC, the fifth PAKE parameter, and the random salt value are transparently transmitted to the first client through the second server.

[0140] Among them, the first server can use the aforementioned formula 6 to generate the fifth PAKE parameter. Afterwards, the first server can use the aforementioned formulas 7 and 8 to generate two secret messages of the first server, and calculate the session key and MAC key of the first server through the following formula 13. Afterwards, the first server can use this MAC key and the fourth PAKE parameter to calculate the fifth MAC.

[0141] k1 || h1 = Hash (idC, idS1, X, salt, Y, Z1, V1, w0) (13)

[0142] Comparing formula 13 and formula 9, it can be seen that in the second possible scenario compared with the aforementioned first possible scenario, when calculating its own MAC key and session key, the first server adds a random salt value.

[0143] After obtaining the fifth PAKE parameter and the fifth MAC, the first server can transparently transmit the fifth PAKE parameter, the fifth MAC, and the random salt value to the first client through the second server.

[0144] After receiving the fifth PAKE parameter, the fifth MAC, and the random salt value, the first client can first calculate the second private key based on the random salt value and the first password through the aforementioned formula 4, and then calculate the secret message of the first client through the aforementioned formulas 10 and 11, and calculate the session key and MAC key of the first client through the following formula 14.

[0145] k2 || h2 = Hash(idC, idS1, X, salt, Y, Z2, V2, w0) (14)

[0146] After obtaining its own session key and MAC key, the first client can generate a sixth MAC based on its own MAC key and the fourth PAKE parameter. Compare the fifth MAC and the sixth MAC. If they are different, the authentication of the first server fails, and the federated registration fails, ending the operation; if they are the same, the authentication of the first server passes, and the first client can continue to generate a seventh MAC based on its own MAC key and the fifth PAKE parameter, and transmit the seventh MAC to the first server through the second server.

[0147] Optionally, after the authentication of the first server passes, the first client can also generate a seventh MAC based on its own MAC key, the fifth PAKE parameter, and a random salt value. At this time, the seventh MAC can be mac7 = MAC(h2, salt||Y).

[0148] The first server can calculate an eighth MAC based on the MAC key and the fifth PAKE parameter calculated by itself. Or, if the first client also uses a random salt value to calculate the seventh MAC, the first server can also calculate the eighth MAC based on its own MAC key, the fifth PAKE parameter, and the random salt value. At this time, the eighth MAC can be mac8 = MAC(h1, salt||Y). After receiving the seventh MAC from the first client, the first server can compare the seventh MAC and the eighth MAC. If they are different, the authentication of the first client fails, and the federated registration fails. The first server can send a registration failure response to the first client through the second server; if they are the same, the authentication of the first client passes, and the first server can then execute step 306.

[0149] Step 306: After the authentication between the first server and the first client passes, the first server sends the first account and the first verification shard to the second server.

[0150] After the mutual authentication between the first server and the first client passes, the first server can obtain the first verification shard based on the password verification information stored by itself and the identifier of the second server sent by the second server in step 304, and send the first verification shard to the second server.

[0151] In the first implementation, the first server can generate a second verification shard based on the first private key in the password verification information and the identifier of the second server, and then generate the first verification shard based on the second verification shard and the first private key.

[0152] As an example, the first server may use a key derivation function (KDF) to calculate a second verification shard through the following formula 15, and then calculate a first verification shard through the following formula 16.

[0153] w01 = KDF(w0, idS2) (15)

[0154] w00 = w0–w01 mod p (16)

[0155] Where w00 is the first verification shard, w01 is the second verification shard, w0 is the first private key, idS2 is the identifier of the second server, p is the prime order of the aforementioned group G, and mod is the modulo operator.

[0156] After generating the second verification shard and the first verification shard, the first server may send the first account and the first verification shard to the second server together. Optionally, the first server may also store the second verification shard corresponding to the first account.

[0157] In the second implementation, the first server may generate a first verification shard based on the public key corresponding to the second private key in the password verification information and the identifier of the second server.

[0158] As an example, the first server may use KDF to calculate the first verification shard L0 through the following formula 17 or 18.

[0159] L0 = KDF(L, idS2)*M (17)

[0160] L0 = KDF(L, idS2)*N (18)

[0161] It should be noted that when using formula 18 to calculate the first verification shard, N is not the identity element of group G.

[0162] After generating the first verification shard, the first server may send the first account and the first verification shard to the second server together. Optionally, the first server may also store the first verification shard corresponding to the first account.

[0163] In the third implementation: The first server may generate a second verification shard based on the public key corresponding to the second private key in the password verification information and the identifier of the second server, and then generate a first verification shard based on the second verification shard.

[0164] As an example, the first server may calculate the second verification shard through the following formula 19, and then calculate the first verification shard through formula 20.

[0165] w11 = KDF(L, idS2) (19)

[0166] w10 = 1 / w11 mod p (20)

[0167] Among them, w11 is the second verification shard, and w10 is the first verification shard.

[0168] After generating the second verification shard and the first verification shard, the first server can send the first account and the first verification shard to the second server together. Optionally, the first server can also store the second verification shard corresponding to the first account.

[0169] It should be noted that the above are three examples of obtaining the first verification shard given in the embodiments of this application. The first server can also use other implementation methods to obtain the first verification shard. For example, after obtaining w00 using the foregoing formula (16), the first server can also directly use w00 and the public key L corresponding to the second private key as the first verification shard and send it to the second server.

[0170] Step 307: The second server stores the first account and the first verification shard.

[0171] After receiving the first account and the first verification shard sent by the first server, the second server can store the first verification shard corresponding to the first account.

[0172] Step 308: The second server sends a registration success response to the first client.

[0173] After receiving the first verification shard allocated by the first server for it, the second server can determine that the mutual identity authentication between the first server and the first client has been completed. After the second server stores the first verification shard corresponding to the first account, the federated registration of the first account and the first password in the second server has been completed. In this case, the second server can return a registration success response to the first client to notify the first client that the federated registration is successful.

[0174] In the embodiments of the present application, a user may use a first account and a first password registered in a first server to perform federated registration in a second server. In this way, the user can subsequently use the first account and the first password to log in to the second server, which simplifies the registration operation compared to the user registering a new account in the second server, and reduces the number of accounts and passwords that the user needs to remember. In addition, as can be seen from the method described in the above embodiments, after the first server completes two-way authentication with the first client, when the first server generates a first verification shard, it uses the identifier of the second server, that is, the first verification shard contains the identity information of the second server, ensuring that the first verification shards of different second servers are also different, and can reduce the risk of the second server being impersonated when subsequently logging in to the second server and performing password authentication and key negotiation with the second server.

[0175] Based on the federated registration method described in the above embodiments, the embodiments of the present application provide two detailed processes for federated registration. Among them, Figure 4 is the detailed process of the first federated registration shown in the embodiments of the present application. Refer to Figure 4 , this process includes the following steps:

[0176] Step 401: In response to a registration instruction, the first client obtains the first account idC and the first password pw input by the user.

[0177] Step 402: The first client calculates a first private key w0 and a second private key w1 based on idC and pw, and calculates a fourth PAKE parameter X based on w0 and the temporary private key x0 of the first client.

[0178] Step 403: The first client sends a federated registration request to the second server, and the federated registration request includes idC and X.

[0179] Step 404: The second server sends idC, X, and the identifier idS2 of the second server to the first server.

[0180] The detailed implementation manners of the above steps 401 to 404 can respectively refer to steps 301 to 304 described in the foregoing embodiments.

[0181] Step 405: The first server obtains the public key L corresponding to w0 and w1 stored in itself according to idC, and generates a fifth PAKE parameter Y based on w0 and the temporary private key y0 of the first server.

[0182] Step 406: The first server generates a secret information Z1 based on w0, y0, and X, and generates a secret information V1 based on y0 and L; generates a MAC key h1 of the first server based on idC, the identifier idS1 of the first server, Z1, V1, X, Y, and w0, and generates mac5 based on h1 and X.

[0183] Step 407: The first server transmits mac5 and Y to the first client through the second server.

[0184] Step 408: The first client generates a secret information Z2 based on w0, x0, and Y, and generates a secret information V2 based on w1, w0, and Y; generates a MAC key h2 of the first client based on idC, idS1, Z2, V2, X, Y, and w0, and generates mac6 based on h2 and X.

[0185] Step 409: The first client compares mac5 and mac6. If mac5 and mac6 are the same, generates mac7 based on h2 and Y.

[0186] Step 410: The first client transmits mac7 to the first server through the second server.

[0187] For the detailed implementation manners of the above steps 405 to 410, reference may be made to the first possible case in step 305 of the foregoing embodiment.

[0188] Step 411: The first server generates mac8 based on h1 and Y, compares mac7 and mac8. If mac7 and mac8 are the same, generates the first verification shard w00 or L0 or w10.

[0189] Step 412: The first server sends idC and w00 or L0 or w10 to the second server.

[0190] For the detailed implementation manners of the above steps 411 to 412, reference may be made to step 306 of the foregoing embodiment.

[0191] Step 413: The second server stores idC and w00 or L0 or w10.

[0192] Step 414: The second server sends a registration success response to the first client.

[0193] For the detailed implementation manners of the above steps 413 to 414, reference may be made to step 307 and step 308 of the foregoing embodiment respectively.

[0194] Figure 5 It is the detailed process of the second type of federated registration shown in the embodiments of the present application. Refer to Figure 5 , and this process includes the following steps:

[0195] Step 501: In response to the registration instruction, the first client obtains the first account ID C and the first password pw entered by the user.

[0196] Step 502: The first client calculates the first private key w0 based on ID C and pw, and calculates the fourth PAKE parameter X based on w0 and the temporary private key x0 of the first client.

[0197] Step 503: The first client sends a federated registration request to the second server, and the federated registration request includes ID C and X.

[0198] Step 504: The second server sends ID C, X, and the identifier idS2 of the second server to the first server.

[0199] For the detailed implementation methods of the above steps 501 to 504, reference can be made to steps 301 to 304 introduced in the foregoing embodiments respectively.

[0200] Step 505: The first server obtains the stored w0, the public key L corresponding to the second private key w1, and the random salt value salt according to ID C, and generates the fifth PAKE parameter Y based on w0 and the temporary private key y0 of the first server.

[0201] Step 506: The first server generates the secret information Z1 based on w0, y0, and X, and generates the secret information V1 based on y0 and L; based on ID C, the identifier idS1 of the first server, Z1, V1, X, Y, salt, and w0, generates the MAC key h1 of the first server, and generates mac5 based on h1 and X.

[0202] Step 507: The first server transmits mac5, Y, and salt to the first client through the second server.

[0203] Step 508: The first client generates w1 based on pw and salt, generates the secret information Z2 based on w0, x0, and Y, and generates the secret information V2 based on w1, w0, and Y; based on ID C, idS1, Z2, V2, X, Y, salt, and w0, generates the MAC key h2 of the first client, and generates mac6 based on h2 and X.

[0204] Step 509: The first client compares mac5 and mac6. If mac5 and mac6 are the same, it generates mac7 based on h2, salt, and Y.

[0205] Step 510: The first client transmits mac7 to the first server through the second server.

[0206] For the detailed implementation of the above steps 505 to 510, reference can be made to the second possible case in step 305 of the foregoing embodiment.

[0207] Step 511: The first server generates mac8 based on h1, salt, and Y, compares mac7 and mac8. If mac7 and mac8 are the same, it generates the first verification shard w00 or L0 or w10.

[0208] Step 512: The first server sends idC and w00 or L0 or w10 to the second server.

[0209] For the detailed implementation of the above steps 511 to 512, reference can be made to step 306 in the foregoing embodiment.

[0210] Step 513: The second server stores idC and w00 or L0 or w10.

[0211] Step 514: The second server sends a registration success response to the first client.

[0212] For the detailed implementation of the above steps 513 to 514, reference can be made to step 307 and step 308 in the foregoing embodiment respectively.

[0213] After completing the federated registration through the method introduced above, subsequent users can then use the first account and the first password to log in to the second server. Next, the process of the user logging in to the second server through the first client using the first account and the first password will be introduced.

[0214] See Figure 6 , and this process may include the following steps:

[0215] Step 601: In response to a login instruction, the first client obtains the first account and the first password input by the user, where the first account and the first password are the account and password registered in the first server.

[0216] In the embodiment of the present application, the user can input the first account and the first password on the login page of the first client and click the login option to trigger the login instruction. In response to this login instruction, the first client obtains the first account and the first password input by the user.

[0217] Step 602: The first client generates a first PAKE parameter based on the first password and the temporary private key of the first client.

[0218] This step can have three different implementation manners.

[0219] Method 1: The first client can generate a first private key and a second private key based on the first password, the first account, and the identifier of the first server using the aforementioned formula 1. After that, the first client can generate a first PAKE parameter based on the first private key and the temporary private key of the first client. The first PAKE parameter is used for identity authentication and key negotiation with the second server.

[0220] Exemplarily, the first client can generate the first PAKE parameter based on the first private key and the temporary private key of the first client through the following formula 21.

[0221] X0 = x1*P + w0*M (21)

[0222] Where X0 is the first PAKE parameter, x1 is the temporary private key of the first client, P is the generator of the specified group G, w0 is the first private key, and M is a random element in the pre-specified group G. It should be noted that x1 can be a string randomly generated by the first client, and x1 can be the same as or different from the temporary private key x0 generated during the aforementioned federated registration process.

[0223] Method 2: The first client can generate a first private key based on the first password, the first account, and the identifier of the first server using the aforementioned formula 3. After that, the first client can generate the first PAKE parameter based on the first private key and the temporary private key of the first client by referring to the method in Method 1 above.

[0224] Method 3: The first client can generate a first private key and a second private key based on the first password, the first account, and the identifier of the first server using the aforementioned formula 1. Obtain the identifier of the second server, and generate a first verification shard w00 based on the identifier of the second server and the first private key through the aforementioned formulas 15 and 16. After that, generate a first PAKE parameter based on the first verification shard and the temporary private key of the first client through the following formula 22.

[0225] X0 = x1*P + w00*M (22)

[0226] Step 603: The first client uses the PAKE protocol to perform identity authentication and key negotiation with the second server based on the first account and the first PAKE parameter.

[0227] In the embodiment of the present application, since the federated registration of the first account is completed in the second server, and the second server stores the first verification shard generated based on the password verification information of the first account, after the first client generates the first PAKE parameter, it can use the first account and the first PAKE parameter to interact with the second server based on the PAKE protocol to implement two-way authentication and key negotiation with the second server. Moreover, since the key negotiation in the embodiment of the present application is directly carried out between the first client and the second server, the negotiated key will not be known to the first server. In this way, the security of communication can be further improved to ensure data security.

[0228] Specifically, in a possible implementation manner, the process of the first client and the second server performing authentication and key negotiation in step 603 can be implemented through Figure 7 the steps 603a to 603c shown below.

[0229] Step 603a: The first client sends a login request to the second server. The login request includes the first account and the first PAKE parameter, and the second server receives the login request.

[0230] Step 603b: The second server generates a second PAKE parameter based on the temporary private key of the second server.

[0231] After receiving the login request sent by the first client, the second server can generate its own temporary private key, and then generate a second PAKE parameter based on its own temporary private key. Exemplarily, the second server can generate the second PAKE parameter in the following two ways.

[0232] Way 1: The second server can generate the second PAKE parameter based on its own temporary private key through the following formula 23.

[0233] Y0 = y1 * P (23)

[0234] Where, Y0 is the second PAKE parameter; y1 is the temporary private key of the second server, which can be a string randomly generated by the second server; P is the generator of the group G.

[0235] Way 2: The second server can obtain the first verification shard based on the first account, and then generate the second PAKE parameter based on the first verification shard and its own temporary private key.

[0236] Among them, if the first verification shard stored in the second server is generated based on the public key corresponding to the second private key, for example, when the first verification shard is L0 generated through the foregoing formula 17 or 18, the second server can generate the second PAKE parameter through the following formula 24.

[0237] Y0 = y1*P + L0(24)

[0238] Optionally, if the first verification shard stored in the second server is generated based on the first private key, for example, when the first verification shard is w00 generated by the foregoing formula 16, the second server may generate the second PAKE parameter through the following formula 25 or 26.

[0239] Y0 = y1*P + w00*M (25)

[0240] Y0 = y1*P + w00*N (26)

[0241] It should be noted that when the second PAKE parameter is generated by using the above formula 26, N is not the identity element of the group G.

[0242] Step 603c: The second server performs identity authentication and key negotiation with the first client based on the first account, the first PAKE parameter, the second PAKE parameter, and the stored first verification shard.

[0243] After the second server generates the second PAKE parameter, it can interact with the first client based on the first account, the first PAKE parameter, the second PAKE parameter, and the stored first verification shard, so as to implement two-way identity authentication and key negotiation.

[0244] In a possible implementation manner, if the first verification shard stored in the second server contains both the information of the first private key in the password verification information of the first account and the information of the second private key, for example, the first verification shard not only contains the foregoing w00, but also includes L, the second server can independently interact with the first client to implement two-way identity authentication and key negotiation.

[0245] Exemplarily, the second server can use the first account, the first PAKE parameter, the second PAKE parameter, and the first verification shard to generate a server session key and a server MAC key. After that, based on the server MAC key and the first PAKE parameter, a first MAC is generated and the first MAC and the second PAKE parameter are sent to the first client. After receiving the first MAC, the first client generates a client session key and a client MAC key based on the first account, the first PAKE parameter, the second PAKE parameter, and the password verification information. After that, based on the client MAC key and the first PAKE parameter, a fourth MAC is generated, the second server is authenticated based on the first MAC and the fourth MAC, and after the authentication passes, a second MAC is generated based on the second PAKE parameter and the client MAC key and sent to the second server. Correspondingly, the second server can authenticate the identity of the first client based on the second MAC.

[0246] As an example, the first PAKE parameter can be obtained through the third method in the aforementioned step 602, the second PAKE parameter can be calculated through formula 26, and the first verification shard stored in the second server includes w00 and the public key L corresponding to the second private key. Based on this, the second server can first generate Z3 in the server secret information based on the first PAKE parameter, the temporary private key of the second server, and w00 through the following formula 27, and generate V3 in the server secret information based on the temporary private key of the second server and the public key L corresponding to the second private key through the following formula 28.

[0247] Z3 = y1*(X0–w00*M) (27)

[0248] V3 = y1*L (28)

[0249] After generating the server secret information Z3 and V3, the second server can generate a server session key k3 and a server MAC key h3 based on the first account, the identifier of the second server, the first PAKE parameter, the second PAKE parameter, Z3, V3, and w00 through the following formula 29.

[0250] k3 || h3 = Hash(idC, idS2, X0, Y0, Z3, V3, w00) (29)

[0251] After generating the server MAC key, the second server generates a first MAC based on the server MAC key and the first PAKE parameter. Exemplarily, the first MAC can be mac1=MAC(h3,X0). After that, the second server can send the first MAC and the second PAKE parameter to the first client.

[0252] After receiving the second PAKE parameter and the first MAC, the first client generates Z4 in the client secret information based on the temporary private key of the first client, the second PAKE parameter, and w00 calculated in Method 3 of the aforementioned step 602, and generates V4 in the client secret information based on the second private key, w00, and the second PAKE parameter through the following formula 31.

[0253] Z4 = x1 * (Y0 – w00 * N) (30)

[0254] V4 = w1 * (Y0 – w00 * N) (31)

[0255] After generating the client secret information Z4 and V4, the first client can generate the client session key k4 and the client MAC key h4 through the following formula 32 based on the first account, the identifier of the second server, the first PAKE parameter, the second PAKE parameter, Z4, V4, and w00.

[0256] k4 || h4 = Hash(idC, idS2, X0, Y0, Z4, V4, w00) (32)

[0257] After generating the client MAC key, the first client generates the fourth MAC based on the client MAC key and the first PAKE parameter. Exemplarily, the fourth MAC can be mac4 = MAC(h4, X0). Then, the first client can compare the first MAC and the fourth MAC. If they are different, the authentication of the second server fails, the login fails, and the operation ends. If they are the same, the authentication of the second server passes. In this case, the first client generates the second MAC based on the client MAC key and the received second PAKE parameter and sends the second MAC to the second server. Wherein, the second MAC can be mac2 = MAC(h4, Y0).

[0258] The second server can generate the third MAC based on its own MAC key and the second PAKE parameter. Wherein, the third MAC can be mac3 = MAC(h3, Y0). After receiving the second MAC sent by the first client, the second server can compare the second MAC with the third MAC it generates itself. If they are different, the authentication of the first client fails, the login fails, and the second server can return a login failure response to the first client; if they are the same, the authentication of the first client passes, the login is successful, and the second server can return a login success response to the first client.

[0259] From the process of identity authentication between the first client and the second server introduced above, it can be seen that when the client MAC key calculated by the first client is the same as the server MAC key calculated by the second server, the fourth MAC calculated by the first client will be equal to the first MAC calculated by the second server, and the third MAC calculated by the second server will also be equal to the second MAC calculated by the first client. That is to say, if the first client and the second server authenticate each other successfully, it means that the MAC keys generated by the first client and the second server respectively are equal. And based on the method of generating the MAC key, it can be seen that when the MAC keys generated by the first client and the second server respectively are the same, the session keys generated by the two are also the same. Based on this, after the first client and the second server authenticate each other successfully, when the first client sends session data to the second server, it can encrypt the session data with the client session key generated by itself, and the second server can decrypt the session data with the server session key generated by itself. Correspondingly, when the second server sends session data to the first client, it can encrypt the session data with the server session key generated by itself, and the first client can decrypt the session data with the client session key generated by itself.

[0260] In another possible implementation, the first verification shard stored in the second server is generated based on the public key corresponding to the first private key or the second private key and does not include other information. That is to say, the first verification shard contains some information in the password verification information. For example, the first verification shard contains the information of the first private key but does not contain the information of the second private key, or the first verification shard contains the information of the second private key but does not contain the information of the first private key. In this case, the second server can interact with the first client with the assistance of the first server to achieve identity authentication and key negotiation with the first client. That is to say, the second server can achieve identity authentication and key negotiation with the first client with the assistance of the complete password verification information stored in the first server. See Figure 8 , the process for the second server to achieve two-way identity authentication and key negotiation with the first client with the assistance of the first server may include the following steps:

[0261] Step 603c1: The second server sends an authentication assistance request to the first server. The authentication assistance request includes the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter. The client PAKE parameter to be processed is obtained based on the first PAKE parameter. The first server receives the authentication assistance request.

[0262] In this implementation, since the first verification shard stored in the second server is generated based on the public key corresponding to the first private key or the second private key in the password verification information of the first account and does not include other information, the first verification shard will contain some information in the password verification information. Based on this, after generating the second PAKE parameter, the second server can send an authentication assistance request to the first server, requesting the first server to process the second PAKE parameter generated by the second server and the client PAKE parameter to be processed based on the stored complete password verification information, so that the second server can perform two-way authentication and key negotiation based on the password with the first client. Among them, the client PAKE parameter to be processed can be obtained by the second server processing the first PAKE parameter, or the client PAKE parameter to be processed is the first PAKE parameter. In addition, the second PAKE parameter can also be referred to as the server PAKE parameter to be processed.

[0263] According to the different generation methods of the first verification shard in the second server, that is, according to the different contents in the password verification information included in the first verification shard, the implementation method of the second server sending the authentication assistance request can also be different.

[0264] In the first implementation, if the first verification shard in the second server is generated based on the first private key in the password verification information, the second server can generate a third PAKE parameter based on the first verification shard and the first PAKE parameter, and the third PAKE parameter is the client PAKE parameter to be processed. After that, the second server can send an authentication assistance request to the first server, where the authentication assistance request can include the third PAKE parameter, the second PAKE parameter, the first account, and the identifier of the second server.

[0265] As an example, the second server can directly process the first PAKE parameter using the first verification shard to obtain the third PAKE parameter. For example, when the first verification shard is w00 that satisfies the aforementioned formulas 15 and 16, the second server can generate a third PAKE parameter that satisfies the following formula 33.

[0266] X1 = X0–w00*M (33)

[0267] Where X1 is the third PAKE parameter, X0 is the first PAKE parameter, w00 is the first verification shard, and M is a randomly specified element in the group G.

[0268] In another example, the second server may process the first PAKE parameter by using the first verification shard and the first blinding factor to obtain a third PAKE parameter. The first blinding factor is a security factor randomly generated by the second server for blinding the first verification shard to protect the security of the first verification shard. For example, when the first verification shard satisfies the foregoing formula 15 or 16, the second server may generate a third PAKE parameter that satisfies the following formula 34, where t is the first blinding factor.

[0269] X1 = t*(X0–w00*M) (34)

[0270] It can be seen from the foregoing formula 34 that through the processing of the first blinding factor, even if X0 and X1 are obtained by other parties during the transmission process, other parties cannot obtain the information item w00*M containing the first verification shard from X1 and X0. In this way, a third party cannot impersonate the second server to perform identity authentication and key negotiation with the first client, ensuring the security of identity authentication and key negotiation between the second server and the first client.

[0271] When the second server processes the first PAKE parameter by using the first verification shard and the first blinding factor, the second server may further generate a first blinding value based on the first blinding factor, so that the first server can eliminate the influence of the first blinding factor introduced in the third PAKE parameter based on the first blinding value. Exemplarily, the second server may generate a first blinding value T that satisfies the following formula 35.

[0272] T = t*M (35)

[0273] In the second implementation manner, if the first verification shard in the second server is generated based on the public key corresponding to the second private key in the password verification information, the second server may directly send an authentication assistance request to the first server, where the authentication assistance request may include the first PAKE parameter, the second PAKE parameter, the first account number, and the identifier of the second server. At this time, the client PAKE parameter to be processed is the first PAKE parameter.

[0274] Step 603c2: The first server obtains first assistance information based on the password verification information of the first account number, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter. The first assistance information includes the first processed client PAKE parameter, the first processed server PAKE parameter, and public key information.

[0275] After receiving the authentication assistance request sent by the second server, the first server may obtain the password verification information of the stored first account based on the first account in the authentication assistance request. Then, based on the password verification information and the identifier of the second server, a second verification shard is generated; based on the password verification information, the second verification shard, the client PAKE parameter to be processed, and the second PAKE parameter, the first assistance information is obtained.

[0276] As can be seen from the introduction in the foregoing step 603c1, according to the different generation methods of the first verification shard stored in the second server, the method for the first server to generate the second verification shard is also different. Correspondingly, the method for the first server to obtain the first assistance information based on the second verification shard, the password verification information, the client PAKE parameter to be processed, and the second PAKE parameter is also different. Based on this, the following introduces two possible implementation methods of this step.

[0277] Method 1:

[0278] If the first verification shard in the second server is generated based on the first private key in the password verification information and the identifier of the second server, the first server may generate the second verification shard based on the first private key and the identifier of the second server. Among them, the second verification shard is different from the first verification shard. Then, the first server may process the client PAKE parameter to be processed and the second PAKE parameter respectively based on the second verification shard, so as to obtain the first processed client PAKE parameter and the first processed server PAKE parameter, and obtain the public key information based on the public key corresponding to the second private key in the password verification information.

[0279] Exemplarily, as can be seen from the introduction in the foregoing step 306, the first verification shard may be generated through the foregoing formulas 15 and 16. Then, the first server may use the first private key and the identifier of the second server to generate the second verification shard through the foregoing formula 15.

[0280] As can be seen from the introduction in the foregoing step 603c1, when the first verification shard is generated based on the first private key, the client PAKE parameter to be processed in the authentication assistance request may be the third PAKE parameter obtained by processing the first PAKE parameter based on the first verification shard. In this case, after obtaining the second verification shard, the first server may process the third PAKE parameter based on the second verification shard to obtain the first processed client PAKE parameter, and process the second PAKE parameter based on the second verification shard to obtain the first processed server PAKE parameter.

[0281] For example, when the third PAKE parameter is calculated by formula 33, the first server can obtain the first processed client PAKE parameter through the following formula 36. Optionally, when the third PAKE parameter is calculated by formula 34, the authentication assistance request will also include a first blinding value. In this case, the first server can obtain the first processed client PAKE parameter through formula 37.

[0282] X2 = X1 – w01 * M (36)

[0283] X2 = X1 – w01 * T (37)

[0284] Wherein, X2 is the first processed client PAKE parameter, and w01 is the second verification shard.

[0285] For example, when the second PAKE parameter is generated by the foregoing formula 23, the first server can obtain the first processed server PAKE parameter through the following formula 38. Optionally, if the second PAKE parameter is generated by the foregoing formula 25 or 26, the first server can also generate the first verification shard based on the generated second verification shard and the first private key through the foregoing formula 16. Then, based on the first verification shard, the second PAKE parameter is processed through the following formula 39 or 40 to obtain the first processed server PAKE parameter.

[0286] Y1 = Y0 + w01 * N (38)

[0287] Y1 = (Y0 – w00 * M) + w0 * N (39)

[0288] Y1 = (Y0 – w00 * N) + w0 * N (40)

[0289] After obtaining the first processed client PAKE parameter and the first processed server PAKE parameter, the first server can directly use the public key corresponding to the second private key as the public key information, thereby obtaining the first auxiliary information.

[0290] Optionally, the first server can also generate a second blinding factor and generate the public key information based on the second blinding factor and the public key corresponding to the second private key. On this basis, the first server can process the third PAKE parameter and the second PAKE parameter respectively based on the second blinding factor and the second verification shard, thereby obtaining the first processed client PAKE parameter and the first processed server PAKE parameter.

[0291] Among them, the first server can randomly generate a second blinding factor. Alternatively, the first server can first generate a random number, and then use the information carried in the authentication assistance request and this random number to generate the second blinding factor through KDF.

[0292] For example, if the authentication assistance request carries a third PAKE parameter, a second PAKE parameter, a first account, an identifier of the second server, and a first blinding value, the first server can generate the second blinding factor through the following formula 41.

[0293] u = KDF(RandS1, idC || idS2 || T || X1 || Y0) (41)

[0294] Among them, u is the second blinding factor, and RandS1 is the random number generated by the first server.

[0295] After obtaining the second blinding factor, the first server can use this second blinding factor to blind the public key corresponding to the second private key to obtain the blinded value of the public key corresponding to the second private key, and use this blinded value as the public key information. For example, the public key information calculated by the first server can be U = u * L. Among them, u is the second blinding factor, and L is the public key corresponding to the second private key.

[0296] In addition, the first server can also process the third PAKE parameter and the second PAKE parameter respectively based on the second blinding factor and the second check shard. That is, the first server can add the second blinding factor to the aforementioned formulas 36, 37, 38, 39, and 40.

[0297] For example, when the third PAKE parameter is calculated through formula 33, the first server can calculate the first processed client PAKE parameter through the following formula 42. When the third PAKE parameter is calculated through formula 34, the first server can calculate the first processed client PAKE parameter through the following formula 43. When the second PAKE parameter is generated through the aforementioned formula 23, the first server can obtain the first processed server PAKE parameter through the following formula 44. When the second PAKE parameter is generated through the aforementioned formula 25 or 26, then the first server can generate the first check shard through the aforementioned formula 16 based on the generated second check shard and the first private key, and then obtain the first processed server PAKE parameter through the following formula 45 or 46.

[0298] X2 = u*(X1–w01*M) (42)

[0299] X2 = u*(X1–w01*T) (43)

[0300] Y1 = u * Y0 + w01 * N (44)

[0301] Y1 = u * (Y0 – w00 * M) + w0 * N (45)

[0302] Y1 = u * (Y0 – w00 * N) + w0 * N (46)

[0303] Method 2:

[0304] If the first verification shard in the second server is generated based on the public key corresponding to the second private key in the password verification information and the identifier of the second server, the first server can generate a second verification shard based on the public key corresponding to the second private key and the identifier of the second server. Then, the first server can process the client PAKE parameter to be processed based on the first private key to obtain the first processed client PAKE parameter, process the second PAKE parameter based on the first private key or the first private key and the second verification shard to obtain the first processed server PAKE parameter, and obtain the public key information based on the public key corresponding to the second private key.

[0305] It should be noted that when the first verification shard is generated based on the public key corresponding to the second private key, the client PAKE parameter to be processed in the authentication auxiliary request can be the first PAKE parameter. In this case, the first server can process the first PAKE parameter based on the first private key to obtain the first processed client PAKE parameter.

[0306] Exemplarily, the first server can obtain the first processed client PAKE parameter X2 through the following formula 47.

[0307] X2 = X0 – w0 * M (47)

[0308] In addition, in an example, if the first verification shard is generated based on formula 17 or 18 in the foregoing embodiment, the first server can generate the second verification shard in the same way. At this time, the second verification shard is the same as the first verification shard. In this case, the second PAKE parameter can be generated through the foregoing formula 24. Correspondingly, the first server can process the second PAKE parameter based on the second verification shard and the first private key through the following formula 48 to obtain the first processed server PAKE parameter. Then, the first server can use the public key corresponding to the second private key as the public key information.

[0309] Y1 = (Y0 – L0) + w0 * N (48)

[0310] In another example, if the first verification shard is generated based on Formulas 19 and 20 in the foregoing embodiments, the first server may use Formula 19 to generate the second verification shard. At this time, the first verification shard and the second verification shard are different. In this case, the second PAKE parameter may be generated by the foregoing Formula 23. Correspondingly, the first server may process the second PAKE parameter based on the first private key through the following Formula 49 to obtain the first processed server PAKE parameter. After that, the first server may generate public key information based on the second verification shard and the public key corresponding to the second private key. Among them, the public key information may be w11*L, where w11 is the second verification shard and L is the public key corresponding to the second private key.

[0311] Y1 = Y0 + w0*N (49)

[0312] Optionally, in the second method, the first server may also generate a second blinding factor, and blind the public key corresponding to the second private key based on the second blinding factor to obtain a blinded value of the public key corresponding to the second private key. This blinded value is the public key information. Correspondingly, the first server may also process the first PAKE parameter and the second PAKE parameter using the second blinding factor.

[0313] Among them, the implementation method for the first server to generate the second blinding factor may refer to the relevant introduction in the foregoing first method. In addition, the public key information obtained by processing the public key corresponding to the second private key using the second blinding factor may be U = u*L or U = u*w11*L. Correspondingly, the first server may use the second blinding factor to process through the following Formula 50 to obtain the first processed client PAKE parameter. In addition, when the first verification shard is L0, the first processed server PAKE parameter may be obtained through the following Formula 51, and when the first verification shard is w10, the first processed server PAKE parameter may be obtained through the following Formula 52.

[0314] X2 = u*(X0 – w0*M) (50)

[0315] Y1 = u*(Y0 – L0) + w0*N (51)

[0316] Y1 = u*Y0 + w0*N (52)

[0317] After obtaining the first processed client PAKE parameter, the first processed server PAKE parameter, and the public key information through any one of the implementation methods in the first method or the second method introduced above, the first server may obtain first auxiliary information, where the first auxiliary information includes the first processed client PAKE parameter, the first processed server PAKE parameter, and the public key information. Optionally, the first auxiliary information may further include the identifier of the first server.

[0318] Optionally, if the second private key in the password verification information of the first server is generated by the first password and the random salt value stored in the first server, the random salt value may also be included in the first auxiliary information.

[0319] Step 603c3: The first server sends the first auxiliary information to the second server.

[0320] Step 603c4: The second server performs identity authentication and key negotiation with the first client based on the first auxiliary information and the first verification shard.

[0321] As can be seen from the way of obtaining the first auxiliary information introduced above, after the auxiliary processing of the first server, the first auxiliary information finally obtained contains the information of the first private key and the second private key in the password verification information of the first account. In this way, the second server can use the first auxiliary information to perform two-way authentication and key negotiation with the first client.

[0322] Exemplarily, the second server may obtain the second processing server PAKE parameter based on the first processing server PAKE parameter in the first auxiliary information; generate a server session key and a server MAC key based on the first auxiliary information, the second processing server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter; generate a first MAC based on the server MAC key and the first PAKE parameter; and send the first MAC and the second auxiliary information to the first client, where the second auxiliary information includes the identifier of the second server and the second processing server PAKE parameter.

[0323] Among them, according to the differences in the first verification shards stored in the second server, there are the following two possible implementation manners for the above process.

[0324] Manner 1:

[0325] When the first verification shard is generated based on the first private key, the second server may process the first processing server PAKE parameter based on the first verification shard to obtain the second processing server PAKE parameter.

[0326] For example, when the first processing server PAKE parameter is calculated by formula 38 or 44, the second server may obtain the second processing server PAKE parameter Y2 through the following formula 53.

[0327] Y2 = Y1 + w00 * N (53)

[0328] Optionally, the second server may also generate a third blinding factor, and process the first processing server's PAKE parameter based on the third blinding factor and the first verification shard to obtain the second processing server's PAKE parameter.

[0329] Among them, the second server may randomly generate a third blinding factor. Among them, the third blinding factor may be the same as or different from the first blinding factor.

[0330] Optionally, the second server may also generate a random number, and use the random number and the first auxiliary information to generate a third blinding factor through KDF. For example, the second server may use the following formula 54 to generate the third blinding factor.

[0331] v = KDF(RandS2, idS1 || X2 || Y1 || U) (54)

[0332] Among them, v is the third blinding factor, RandS2 is the random number generated by the second server, idS1 is the identifier of the first server, X2 is the first processing client's PAKE parameter, Y1 is the first processing server's PAKE parameter, and U is the public key information obtained after blinding the public key corresponding to the second private key.

[0333] After generating the third blinding factor, the second server may use the third blinding factor to blind the first processing server's PAKE parameter processed by the first verification shard, so as to obtain the second processing server's PAKE parameter. Correspondingly, the second server may also generate a second blinding value based on the third blinding factor, and use the second blinding value as part of the second auxiliary information, so that the first client can eliminate the influence of the third blinding factor included in the second processing server's PAKE based on the second blinding value.

[0334] For example, the second server may obtain the second processing server's PAKE parameter through the following formula 55, and calculate the second blinding value R through the following formula 56.

[0335] Y2 = v*(Y1+w00*N) (55)

[0336] R = v*N (56)

[0337] Optionally, in the case where the third blinding factor is different from the first blinding factor, the second server may also process the first processing server's PAKE parameter processed by the first verification shard based on the third blinding factor and the first blinding factor, and calculate the second blinding value based on the third blinding factor and the first blinding factor. At this time, the second processing server's PAKE parameter may be Y2=v*t*(Y1+w00*N), and the second blinding value may be R=v*t*N.

[0338] After obtaining the second processing server PAKE parameter, the second server can generate server secret information based on the first processing client PAKE parameter, the public key information, and the temporary private key of the second server, and generate a server session key and a server MAC key based on the server secret information, the second processing server PAKE parameter, the first verification shard, and the first PAKE parameter.

[0339] Among them, the second server can generate the first secret information of the second server based on the first processing client PAKE parameter and the temporary private key of the second server, and generate the second secret information of the second server based on the public key information and the temporary private key of the second server. Among them, the server secret information includes the first secret information and the second secret information.

[0340] In the first example, if the first processing client PAKE parameter does not contain the information of the first blinding factor and the second processing server PAKE parameter is not processed by the third blinding factor, the first secret information generated by the second server is Z3 = y1 * X2, and the second secret information is V3 = y1 * U.

[0341] In the second example, if the first processing client PAKE parameter contains the information of the first blinding factor and / or the second processing server PAKE parameter is processed by the third blinding factor, the second server can calculate the first secret information based on the first blinding factor and / or the third blinding factor, the first processing client PAKE parameter, and the temporary private key of the second server. If the second processing server PAKE parameter is processed by the third blinding factor, the second server can generate the second secret information based on the third blinding factor, the temporary private key of the second server, and the public key information.

[0342] For example, the second server can calculate the first secret information through the following formula 57 and calculate the second secret information through the following formula 58.

[0343] Z3 = (1 / t)*v*y1*X2 (57)

[0344] V3 = v*y1*U (58)

[0345] Optionally, if the second processing server PAKE parameter is obtained by processing with the third blinding factor and the first blinding factor, the second server can calculate Z3 based on the third blinding factor, the temporary private key of the second server, and the first processing client PAKE parameter, and calculate V3 based on the third blinding factor, the first blinding factor, the temporary private key of the second server, and the public key information. For example, if the second processing server PAKE parameter Y2 = v * t * (Y1 + w00 * N), then Z3 = v * y1 * X2, and V3 = v * t * y1 * U.

[0346] After generating the server secret information, the second server can generate the server session key and the server MAC key based on the server secret information, the second processing server PAKE parameter, the first check shard, and the first PAKE parameter.

[0347] Among them, if the second server also generates the second blinding value, the second server can generate the server session key and the server MAC key based on the server secret information, the second processing server PAKE parameter, the first check shard, the first PAKE parameter, and the second blinding value.

[0348] Optionally, the second server can also generate the server session key and the server MAC key based on the identifier of the first server, the identifier of the second server, the first account, the second processing server PAKE parameter, the first check shard, the first PAKE parameter, and the second blinding value.

[0349] For example, the second server can generate the server session key and the server MAC key through the following formula 59.

[0350] k3 || h3 = Hash(idC, idS2, idS1, X0, R, Y2, Z3, V3, w00) (59)

[0351] Optionally, if the first auxiliary information also includes a random salt value, the input parameter of the hash function in the above formula 59 can also include this random salt value.

[0352] After generating the server MAC key, the second server can use the server MAC key and the first PAKE parameter to generate the first MAC. Exemplarily, the first MAC can be mac1 = MAC(h3, X0). After that, the second server can send the first MAC and the second auxiliary information to the first client. The second auxiliary information may include the second processing server PAKE parameter and the identifier of the second server. Optionally, if the second server also generates a second blinding value, the second auxiliary information may also include the second blinding value. Optionally, if the first auxiliary information also includes a random salt value, the second auxiliary information also includes the random salt value. Optionally, the second auxiliary information may also include the identifier of the first server.

[0353] After receiving the first MAC and the second auxiliary information, the first client generates a client session key and a client MAC key based on the second auxiliary information, the password verification information of the first account, the temporary private key of the first client, and the first PAKE parameter; generates a fourth MAC based on the client MAC key and the first PAKE parameter; and authenticates the second server based on the first MAC and the fourth MAC.

[0354] Among them, the first client can generate a first verification shard based on the identifier of the second server in the second auxiliary information and the password verification information calculated by itself, and generate a client secret information based on the second processing server PAKE parameter, the temporary private key of the first client, and the password verification information. After that, based on the client secret information, the first PAKE parameter, the second processing server PAKE parameter, and the first verification shard, a client session key and a client MAC key are generated.

[0355] Exemplarily, the first client can use the identifier of the second server and the first private key calculated by itself to calculate the first verification shard through the foregoing formulas 15 and 16.

[0356] In addition, the first client can generate a first secret information of the first client based on the first private key, the temporary private key of the first client, and the second processing server PAKE parameter; generate a second secret information of the first client based on the first private key, the second private key, and the second processing server PAKE parameter. The secret information of the first client includes the first secret information and the second secret information.

[0357] Among them, if the second auxiliary information does not include a random salt value, the first client generates the second private key when generating the first private key in step 602. Therefore, the first client can directly obtain the generated second private key.

[0358] Optionally, if the second auxiliary information includes a random salt value, the first client may use the first password and the random salt value to generate a second private key. For example, the first client may generate the second private key through the foregoing formula 4.

[0359] In addition, in one example, if the second auxiliary information does not include the second blinding value, that is, the second processing server PAKE parameter is not processed by the third blinding factor, the first secret information of the first client may be Z4 = x1 * (Y2 – w0 * N), and the second secret information may be V4 = w1 * (Y2 – w0 * N).

[0360] In another example, if the second auxiliary information includes the second blinding value, that is, the second processing server PAKE parameter is processed by the third blinding factor, the first client may generate the first secret information of the first client based on the second blinding value, the first private key, the temporary private key of the first client, and the second processing server PAKE parameter; generate the second secret information of the first client based on the first private key, the second private key, the second blinding value, and the second processing server PAKE parameter.

[0361] For example, the first client may generate the first secret information Z4 and the second secret information V4 through the following formulas 60 and 61.

[0362] Z4 = x1 * (Y2 – w0 * R) (60)

[0363] V4 = w1 * (Y2 – w0 * R) (61)

[0364] After obtaining the client secret information, the first client may generate a client session key and a client MAC key based on the client secret information, the first PAKE parameter, the second processing server PAKE parameter, and the first verification shard. Among them, if the second auxiliary information further includes the second blinding value, the first client may generate a client session key and a client MAC key based on the client secret information, the first PAKE parameter, the second processing server PAKE parameter, the second blinding value, and the first verification shard. Optionally, the first client may also generate a client session key and a client MAC key based on the identifier of the second server, the identifier of the first server, the first account, the client secret information, the first PAKE parameter, the second processing server PAKE parameter, the first verification shard, and the second blinding value.

[0365] For example, the first client may generate a client session key and a client MAC key through the following formula 62.

[0366] k4 || h4 = Hash(idC, idS2, idS1, X0, R, Y2, Z4, V4, w00) (62)

[0367] Optionally, if the second auxiliary information further includes a random salt value, the input parameter of the hash function in the above formula (62) may further include the random salt value.

[0368] After the first client generates the client MAC key, it generates a fourth MAC based on the client MAC key and the first PAKE parameter. Exemplarily, the fourth MAC may be mac4 = MAC(h4, X0). Then, the first client may compare the first MAC and the fourth MAC. If they are different, the authentication of the second server fails, and the login fails, ending the operation. If they are the same, the authentication of the second server passes. In this case, the first client generates a second MAC based on the client MAC key and the received second processing server PAKE parameter, and sends the second MAC to the second server. Wherein, the second MAC may be mac2 = MAC(h4, Y2).

[0369] Optionally, if the second auxiliary information further includes a second blinding value, the first client generates the second MAC based on the client MAC key, the second processing server PAKE parameter, and the second blinding value. For example, the second MAC may be mac2 = MAC(h4, R||Y2). Optionally, if the second auxiliary information further includes a random salt value, the first client may generate the second MAC based on the client MAC key, the second processing server PAKE parameter, and the random salt value. For example, the second MAC may be mac2 = MAC(h4, salt||Y2). Of course, if the second auxiliary information includes both the second blinding value and the random salt value, the second MAC can be calculated based on both of them at the same time. For example, the second MAC may be mac2 = MAC(h4, salt||R||Y2).

[0370] The second server can generate a third MAC based on the server MAC key calculated by itself and the second processing server PAKE parameter. After receiving the second MAC sent by the first client, the second server can compare the second MAC with the third MAC generated by itself. If they are different, the authentication of the first client fails and the login fails. The second server can return a login failure response to the first client. If they are the same, the authentication of the first client passes and the login is successful. The second server can return a login success response to the first client. Among them, the implementation method for the second server to generate the third MAC can refer to the implementation method for the first client to generate the second MAC. The difference is that the second server uses the server MAC key, while the first client uses the client MAC key.

[0371] Method 2:

[0372] When the first verification shard is generated based on the public key corresponding to the second private key, the second processing server PAKE parameter is the same as the first processing server PAKE parameter. That is, the second server does not need to perform additional processing on the first processing server PAKE parameter.

[0373] It should be noted that from the foregoing introduction, when the first verification shard is generated based on the public key corresponding to the second private key, when the first server obtains the first auxiliary information, a second verification shard will be generated. On this basis, the first server can process the second PAKE parameter based on the second verification shard to obtain the first processing server PAKE parameter, or the first server can also process the public key corresponding to the second private key based on the second verification shard to obtain the public key information. For these two possible situations, the following two examples are provided.

[0374] In the first example, when the first processing server PAKE parameter is calculated by the first server based on the second verification shard, the first private key, and the second PAKE parameter, the second server can generate a server secret information based on the first processing client PAKE parameter, the public key information, and the temporary private key of the second server.

[0375] Specifically, the second server can generate the first secret information of the second server based on the first processing client PAKE parameter and the temporary private key of the second server. Generate the second secret information of the second server based on the temporary private key of the second server and the public key information. Among them, the server secret information includes the first secret information and the second secret information.

[0376] For example, when the first verification shard is calculated using formula 17 or 18, the second server can generate the first secret information Z3 and the second secret information V3 through the following formulas 63 and 64.

[0377] Z3 = y1 * X2 (63)

[0378] V3 = y1 * U (64)

[0379] Among them, as can be seen from the foregoing embodiments, when the first verification shard is generated based on the public key corresponding to the second private key, the client PAKE parameter to be processed can be the first PAKE parameter. The first processing client PAKE parameter X2 is calculated based on the first PAKE parameter, and U is the public key information. For example, U = L or U = u * L, where L is the public key corresponding to the second private key and u is the second blinding factor.

[0380] In another example, when the public key information is generated based on the second verification shard and the public key corresponding to the second private key, the second server can generate the server secret information based on the first verification shard, the first processing client PAKE parameter, the public key information, and the temporary private key of the second server.

[0381] Specifically, the second server can generate the first secret information of the second server based on the first processing client PAKE parameter and the temporary private key of the second server. Generate the second secret information of the second server based on the temporary private key of the second server, the first verification shard, and the public key information. Among them, the server secret information includes the first secret information and the second secret information.

[0382] For example, when the first verification shard is obtained based on Formulas 19 and 20, the second server can generate the first secret information Z3 through the foregoing Formula 63 and generate the second secret information V3 through the following Formula 65.

[0383] V3 = y1 * w10 * U (65)

[0384] Among them, U is the public key information generated based on the second verification shard and the public key corresponding to the second private key. For example, U = w11 * L, or U = u * w11 * L, where w11 is the second verification shard.

[0385] After obtaining the server secret information, the second server can generate the server session key and the server MAC key based on the server secret information, the second processing server PAKE parameter, the first verification shard, and the first PAKE parameter. The implementation manner for the second server to generate the server session key and the server MAC key can refer to the relevant implementation manner in Method 1 of this step, and will not be elaborated herein in the embodiments of the present application.

[0386] After generating the server MAC key, the second server may also refer to the implementation method in Method 1 of this step, calculate the first MAC based on the server MAC key and the first PAKE parameter, and send the first MAC and the second auxiliary information to the first client.

[0387] It should be noted that in Method 2, since the second server does not process the first processing server PAKE parameter, compared with Method 1, this implementation method does not have the third blinding factor and does not calculate the second blinding value. Correspondingly, the second auxiliary information does not include the second blinding value either.

[0388] After receiving the first MAC and the second auxiliary information, the first client may generate the client secret information based on the second auxiliary information, the temporary private key of the first client, and the password verification information. The specific implementation method may refer to the implementation method of the first client calculating the client secret information without the second blinding value in Method 1.

[0389] After generating the client secret information, the first client may calculate the client session key and the client MAC key in the same way as the second server calculates the server session key and the server MAC key. Different from the second server, the client secret information is used in the calculation of the first client.

[0390] After obtaining the client MAC key, the first client may calculate the fourth MAC based on the client MAC key and the first PAKE parameter, and authenticate the identity of the second server by comparing the fourth MAC and the first MAC. The relevant implementation method may refer to the introduction of Method 1 in this step.

[0391] After the first client passes the identity authentication of the second server, it generates the second MAC based on the client MAC key and the second processing server PAKE parameter, and sends the second MAC to the second server. Correspondingly, the second server may generate the third MAC based on the server MAC key and the second processing server PAKE parameter, and authenticate the identity of the first client by comparing the third MAC and the second MAC. The relevant implementation method may refer to the introduction of Method 1 in this step.

[0392] In addition, it should be noted that when the first verification shard is generated based on the first private key, for example, when the second PAKE parameter is calculated by Formula 25 or 26 and the first processing server PAKE parameter is calculated by Formula 39 or 40, the second server may also not process the first processing server PAKE parameter. At this time, the second processing server PAKE parameter is the first processing server PAKE parameter. Correspondingly, the second server and the first client may refer to Method 2 for mutual authentication and key negotiation.

[0393] As can be seen from the introduction of the above steps 603c1 to 603c4, the first verification shard stored in the second server contains the information of the first private key or the second private key in the password verification information, that is, it contains part of the information in the password verification information. In this case, the second server can, with the assistance of the complete password verification information in the first server, achieve two-way authentication with the first client and conduct key negotiation with the first client. That is, in this implementation method, it can be understood that the identity authentication responsibility and key negotiation responsibility of the server in the traditional PAKE protocol are separated. Since the first server stores the complete password verification information, the first server mainly undertakes the responsibility of identity authentication and assists the second server to complete the identity authentication through the stored complete password verification information, while the key negotiation is borne by the second server. In this way, the session key negotiated by the second server and the first client cannot be obtained by a third party, ensuring the security of the session key. Moreover, since the first server assigns the first verification shard implicitly containing part of the password verification information and the identifier of the second server to the second server, the second server can reduce the risk of being impersonated during the process of using the first verification shard to conduct identity authentication and key negotiation with the first client. On this basis, with the cooperation of the complete password verification information and the second verification shard in the first server, the correctness of the session key negotiated between the second server and the first client is ensured. Finally, during the above identity authentication and key negotiation process, the interaction information between the first client and the second server and between the second server and the first server can be blinded by the blinding factor, so as to reduce the risk of the password verification information and the verification shard of the password verification information contained in the interaction information being leaked, thereby improving the security.

[0394] It should be noted that the various formulas involved in the above embodiments are exemplary formulas given in the embodiments of the present application. In some possible cases, the above various formulas can also be subjected to corresponding mathematical transformations. Moreover, after a certain formula changes, the related formulas can also be changed accordingly to ensure that correct authentication and key negotiation can be achieved. For example, the element N in the group G used in some of the above formulas can be replaced by M, and M can also be replaced by N. For another example, in the formulas for blinding processing using the respective blinding factors involved in the above embodiments, the position of the blinding factor and the algorithm used can also be appropriately mathematically transformed. Correspondingly, the calculation method of the blinded value and other related formulas also need to be appropriately transformed, as long as it is ensured that the introduced blinding factor can play a blinding role without affecting the accuracy of authentication and key negotiation.

[0395] Based on the above Figures 6 to 8For the method introduced in the embodiments shown, next, the embodiments of the present application provide four exemplary flowcharts for password authentication and key negotiation.

[0396] Example 1:

[0397] The password verification information of the first account stored in the first server includes the public key L corresponding to the first private key w0 and the second private key w1, where w0 and w1 are calculated based on Formula 1, L is calculated based on Formula 2, and the first verification shard stored in the second server is w00, and w00 is calculated based on Formulas 15 and 16. See Figure 9 , and this process includes the following steps:

[0398] Step 901: In response to a login instruction, the first client obtains the first account idC and the first password pw entered by the user.

[0399] Step 902: The first client generates the first private key w0 and the second private key w1 based on pw, and generates the first PAKE parameter X0 based on w0 and the temporary private key x1 of the first client.

[0400] Among them, X0 = x1*P + w0*M.

[0401] Step 903: The first client sends a login request to the second server, and this login request includes idC and X0.

[0402] Step 904: The second server generates the second PAKE parameter Y0 based on the temporary private key y1 of the second server.

[0403] Among them, Y0 = y1*P.

[0404] Step 905: The second server randomly generates the first blinding factor t, processes X0 with t and w00 to obtain the third PAKE parameter X1, and calculates the first blinding value T based on t.

[0405] Among them, X1 = t*(X0 – w00*M), T = t*M.

[0406] Step 906: The second server sends idC, idS2, X1, Y0, T to the first server.

[0407] Among them, idS2 is the identifier of the second server. The above information can be carried in the authentication assistance request.

[0408] Step 907: The first server calculates the second verification shard w01 based on the stored w0 and idS2 in itself; generates the second blinding factor u; processes X1 with w01, u and T to obtain X2, processes Y0 with w01 and u to obtain Y1, and obtains U based on u and L.

[0409] Wherein, X2 = u * (X1 – w01 * T), Y1 = u * Y0 + w01 * N, U = u * L.

[0410] Step 908: The first server sends idS1, X2, Y1, and U to the second server.

[0411] Wherein, idS1, X2, Y1, and U are the first auxiliary information.

[0412] Step 909: The second server generates a third blinding factor v; processes Y1 based on w00 and v to obtain Y2; generates a second blinding value R based on v; generates a secret information Z3 based on t, v, y1, and X2, generates a secret information V3 based on v, y1, and U; generates a server MAC key h3 and a server session key k3 based on idC, idS2, idS1, X0, R, Y2, Z3, V3, w00; generates mac1 based on h3 and X0.

[0413] Wherein, Y2 = v * (Y1 + w00 * N), R = v * N, Z3 = (1 / t) * v * y1 * X2, V3 = v * y1 * U, k3||h3 = Hash(idC,idS2,idS1,X0,R,Y2,Z3,V3,w00), mac1 = MAC(h3,X0).

[0414] Step 910: The second server sends mac1, idS2, idS1, R, and Y2 to the first client.

[0415] Step 911: The first client generates w00 based on w0 and idS2; generates a secret information Z4 based on x1, Y2, w0, and R; generates a secret information V4 based on w1, Y2, w0, and R; generates a client MAC key h4 and a client session key k4 based on idC, idS2, idS1, X0, R, Y2, Z4, V4, w00; generates mac4 based on h4 and X0.

[0416] Wherein, Z4 = x1 * (Y2 – w0 * R), V4 = w1 * (Y2 – w0 * R), k4||h4 = Hash(idC,idS2,idS1,X0,R,Y2,Z4,V4,w00), mac4 = MAC(h4,X0).

[0417] Step 912: The first client compares mac4 and mac1. If mac4 is the same as mac1, the authentication of the second server passes, and mac2 is generated based on h4, R, and Y2.

[0418] Wherein, mac2 = MAC(h4,R||Y2).

[0419] Step 913: The first client sends mac2 to the second server.

[0420] Step 914: The second server generates mac3 based on h3, R, and Y2.

[0421] Where mac3 = MAC(h3, R||Y2).

[0422] Step 915: The second server compares mac3 and mac2. If mac3 and mac2 are the same, the authentication of the first client passes.

[0423] Step 916: The second server returns a login success response to the first client.

[0424] At this point, the first client can use k4 to encrypt the session data to be sent to the second server and decrypt the session data received from the second server. The second server can use k3 to encrypt the session data to be sent to the first client and decrypt the session data received from the first client.

[0425] Example 2:

[0426] The password verification information of the first account stored in the first server includes the first private key w0, the public key L corresponding to the second private key w1, and the random salt value salt. Among them, w0 is calculated based on Formula 3, w1 is calculated based on Formula 4, L is calculated based on Formula 2, and the first verification shard stored in the second server is w00, and w00 is calculated based on Formulas 15 and 16. See Figure 10 , and this process includes the following steps:

[0427] Step 1001: In response to the login instruction, the first client obtains the first account idC and the first password pw entered by the user.

[0428] Step 1002: The first client generates the first private key w0 based on pw, and generates the first PAKE parameter X0 based on w0 and the temporary private key x1 of the first client.

[0429] Where X0 = x1*P + w0*M.

[0430] Step 1003: The first client sends a login request to the second server, and this login request includes idC and X0.

[0431] Step 1004: The second server generates the second PAKE parameter Y0 based on the temporary private key y1 of the second server.

[0432] Where Y0 = y1*P.

[0433] Step 1005: The second server randomly generates a first blinding factor t, processes X0 using t and w00 to obtain a third PAKE parameter X1, and calculates a first blinding value T based on t.

[0434] Where X1 = t * (X0 – w00 * M), and T = t * M.

[0435] Step 1006: The second server sends idC, idS2, X1, Y0, and T to the first server.

[0436] Where idS2 is the identifier of the second server. The above information can be carried in the authentication assistance request.

[0437] Step 1007: The first server calculates a second verification shard w01 based on w0 and idS2 stored locally; generates a second blinding factor u; processes X1 using w01, u, and T to obtain X2, processes Y0 using w01 and u to obtain Y1, and obtains U based on u and L.

[0438] Where X2 = u * (X1 – w01 * T), Y1 = u * Y0 + w01 * N, and U = u * L.

[0439] Step 1008: The first server sends idS1, X2, Y1, U, and salt to the second server.

[0440] Where idS1, X2, Y1, U, and salt are the first auxiliary information.

[0441] Step 1009: The second server generates a third blinding factor v; processes Y1 using w00 and v to obtain Y2; generates a second blinding value R based on v; generates a secret information Z3 based on t, v, y1, and X2, and generates a secret information V3 based on v, y1, and U; generates a server MAC key h3 and a server session key k3 based on idC, idS2, idS1, X0, R, Y2, Z3, V3, salt, and w00; and generates mac1 based on h3 and X0.

[0442] Where Y2 = v * (Y1 + w00 * N), R = v * N, Z3 = (1 / t) * v * y1 * X2, V3 = v * y1 * U, k3||h3 = Hash(idC,idS2,idS1,X0,salt,R,Y2,Z3,V3,w00), and mac1 = MAC(h3,X0).

[0443] Step 1010: The second server sends mac1, idS2, idS1, R, Y2, and salt to the first client.

[0444] Step 1011: The first client generates a second private key w1 based on pw and salt, and generates w00 based on w0 and idS2; generates a secret information Z4 based on x1, Y2, w0, and R; generates a secret information V4 based on w1, Y2, w0, and R; generates a client MAC key h4 and a client session key k4 based on idC, idS2, idS1, X0, R, Y2, Z4, V4, salt, and w00; generates mac4 based on h4 and X0.

[0445] Wherein, Z4 = x1 * (Y2 – w0 * R), V4 = w1 * (Y2 – w0 * R), k4||h4 = Hash(idC, idS2, idS1, X0, salt, R, Y2, Z4, V4, w00), mac4 = MAC(h4, X0).

[0446] Step 1012: The first client compares mac4 and mac1. If mac4 is the same as mac1, the authentication of the second server passes, and mac2 is generated based on h4, R, Y2, and salt.

[0447] Wherein, mac2 = MAC(h4, salt||R||Y2).

[0448] Step 1013: The first client sends mac2 to the second server.

[0449] Step 1014: The second server generates mac3 based on h3, R, Y2, and salt.

[0450] Wherein, mac3 = MAC(h3, salt||R||Y2).

[0451] Step 1015: The second server compares mac3 and mac2. If mac3 and mac2 are the same, the authentication of the first client passes.

[0452] Step 1016: The second server returns a login success response to the first client.

[0453] As can be seen from the above Example 2, the difference between Example 2 and Example 1 is that the second private key is generated based on the random salt value provided by the first server. On this basis, in step 1008, the first auxiliary information sent by the first server includes salt. In step 1009, when generating h3 and k3, the second server adds salt as an input parameter. In step 1010, salt is added to the information transmitted by the second server to the first client. In steps 1011 to 1015, the first client calculates w1 using salt, and adds salt when calculating h4, k4, and mac2. The second server also adds salt correspondingly when calculating mac3. That is to say, what salt mainly affects is the calculation of w1 and the calculation of the MAC key and session key between the client and the server. In Example 2, the first server calculates w1 based on salt and pw, and enables the first client to calculate w1 by sending salt. This implementation method can be compatible with the traditional password authentication method that obtains w1 in the same way, thereby improving the applicability of the password authentication key exchange method provided in the embodiments of the present application.

[0454] Example 3:

[0455] The password verification information of the first account stored in the first server includes the first private key w0 and the public key L corresponding to the second private key w1, where w0 and w1 are calculated based on Formula 1, and L is calculated based on Formula 2. The first verification shard stored in the second server is L0, and L0 is calculated based on Formula 17. See Figure 11 , and this process includes the following steps:

[0456] Step 1101: In response to a login instruction, the first client obtains the first account idC and the first password pw input by the user.

[0457] Step 1102: The first client generates the first private key w0 and the second private key w1 based on pw, and generates the first PAKE parameter X0 based on w0 and the temporary private key x1 of the first client.

[0458] Among them, X0 = x1*P + w0*M.

[0459] Step 1103: The first client sends a login request to the second server, and this login request includes idC and X0.

[0460] Step 1104: The second server generates the second PAKE parameter Y0 based on the temporary private key y1 of the second server and the first verification shard.

[0461] Among them, Y0 = y1*P + L0.

[0462] Step 1105: The second server sends idC, idS2, X0, and Y0 to the first server.

[0463] Among them, idS2 is the identifier of the second server. The above information can be carried in the authentication assistance request.

[0464] Step 1106: The first server calculates L0 based on L and idS2 stored by itself; generates the second blinding factor u; processes X0 based on w0 and u to obtain X2, processes Y0 based on w0, L0, and u to obtain Y1, and obtains U based on u and L.

[0465] Among them, X2 = u * (X0 – w0 * M), Y1 = u * (Y0 – L0) + w0 * N, U = u * L.

[0466] Step 1107: The first server sends idS1, X2, Y1, and U to the second server.

[0467] Among them, idS1, X2, Y1, and U are the first auxiliary information.

[0468] Step 1108: The second server generates the secret information Z3 based on y1 and X2, generates the secret information V3 based on y1 and U; generates the server MAC key h3 and the server session key k3 based on idC, idS2, idS1, X0, Y1, Z3, V3, L0; generates mac1 based on h3 and X0.

[0469] Among them, Z3 = y1 * X2, V3 = y1 * U, k3||h3 = Hash(idC,idS2,idS1,X0,Y1,Z3,V3,L0), mac1 = MAC(h3,X0).

[0470] Step 1109: The second server sends mac1, idS2, idS1, and Y1 to the first client.

[0471] Step 1110: The first client generates L0 based on L and idS2; generates the secret information Z4 based on x1, Y1, and w0; generates the secret information V4 based on w1, Y1, and w0; generates the client MAC key h4 and the client session key k4 based on idC, idS2, idS1, X0, Y1, Z4, V4, L0; generates mac4 based on h4 and X0.

[0472] Among them, Z4 = x1 * (Y1 – w0 * N), V4 = w1 * (Y1 – w0 * N), k4||h4 = Hash(idC,idS2,idS1,X0,Y1,Z4,V4,L0), mac4 = MAC(h4,X0).

[0473] Step 1111: The first client compares mac4 and mac1. If mac4 is the same as mac1, the authentication of the second server passes, and based on h4 and Y1, mac2 is generated.

[0474] Among them, mac2 = MAC(h4, Y1).

[0475] Step 1112: The first client sends mac2 to the second server.

[0476] Step 1113: The second server generates mac3 based on h3 and Y1.

[0477] Among them, mac3 = MAC(h3, Y1).

[0478] Step 1114: The second server compares mac3 and mac2. If mac3 and mac2 are the same, the authentication of the first client passes.

[0479] Step 1115: The second server returns a login success response to the first client.

[0480] In Example 3, the first verification shard is generated based on the public key corresponding to the second private key. And in step 1104, when the second server calculates the second PAKE parameter Y0, the first verification shard is introduced. On this basis, the second server can no longer use the first verification shard to process X0. Correspondingly, since X0 does not contain the information of the first verification shard, the second server can directly transmit X0 to the first server without blinding X0. And although Y0 contains the information of the first verification shard, since a third party cannot intercept other information related to Y0 before Y0, it cannot obtain the first verification shard in Y0 either. Therefore, Y0 does not need to be blinded either. Similarly, the subsequent Y1 sent by the second server to the first client also does not need to be blinded, reducing the calculation amount of the second server. And since the second server does not perform blinding processing, the corresponding blinding value can not be transmitted, reducing the communication cost.

[0481] Example 4:

[0482] The password verification information of the first account stored in the first server includes the first private key w0 and the public key L corresponding to the second private key w1, where w0 and w1 are calculated based on formula 1, and L is calculated based on formula 2. The first verification shard stored in the second server is w10, and w10 is calculated based on formula 19 and formula 20. See Figure 12 , and this process includes the following steps:

[0483] Step 1201: In response to the login instruction, the first client obtains the first account ID C and the first password pw entered by the user.

[0484] Step 1202: The first client generates a first private key w0 and a second private key w1 based on pw, and generates a first PAKE parameter X0 based on w0 and the temporary private key x1 of the first client.

[0485] Where X0 = x1*P + w0*M.

[0486] Step 1203: The first client sends a login request to the second server, and the login request includes ID C and X0.

[0487] Step 1204: The second server generates a second PAKE parameter Y0 based on the temporary private key y1 of the second server.

[0488] Where Y0 = y1*P.

[0489] Step 1205: The second server sends ID C, ID S2, X0, and Y0 to the first server.

[0490] Where ID S2 is the identifier of the second server. The above information can be carried in the authentication assistance request.

[0491] Step 1206: The first server calculates the second verification shard w11 based on L and ID S2 stored in itself; generates a second blinding factor u; processes X0 based on w0 and u to obtain X2, processes Y0 based on w0 and u to obtain Y1, and obtains U based on u, w11, and L.

[0492] Where X2 = u*(X0 – w0*M), Y1 = u*Y0 + w0*N, and U = u*w11*L.

[0493] Step 1207: The first server sends ID S1, X2, Y1, and U to the second server.

[0494] Where ID S1, X2, Y1, and U are the first auxiliary information.

[0495] Step 1208: The second server generates a secret information Z3 based on y1 and X2, generates a secret information V3 based on y1, w10, and U; generates a server MAC key h3 and a server session key k3 based on ID C, ID S2, ID S1, X0, Y1, Z3, V3, w10; and generates mac1 based on h3 and X0.

[0496] Wherein, Z3 = y1 * X2, V3 = y1 * w10 * U, k3||h3 = Hash(idC, idS2, idS1, X0, Y1, Z3, V3, w10), mac1 = MAC(h3, X0).

[0497] Step 1209: The second server sends mac1, idS2, idS1, and Y1 to the first client.

[0498] Step 1210: The first client generates w10 based on L and idS2; generates the secret information Z4 based on x1, Y1, and w0; generates the secret information V4 based on w1, Y1, and w0; generates the client MAC key h4 and the client session key k4 based on idC, idS2, idS1, X0, Y1, Z4, V4, w10; generates mac4 based on h4 and X0.

[0499] Wherein, Z4 = x1 * (Y1 – w0 * N), V4 = w1 * (Y1 – w0 * N), k4||h4 = Hash(idC, idS2, idS1, X0, Y1, Z4, V4, w10), mac4 = MAC(h4, X0).

[0500] Step 1211: The first client compares mac4 and mac1. If mac4 is the same as mac1, the authentication of the second server passes, and mac2 is generated based on h4 and Y1.

[0501] Wherein, mac2 = MAC(h4, Y1).

[0502] Step 1212: The first client sends mac2 to the second server.

[0503] Step 1213: The second server generates mac3 based on h3 and Y1.

[0504] Wherein, mac3 = MAC(h3, Y1).

[0505] Step 1214: The second server compares mac3 and mac2. If mac3 and mac2 are the same, the authentication of the first client passes.

[0506] Step 1215: The second server returns a login success response to the first client.

[0507] In the fourth example, the first verification shard is also generated based on the public key corresponding to the second private key. On this basis, the second server can no longer use the first verification shard to process X0. Correspondingly, since X0 does not contain the information of the first verification shard, the second server can directly transmit X0 to the first server without blinding X0. Moreover, since Y0 also does not contain the information of the first verification shard, there is no need to blind Y0 either. Similarly, the subsequent Y1 sent by the second server to the first client also does not need to be blinded, reducing the computational amount of the second server. And since the second server does not perform blinding processing, the corresponding blinding value can be not transmitted, reducing the communication cost.

[0508] It should be noted that, in the above third and fourth examples, the second private key can also be calculated using the random salt value provided by the first server. In this case, the first auxiliary information sent by the first server and the information transmitted by the second server to the first client will both contain the random salt value. Moreover, when calculating their respective MAC keys and session keys, the second server and the first client can use the random salt value as an input parameter. When the first client calculates mac2 and the second server calculates mac3, the random salt value can also be added. The relevant implementation methods can refer to the relevant content about the random salt value in the second example.

[0509] Next, the password authentication key exchange device provided by the embodiments of the present application will be introduced.

[0510] Figure 13 is a schematic structural diagram of a password authentication key exchange device provided by the embodiments of the present application. This password authentication key exchange device can be deployed in the second server of the foregoing embodiments. Refer to Figure 13 The password authentication key exchange device 1300 may include: a receiving module 1301, a generating module 1302, and an authentication negotiation module 1303.

[0511] Among them, the receiving module 1301 is used to execute step 603a in the foregoing embodiments;

[0512] The generating module 1302 is used to execute step 603b in the foregoing embodiments;

[0513] The authentication negotiation module 1303 is used to execute 603c in the foregoing embodiments.

[0514] Optionally, the password verification information includes the public key corresponding to the second private key. The authentication negotiation module 1303 includes: a sending unit configured to send an authentication assistance request to the first server, where the authentication assistance request includes a first account, an identifier of the second server, a client PAKE parameter to be processed, and a second PAKE parameter, and the client PAKE parameter to be processed is obtained based on the first PAKE parameter; a receiving unit configured to receive first assistance information sent by the first server, where the first assistance information is obtained based on the password verification information, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter, and the first assistance information includes a first processed client PAKE parameter, a first processed server PAKE parameter, and public key information, and the public key information is obtained based on the public key corresponding to the second private key; an authentication negotiation unit configured to perform identity authentication and key negotiation with the first client based on the first assistance information and the first verification shard.

[0515] Optionally, the authentication negotiation unit is specifically configured to: obtain a second processed server PAKE parameter based on the first processed server PAKE parameter; generate a server session key and a server MAC key based on the first assistance information, the second processed server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter; generate a first MAC based on the server MAC key and the first PAKE parameter; and send the first MAC and second assistance information to the first client, where the second assistance information includes the identifier of the second server and the second processed server PAKE parameter.

[0516] Optionally, the password verification information further includes a first private key, and the first verification shard is obtained based on the identifier of the second server and the first private key; the authentication negotiation unit is further configured to: generate a third PAKE parameter based on the first verification shard and the first PAKE parameter; where the client PAKE parameter to be processed is the third PAKE parameter, and the first processed client PAKE parameter and the first processed server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter respectively based on a second verification shard of the password verification information, the second verification shard is generated based on the first private key and the identifier of the second server, and the second verification shard is different from the first verification shard.

[0517] Optionally, the authentication negotiation unit is specifically configured to: process the first PAKE parameter based on the first verification shard and the first blinding factor to obtain a third PAKE parameter, and generate a first blinding value based on the first blinding factor; where the authentication assistance request further includes the first blinding value, and the first processed client PAKE parameter is obtained by processing the third PAKE parameter based on the second verification shard and the first blinding value.

[0518] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on the second blinding factor, and the first processing client PAKE parameter and the first processing server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter based on the second check shard and the second blinding factor respectively.

[0519] Optionally, the authentication negotiation unit is specifically configured to: process the first processing server PAKE parameter based on the first check shard and the third blinding factor to obtain a second processing server PAKE parameter, and generate a second blinding value based on the third blinding factor, where the second auxiliary information further includes the second blinding value.

[0520] Optionally, the authentication negotiation unit is specifically configured to: generate a server secret information based on the third blinding factor, the first processing client PAKE parameter, the public key information, and the temporary private key of the second server; generate a server session key and a server MAC key based on the server secret information, the second processing server PAKE parameter, the first check shard, and the first PAKE parameter.

[0521] Optionally, the password verification information further includes a first private key, the first check shard is obtained based on the public key corresponding to the second private key and the identifier of the second server, the client PAKE parameter to be processed is the first PAKE parameter, and the first processing client PAKE parameter and the first processing server PAKE parameter are obtained by processing the first PAKE parameter and the second PAKE parameter based on the first private key respectively.

[0522] Optionally, the generating module 1302 is specifically configured to: generate a second PAKE parameter based on the temporary private key of the second server and the first check shard; where the first processing server PAKE parameter is obtained by processing the second PAKE parameter based on the first private key and the second check shard, and the second check shard is obtained based on the identifier of the second server and the public key corresponding to the second private key.

[0523] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on the second blinding factor, the first processing client PAKE parameter is obtained by processing the first PAKE parameter based on the first private key and the second blinding factor, and the first processing server PAKE parameter is obtained by processing the second PAKE parameter based on the first private key, the second blinding factor, and the second check shard.

[0524] Optionally, the authentication negotiation unit is specifically configured to: generate a server secret information based on the first processing client PAKE parameter, the public key information, and the temporary private key of the second server; generate a server session key and a server MAC key based on the server secret information, the second processing server PAKE parameter, the first check shard, and the first PAKE parameter.

[0525] Optionally, the public key information is obtained by processing the public key corresponding to the second private key based on the second blinding factor and the second check shard. The authentication negotiation unit is specifically configured to: generate server secret information based on the first check shard, the first processed client PAKE parameter, the public key information, and the temporary private key of the second server; generate a server session key and a server MAC key based on the server secret information, the second processed server PAKE parameter, the first check shard, and the first PAKE parameter.

[0526] Optionally, both the first auxiliary information and the second auxiliary information include a random salt value provided by the first server, and the second private key is generated based on the random salt value and the first password.

[0527] Optionally, the receiving unit is further configured to receive a second MAC sent by the first client. The second MAC is generated by the first client based on the client MAC key and the second processed server PAKE parameter after the identity authentication of the second server based on the first MAC. The client MAC key is generated based on the second auxiliary information, the temporary private key of the first client, the password verification information, and the first PAKE parameter. The authentication negotiation unit is further configured to generate a third MAC based on the server MAC key and the second processed server PAKE parameter; perform identity authentication on the first client based on the second MAC and the third MAC.

[0528] Optionally, the apparatus further includes a sending module 1304. The receiving module 1301 is further configured to receive a federated registration request sent by the first client. The federated registration request includes a first account number and a fourth PAKE parameter, and the fourth PAKE parameter is generated based on the first password and the temporary private key of the first client. The sending module 1304 is configured to send the federated registration request and the identifier of the second server to the first server. The first server is configured to perform identity authentication with the first client using the PAKE protocol based on the first account number and the fourth PAKE parameter. The receiving module 1301 is further configured to receive and store the first account number and the first check shard sent by the first server after the identity authentication with the first client is successful. The sending module 1304 is further configured to send a registration success response to the first client.

[0529] Figure 14 It is a schematic structural diagram of another password authentication key exchange apparatus provided by an embodiment of the present application. The password authentication key exchange apparatus can be deployed in the first client of the foregoing embodiment. Refer to Figure 14 As shown in the figure, the password authentication key exchange apparatus 1400 may include: an acquisition module 1401, a generation module 1402, and an authentication negotiation module 1403.

[0530] The acquisition module 1401 is configured to execute step 601 in the foregoing embodiment;

[0531] The generation module 1402 is used to execute step 602 in the foregoing embodiment;

[0532] The authentication negotiation module 1403 is used to execute step 603 in the foregoing embodiment.

[0533] Optionally, the authentication negotiation module 1403 includes:

[0534] A sending unit, configured to send a login request to the second server, where the login request includes a first account number and a first PAKE parameter;

[0535] A receiving unit, configured to receive a first MAC and second auxiliary information sent by the second server, where the second auxiliary information includes an identifier of the second server and a second processing server PAKE parameter, the first MAC is generated based on a server MAC key and the second processing server PAKE parameter, and the server MAC key is generated based on the first auxiliary information, the second processing server PAKE parameter, a temporary private key of the second server, a first check fragment of the password verification information of the first account number, and the first PAKE parameter;

[0536] A generating unit, configured to generate a client session key and a client MAC key based on the second auxiliary information, the password verification information of the first account number, a temporary private key of the first client, and the first PAKE parameter; generate a fourth MAC based on the client MAC key and the first PAKE parameter;

[0537] An authentication unit, configured to perform identity authentication on the second server based on the first MAC and the fourth MAC.

[0538] Optionally, the generating unit is further configured to generate a second MAC based on the client MAC key and the second processing server PAKE parameter after the identity authentication of the second server passes;

[0539] The sending unit is further configured to send the second MAC to the second server.

[0540] Optionally, the apparatus further includes a sending module 1404 and a receiving module 1405, and the obtaining module 1401 is further configured to obtain a first account number and a first password input by a user in response to a registration instruction;

[0541] The generating module 1402 is further configured to generate a fourth PAKE parameter based on the first password and a temporary private key of the first client;

[0542] A sending module 1404, configured to send a federated registration request to the first server through the second server, where the federated registration request includes the first account number and the fourth PAKE parameter, and the first account number and the fourth PAKE parameter are used for identity authentication with the first server;

[0543] A receiving module 1405, configured to receive a registration success response sent by a second server after passing authentication with a first server.

[0544] Figure 15 Another password authentication key exchange device provided by an embodiment of the present application. This password authentication key exchange device can be deployed in the first server of the foregoing embodiment. Refer to Figure 15 , the password authentication key exchange device 1500 may include: a receiving module 1501, a processing module 1502, and a sending module 1503.

[0545] The receiving module 1501 is configured to execute step 603c1 in the foregoing embodiment;

[0546] The processing module 1502 is configured to execute step 603c2 in the foregoing embodiment;

[0547] The sending module 1503 is configured to execute step 603c3 in the foregoing embodiment.

[0548] Optionally, the processing module 1502 is specifically configured to: generate a second verification shard based on the password verification information and the identifier of the second server; obtain first auxiliary information based on the password verification information, the second verification shard, the client PAKE parameter to be processed, and the second PAKE parameter.

[0549] Optionally, the password verification information further includes a first private key. Both the first verification shard and the second verification shard are generated based on the identifier of the second server and the first private key, and the second verification shard is different from the first verification shard. The processing module 1502 is specifically configured to: process the client PAKE parameter to be processed and the second PAKE parameter respectively based on the second verification shard and the second blinding factor to obtain a first processed client PAKE parameter and a first processed server PAKE parameter; generate public key information based on the public key corresponding to the second private key and the second blinding factor.

[0550] Optionally, both the first verification shard and the second verification shard are generated based on the identifier of the second server and the public key corresponding to the second private key.

[0551] Optionally, the processing module 1502 is specifically configured to: process the client PAKE parameter to be processed and the second PAKE parameter respectively based on the first private key and the second blinding factor to obtain a first processed client PAKE parameter and a first processed server PAKE parameter; generate public key information based on the second blinding factor, the second verification shard, and the public key corresponding to the second private key.

[0552] Optionally, the password verification information further includes a first private key. The second verification shard is the same as the first verification shard. The processing module 1502 is specifically configured to: process the client PAKE parameter to be processed based on the first private key and the second blinding factor to obtain a first processed client PAKE parameter; process the second PAKE parameter based on the first private key, the second verification shard, and the second blinding factor to obtain a first processed server PAKE parameter; generate public key information based on the public key corresponding to the second private key and the second blinding factor.

[0553] Optionally, the first auxiliary information further includes a random salt value, and the second private key is generated based on the random salt value and the first password.

[0554] It should be noted that the division of modules in the various password authentication key exchange devices provided in the above embodiments is illustrative. It is only a logical function division. In actual implementation, there may be other division methods. In addition, in each embodiment of the present application, each functional module may be integrated in a processor, may exist separately physically, or two or more modules may be integrated into one module. The above integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0555] If the above integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, may be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device or a processor to execute all or part of the steps of the embodiments of the present application. The foregoing storage medium includes: various media such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc that can store program codes.

[0556] In addition, the password authentication key device provided in the above embodiment and the embodiment of the password authentication key method belong to the same concept. The specific implementation process and the corresponding beneficial effects can be found in detail in the method embodiment, and will not be repeated here.

[0557] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a digital versatile disc (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0558] In various embodiments of the present application, if there is no special description and logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments according to their internal logical relationships. In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent the cases of A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the written description of the embodiments of the present application, the character " / " generally represents an "or" relationship between the associated objects before and after. In the present application, "first", "second", etc. and various numerical numbers are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. For example, to distinguish different messages, etc., rather than to describe a specific order or sequence.

[0559] It should be understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The magnitudes of the serial numbers of the above processes do not mean the sequence of execution, and the execution sequence of each process should be determined by its function and internal logic.

[0560] Finally, it should be noted that the above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A password authentication key exchange method, characterized in that, the method includes: receiving a login request sent by a first client, the login request including a first account number and a first PAKE parameter, the first PAKE parameter being generated based on a first password corresponding to the first account number and a temporary private key of the first client, the first account number and the first password being the account number and password registered in a first server; generating a second PAKE parameter based on a temporary private key of a second server; performing identity authentication and key negotiation with the first client based on the first account number, the first PAKE parameter, the second PAKE parameter, and a first verification shard stored in the second server, the first verification shard being allocated by the first server for the second server based on an identifier of the second server and password verification information of the first account number.

2. The method according to claim 1, characterized in that, the password verification information includes a public key corresponding to a second private key, and the performing identity authentication and key negotiation with the first client based on the first account number, the first PAKE parameter, the second PAKE parameter, and the first verification shard stored in the second server includes: sending an authentication assistance request to the first server, the authentication assistance request including the first account number, the identifier of the second server, a client PAKE parameter to be processed, and the second PAKE parameter, the client PAKE parameter to be processed being obtained based on the first PAKE parameter; receiving first assistance information sent by the first server, the first assistance information being obtained based on the password verification information, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter, the first assistance information including a first processed client PAKE parameter, a first processed server PAKE parameter, and public key information, the public key information being obtained based on the public key corresponding to the second private key; performing identity authentication and key negotiation with the first client based on the first assistance information and the first verification shard.

3. The method according to claim 2, characterized in that, the performing identity authentication and key negotiation with the first client based on the first assistance information and the first verification shard includes: obtaining a second processed server PAKE parameter based on the first processed server PAKE parameter; generating a server session key and a server MAC key based on the first assistance information, the second processed server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter; generating a first MAC based on the server MAC key and the first PAKE parameter; sending the first MAC and second assistance information to the first client, the second assistance information including the identifier of the second server and the second processed server PAKE parameter.

4. The method according to claim 3, characterized in that, The password verification information further includes a first private key, and the first verification shard is obtained based on the identifier of the second server and the first private key; the method further includes: Generating a third PAKE parameter based on the first verification shard and the first PAKE parameter; Wherein, the to-be-processed client PAKE parameter is the third PAKE parameter, and the first processed client PAKE parameter and the first processed server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter respectively based on a second verification shard of the password verification information. The second verification shard is generated based on the first private key and the identifier of the second server, and the second verification shard is different from the first verification shard.

5. The method according to claim 4, wherein, The generating the third PAKE parameter based on the first verification shard and the first PAKE parameter includes: Processing the first PAKE parameter based on the first verification shard and a first blinding factor to obtain the third PAKE parameter, and generating a first blinding value based on the first blinding factor; Wherein, the authentication assistance request further includes the first blinding value, and the first processed client PAKE parameter is obtained by processing the third PAKE parameter based on the second verification shard and the first blinding value.

6. The method according to claim 4 or 5, wherein, The public key information is obtained by processing the public key corresponding to the second private key based on a second blinding factor, and the first processed client PAKE parameter and the first processed server PAKE parameter are obtained by processing the third PAKE parameter and the second PAKE parameter respectively based on the second verification shard and the second blinding factor.

7. The method according to any one of claims 3 to 6, wherein, The obtaining the second processed server PAKE parameter based on the first processed server PAKE parameter includes: Processing the first processed server PAKE parameter based on the first verification shard and a third blinding factor to obtain the second processed server PAKE parameter, and generating a second blinding value based on the third blinding factor. Wherein, the second auxiliary information further includes the second blinding value.

8. The method according to claim 7, wherein, The generating the server session key and the server MAC key based on the first auxiliary information, the second processed server PAKE parameter, the temporary private key of the second server, the first verification shard, and the first PAKE parameter includes: Generating a server secret information based on the third blinding factor, the first processed client PAKE parameter, the public key information, and the temporary private key of the second server; Generating the server session key and the server MAC key based on the server secret information, the second processed server PAKE parameter, the first verification shard, and the first PAKE parameter.

9. The method according to claim 3, It is characterized in that, the password verification information further includes a first private key, the first verification shard is obtained based on the public key corresponding to the second private key and the identifier of the second server, the client PAKE parameter to be processed is the first PAKE parameter, and the first processed client PAKE parameter and the first processed server PAKE parameter are obtained by processing the first PAKE parameter and the second PAKE parameter respectively based on the first private key.

10. The method according to claim 9, it is characterized in that, generating the second PAKE parameter based on the ephemeral private key of the second server includes: generating the second PAKE parameter based on the ephemeral private key of the second server and the first verification shard; wherein, the first processed server PAKE parameter is obtained by processing the second PAKE parameter based on the first private key and a second verification shard, and the second verification shard is the same as the first verification shard.

11. The method according to claim 10, it is characterized in that, the public key information is obtained by processing the public key corresponding to the second private key based on a second blinding factor, the first processed client PAKE parameter is obtained by processing the first PAKE parameter based on the first private key and the second blinding factor, and the first processed server PAKE parameter is obtained by processing the second PAKE parameter based on the first private key, the second blinding factor and the second verification shard.

12. The method according to claim 11, it is characterized in that, generating the server session key and the server MAC key based on the first auxiliary information, the second processed server PAKE parameter, the ephemeral private key of the second server, the first verification shard and the first PAKE parameter includes: generating the server secret information based on the first processed client PAKE parameter, the public key information and the ephemeral private key of the second server; generating the server session key and the server MAC key based on the server secret information, the first verification shard, the second processed server PAKE parameter and the first PAKE parameter.

13. The method according to claim 9, it is characterized in that, the public key information is obtained by processing the public key corresponding to the second private key based on a second blinding factor and a second verification shard, the second verification shard is obtained based on the public key corresponding to the second private key and the identifier of the second server, and the second verification shard is different from the first verification shard; generating the server session key and the server MAC key based on the first auxiliary information, the second processed server PAKE parameter, the ephemeral private key of the second server, the first verification shard and the first PAKE parameter includes: generating the server secret information based on the first verification shard, the first processed client PAKE parameter, the public key information and the ephemeral private key of the second server; Generate the server session key and the server MAC key based on the server secret information, the first verification shard, the second processing server PAKE parameter, and the first PAKE parameter.

14. The method according to any one of claims 3 to 13, wherein, both the first auxiliary information and the second auxiliary information include a random salt value provided by the first server, and the second private key is generated based on the random salt value and the first password.

15. The method according to any one of claims 3 to 14, wherein, the method further includes: receiving a second MAC sent by the first client, where the second MAC is generated by the first client based on the client MAC key and the second processing server PAKE parameter after the identity authentication of the second server based on the first MAC is passed, and the client MAC key is generated based on the second auxiliary information, the temporary private key of the first client, the password verification information, and the first PAKE parameter; generating a third MAC based on the server MAC key and the second processing server PAKE parameter; performing identity authentication on the first client based on the second MAC and the third MAC.

16. The method according to any one of claims 1 to 15, wherein, the method further includes: receiving a federated registration request sent by the first client, where the federated registration request includes the first account number and a fourth PAKE parameter, and the fourth PAKE parameter is generated based on the first password and the temporary private key of the first client; sending the federated registration request and the identifier of the second server to the first server, where the first server is used to perform identity authentication with the first client based on the first account number and the fourth PAKE parameter; receiving and storing the first account number and the first verification shard sent by the first server after the identity authentication with the first client is passed; sending a registration success response to the first client.

17. A password authentication key exchange method, wherein, the method includes: responding to a login instruction, obtaining a first account number and a first password input by a user, where the first account number and the first password are the account number and password registered in the first server; generating a first PAKE parameter based on the first password and the temporary private key of the first client; performing identity authentication and key negotiation with a second server based on the first account number and the first PAKE parameter.

18. The method according to claim 17, wherein, the performing identity authentication and key negotiation with a second server based on the first account number and the first PAKE parameter includes: sending a login request to the second server, where the login request includes the first account number and the first PAKE parameter; Receive the first MAC and the second auxiliary information sent by the second server, where the second auxiliary information includes the identifier of the second server and the second processing server PAKE parameter, and the first MAC is generated based on the server MAC key and the first PAKE parameter, and the server MAC key is generated based on the first auxiliary information, the second processing server PAKE parameter, the temporary private key of the second server, the first check shard of the password verification information of the first account, and the first PAKE parameter; Generate a client session key and a client MAC key based on the second auxiliary information, the password verification information of the first account, the temporary private key of the first client, and the first PAKE parameter; Generate a fourth MAC based on the client MAC key and the first PAKE parameter; Authenticate the second server based on the first MAC and the fourth MAC.

19. The method according to claim 18, wherein, the method further includes: After the authentication of the second server is passed, generate a second MAC based on the client MAC key and the second processing server PAKE parameter; Send the second MAC to the second server.

20. The method according to any one of claims 17 to 19, wherein, the method further includes: In response to a registration instruction, obtain the first account and the first password input by the user; Generate a fourth PAKE parameter based on the first password and the temporary private key of the first client; Send a federated registration request to the first server through the second server, where the federated registration request includes the first account and the fourth PAKE parameter, and the first account and the fourth PAKE parameter are used for authentication with the first server; After passing the authentication with the first server, receive a registration success response sent by the second server.

21. A password authentication key exchange method, wherein, the method includes: Receive an authentication auxiliary request sent by the second server, where the authentication auxiliary request includes a first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter provided by the second server, the first account is an account registered in the first server, and the client PAKE parameter to be processed is obtained based on the first PAKE parameter provided by the first client; Obtain first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter, where the first auxiliary information includes a first processing client PAKE parameter, a first processing server PAKE parameter, and public key information, and the public key information is obtained based on the public key corresponding to the second private key in the password verification information; Send the first auxiliary information to the second server, which is used to perform identity authentication and key negotiation with the first client based on the first auxiliary information and the first verification shard, and the first verification shard is allocated for the second server based on the identifier of the second server and the password verification information.

22. The method according to claim 21, wherein, the obtaining of the first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter includes: generating a second verification shard based on the password verification information and the identifier of the second server; obtaining the first auxiliary information based on the password verification information, the second verification shard, the client PAKE parameter to be processed, and the second PAKE parameter.

23. The method according to claim 22, wherein, the password verification information further includes a first private key, both the first verification shard and the second verification shard are generated based on the identifier of the second server and the first private key, and the second verification shard is different from the first verification shard; the obtaining of the first auxiliary information based on the password verification information, the second verification shard, the client PAKE parameter to be processed, and the second PAKE parameter includes: processing the client PAKE parameter to be processed and the second PAKE parameter respectively based on the second verification shard and the second blinding factor to obtain the first processed client PAKE parameter and the first processed server PAKE parameter; generating the public key information based on the public key corresponding to the second private key and the second blinding factor.

24. The method according to claim 22, wherein, both the first verification shard and the second verification shard are generated based on the identifier of the second server and the public key corresponding to the second private key.

25. The method according to claim 24, wherein, the password verification information further includes a first private key, the second verification shard is different from the first verification shard, and the obtaining of the first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter includes: processing the client PAKE parameter to be processed and the second PAKE parameter respectively based on the first private key and the second blinding factor to obtain the first processed client PAKE parameter and the first processed server PAKE parameter; generating the public key information based on the second blinding factor, the second verification shard, and the public key corresponding to the second private key.

26. The method according to claim 24, wherein, The password verification information further includes a first private key, the second verification shard is the same as the first verification shard, and obtaining the first auxiliary information based on the password verification information of the first account, the identifier of the second server, the client PAKE parameter to be processed, and the second PAKE parameter includes: Processing the client PAKE parameter to be processed based on the first private key and the second blinding factor to obtain the first processed client PAKE parameter; Processing the second PAKE parameter based on the first private key, the second verification shard, and the second blinding factor to obtain the first processed server PAKE parameter; Generating the public key information based on the public key corresponding to the second private key and the second blinding factor.

27. The method according to any one of claims 21 to 26, wherein, the first auxiliary information further includes a random salt value, and the second private key is generated based on the random salt value and the first password corresponding to the first account.

28. A password authentication key exchange device, wherein, the device includes at least one module, and the at least one module is configured to execute the password authentication key exchange method according to any one of claims 1 to 27.

29. A computer device, wherein, the computer device includes a processor, and the processor is configured to execute at least one program instruction or code stored in a memory to implement the password authentication key exchange method according to any one of claims 1 to 27.

30. A computer-readable storage medium, wherein, instructions are stored in the computer-readable storage medium, and when the instructions run on a computer device, the computer device is caused to execute the password authentication key exchange method according to any one of claims 1 to 27.

Images