Bidirectional authentication method and device, electronic equipment and storage medium

Abstract

The invention relates to the field of information security, and provides a bidirectional authentication method and device, electronic equipment and a storage medium. The method comprises the following steps: reading and analyzing a current certificate file associated with current login user information to obtain current bidirectional authentication data, and storing the current bidirectional authentication data in a first cache region, the current bidirectional authentication data comprising a current client root certificate and a current client checkout object; initiating a network request to the server, and receiving a server check object returned by the server in response to the network request; reading the current client root certificate from the first cache region, and verifying the server verification object by using the current client root certificate; if the verification of the server verification object is passed, reading the current client verification object from the first cache region and sending the current client verification object to the server; and if a verification passing message fed back by the server is received, completing a bidirectional authentication process for the network request. According to the invention, the bidirectional authentication time can be effectively shortened, and the operation efficiency and stability of the system are improved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a two-way authentication method, device, electronic device and storage medium. Background Art

[0002] In a two-way authentication scenario, when a client initiates a network request, not only does the client need to verify the identity of the server, but the server also needs to verify the identity of the client to ensure that both parties are legitimate before starting to exchange data. Since network requests can be concurrent, the client and server need to perform a two-way authentication process for each concurrent network request. For the client, only by completing the two-way authentication process in the shortest possible time can the system be guaranteed to run efficiently and stably.

[0003] The traditional two-way authentication process involves many detailed operations (for example, the client reads the certificate, imports, binds, verifies, etc.), and these detailed operations are a time-consuming process. In the case of multiple concurrent network requests, if the client needs to execute the traditional two-way authentication process for each network request, then each network request will require such a long wait, which can easily lead to interface timeouts, occasional system crashes, and occasional authentication failures and request cancellations when the client requests the server, thereby affecting the system's operating efficiency and stability.

[0004] Therefore, it is urgent to solve the problem of how to reasonably optimize the traditional two-way authentication process to shorten the time of two-way authentication and thus improve the operating efficiency and stability of the system. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a two-way authentication method, device, electronic device and storage medium to solve the problem of how to reasonably optimize the traditional two-way authentication process to shorten the time of two-way authentication, thereby improving the operating efficiency and stability of the system.

[0006] A first aspect of an embodiment of the present application provides a two-way authentication method, including:

[0007] Acquire the current login user information, and if the current login user information is inconsistent with the historical login user information, clear the historical two-way authentication data associated with the historical login user information in the first buffer area; wherein the historical two-way authentication data includes the historical client root certificate and the historical client verification object;

[0008] Read the current certificate file associated with the currently logged-in user information;

[0009] Parse the current certificate file to obtain current two-way authentication data, and store the current two-way authentication data in the first buffer area, where the current two-way authentication data includes the current client root certificate and the current client verification object;

[0010] Initiate a network request to the server, and receive a server verification object returned by the server in response to the network request;

[0011] Read the current client root certificate from the first buffer area, and use the current client root certificate to verify the server verification object;

[0012] If the server verification object passes the verification, the current client verification object is read from the first buffer area and sent to the server;

[0013] If a verification pass message is received from the server for the current client verification object, the two-way authentication process for the network request is completed.

[0014] A second aspect of an embodiment of the present application provides a two-way authentication device, including:

[0015] an acquisition module configured to acquire current login user information, and if the current login user information is inconsistent with the historical login user information, clear the historical two-way authentication data associated with the historical login user information in the first buffer area; wherein the historical two-way authentication data includes the historical client root certificate and the historical client verification object;

[0016] A reading module is configured to read a current certificate file associated with currently logged-in user information;

[0017] A parsing module is configured to parse the current certificate file to obtain current two-way authentication data and store the current two-way authentication data in a first buffer area, wherein the current two-way authentication data includes a current client root certificate and a current client verification object;

[0018] The request module is configured to initiate a network request to the server and receive a server verification object returned by the server in response to the network request;

[0019] A verification module is configured to read the current client root certificate from the first buffer area and verify the server verification object using the current client root certificate;

[0020] A sending module, configured to read the current client verification object from the first buffer area and send it to the server if the server verification object passes the verification;

[0021] The receiving module is configured to complete the two-way authentication process for the network request if a verification pass message fed back by the server for the current client verification object is received.

[0022] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0023] According to a fourth aspect of an embodiment of the present application, a readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0024] Compared with the prior art, the beneficial effects of the embodiment of the present application include at least: before the client initiates a network request to the server, first determine whether the current login user information is consistent with the historical login user information. If not, clear the historical two-way authentication data associated with the historical login user information in the first cache area, and then read the current certificate file associated with the current login user information; then, parse the current certificate file to obtain the current two-way authentication data, and then store the current two-way authentication data in the first cache area. In this way, on the one hand, it can ensure that the client only retains the current two-way authentication data required for the subsequent two-way authentication process, which can effectively prevent the problem of confusion in the certificate binding server verification object, thereby preventing the problem of occasional verification failure; on the other hand, it can effectively solve the problem of dirty reading and writing errors of certificate files caused by concurrent multi-threaded read and write operations. In addition, by pre-storing the current two-way authentication data (including the current client root certificate and the current client verification object) required for subsequent two-way authentication in the first cache area before initiating a network request, when a network request is subsequently initiated, the current client root certificate required for verifying the server verification object and the current client verification object that needs to be sent to the server after the server verification object is verified can be directly read from the first cache area, which can effectively shorten the time for client two-way authentication, improve interface timeouts, and occasional system crashes, thereby improving the system's operating efficiency and stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0026] Figure 1 It is a schematic diagram of an application scenario of an embodiment of the present application;

[0027] Figure 2 It is a flowchart of a two-way authentication method provided in an embodiment of the present application;

[0028] Figure 3 It is a schematic diagram of a flow chart of filling original data variables provided in an embodiment of the present application;

[0029] Figure 4 It is a flow chart of filling original data variables and certificate array variables provided by an embodiment of the present application;

[0030] Figure 5 It is another flow chart of filling original data variables and certificate array variables provided in an embodiment of the present application;

[0031] Figure 6 It is a structural diagram of a type of layer provided in an embodiment of the present application;

[0032] Figure 7 It is a structural diagram of a variable layer provided in an embodiment of the present application;

[0033] Figure 8 is a schematic diagram of a two-way authentication device provided in an embodiment of the present application;

[0034] Fig. 9 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0036] A two-way authentication method and device according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0037] Figure 1 1 is a schematic diagram of an application scenario of an embodiment of the present application. The application scenario may include a client 101 and a server 102.

[0038] The client 101 can be hardware or software. When the client 101 is hardware, it can be various electronic devices that support communication with the server 102, including but not limited to smart phones, tablet computers, laptops and desktop computers, smart cars, etc. When the client 101 is software, it can be installed in the above electronic devices. As an example, the client 101 can be a car control APP (application) installed on a smart phone.

[0039] The server 102 may be a server that provides various services. Specifically, the server 102 may be a single server, a server cluster consisting of several servers, or a cloud computing service center. This embodiment of the present application does not limit this.

[0040] It should be noted that the server 102 can be hardware or software. The specific types, quantities and combinations of the client 101 and the server 102 can be adjusted according to the actual needs of the application scenario, and the embodiments of the present application do not limit this.

[0041] A communication connection may be established between the client 101 and the server 102 via a network (such as a wired network or a wireless network).

[0042] In a two-way authentication scenario, the overall process of two-way authentication between the client and the server is as follows:

[0043] 1) The client 101 initiates a network request (such as an HTTP request, etc.) to the server 102.

[0044] 2) In response to the network request, the server 102 returns a server check object to the client 101. In the iOS system, the server 102 can obtain the server check object by calling the system property of the proxy function. The sample code is as follows: server check object = challenge.protectionSpace.serverTrust.

[0045] 3) When receiving the server verification object, the client 101 formulates a verification strategy and binds the verification strategy to the server verification object. In the iOS system, the client 101 can obtain the verification strategy by calling the system function. For example, an x509 strategy can be obtained by calling the system function SecPolicyCreateBasicX509. Furthermore, the client 101 can bind the verification strategy to the server verification object by calling the system function: public func SecTrustSetPolicies(_trust:SecTrust,_policies:CFTypeRef)->OSStatus; parameter 1 passes in the server verification object, and parameter 2 passes in the newly generated verification strategy (i.e., x509 strategy).

[0046] 4) The client 101 first reads the p12 file (the certificate file for network request two-way authentication) from the hard disk or pre-installed package. The read p12 file is a binary file, which is called Data (in Swift language) or NSData (in Objective-C language) in the iOS system. Then, the p12 file is parsed to obtain the client root certificate and the client verification object. Exemplarily, the client 101 can call the system-provided function SecPKCS12Import: public func SecPKCS12Import(_pkcs12_data:CFData,_options:CFDictionary,_items:UnsafeMutablePointer<CFArray?> )->OSStatus; The parameters passed into this function include: the first parameter is the binary data of the p12 file; the second parameter is the setting item, which includes the file export password of the p12 file; the third parameter is the reference parameter, that is, the parsed data structure.

[0047] 5) The client 101 associates (binds) the client root certificate with the server verification object, that is, loads the client root certificate into the system and associates the client root certificate with the server verification object. Exemplarily, the client 101 can call the system function: public func SecTrustSetAnchorCertificates(_trust:SecTrust,_anchorCertificates:CFArray?)->OSStatus; the parameters passed into the function include: the server verification object and the root certificate array corresponding to the client root certificate.

[0048] Public func SecTrustSetAnchorCertificatesOnly(_trust:SecTrust,_anchorCertificatesOnly:Bool)->OSStatus.

[0049] 6) The client 101 calls the verification function to verify the server verification object. Exemplarily, the client 101 may call the verification function SecTrustEvaluateWithError provided by the system, or its variant function (synchronous or asynchronous function), to verify the server verification object.

[0050] In one example, the synchronization function may be:

[0051] public func SecTrustEvaluateWithError(_trust:SecTrust,_error:UnsafeMutablePointer<CFError?> ? )->Bool, the parameters passed into this function include: parameter 1 (server verification object) and parameter 2 (error message in case of error).

[0052] Since the server verification object has been bound to the client root certificate and the verification policy in the above steps 3) and 5), during the actual verification, only the server verification object needs to be passed in.

[0053] The return value of the above synchronization function is a Bool value (Boolean value), true means the verification passed, false means the verification failed.

[0054] 7) If the return value of the synchronization function in step 6) is true, it means that the server verification object has passed, and the client 101 sends the client verification object to the server 102.

[0055] 8) After receiving the client verification object, the server 102 verifies the client verification object and returns the verification result to the client 101.

[0056] 9) If the verification result returned by the server 102 to the client 101 is that the verification is passed, the two-way authentication process between the client 101 and the server 102 ends, and the two parties begin to exchange data.

[0057] The inventor of the present application discovered in the long-term practice of the client two-way authentication project that: since network requests can be concurrent, if the client 101 initiates m network requests (m is an integer greater than 1), then these m network requests are repeating all the steps of the above-mentioned two-way authentication process, and are cross-cutting, so the SecPKCS12Import function will be called multiple times. Since the data is the same, the system is prone to occasional crashes due to the influence of concurrency. In addition, in the above-mentioned two-way authentication process, the client 101 reads the certificate, imports, binds, verifies and other operations, which is a time-consuming process. If such a long wait is required for each network request, it is easy to cause the problem of interface timeout.

[0058] Usually, after a user logs in to the client, he or she will perform many business operations, including but not limited to two-way authentication operations, etc., and the above two-way authentication process has the following problems: after the user logs in to the client 101, on the one hand, the client 101 deletes the local p12 file, and on the other hand, the client 101 initiates a network request to read the local p12 file list to obtain one of the p12 files (theoretically only one). This concurrent multi-threaded reading and writing, if not locked to protect the data, is prone to dirty reading, writing errors and other problems. In addition, depending on the specific deployment plan, the above operations either call the system method or call the tool library provided by the third-party authority, but the outside world cannot determine whether these operations are locked and whether the lock is effective. Therefore, this may cause the system to crash on the system function call that should not crash, or crash in the report display abnormality, exceeding the certificate array index, etc. In addition, if the certificate used by the client to verify the server verification object is a dirty read p12 file, rather than the correct p12 file that participates in the subsequent verification, it is likely to cause the verification to fail occasionally.

[0059] Normally, a client will connect to multiple servers. If a client uses different certificates for two-way authentication for each server, then when executing the two-way authentication process for each server concurrently, there is a high probability that the certificate binding to the server verification object will be confused, resulting in occasional verification failures. For example, if a client connects to server A and server B, and a set of certificates A is used for two-way authentication for server A, and a set of certificates B is used for two-way authentication for server B, then when the client concurrently executes the two-way authentication process for server A and server B, it is very likely that certificate A will be bound to server verification object B of server B, and certificate B will be bound to server verification object A of server A, which will cause occasional verification failures.

[0060] Based on this, the embodiment of the present application proposes a two-way authentication method, which is applied to the client. Before the client initiates a network request to the server, the method first determines whether the current login user information is consistent with the historical login user information. If not, the historical two-way authentication data associated with the historical login user information in the first cache area is cleared, and then the current certificate file associated with the current login user information is read; then, the current certificate file is parsed to obtain the current two-way authentication data, and then the current two-way authentication data is stored in the first cache area. In this way, on the one hand, it can ensure that the client's local only retains the current two-way authentication data required for the subsequent two-way authentication process, which can effectively prevent the problem of confusion in the certificate binding server verification object, thereby preventing the problem of occasional verification failure; on the other hand, it can effectively solve the problem of dirty reading and writing errors of certificate files caused by concurrent multi-threaded read and write operations. In addition, by pre-storing the current two-way authentication data (including the current client root certificate and the current client verification object) required for subsequent two-way authentication in the first cache area before initiating a network request, when a network request is subsequently initiated, the current client root certificate required for verifying the server verification object and the current client verification object that needs to be sent to the server after the server verification object is verified can be directly read from the first cache area, which can effectively shorten the time for client two-way authentication, improve interface timeouts, and occasional system crashes, thereby improving the system's operating efficiency and stability.

[0061] Figure 2 It is a flowchart of a two-way authentication method provided in an embodiment of the present application. Figure 2 The two-way authentication method can be Figure 1 The client 101 executes. Figure 2 As shown, the two-way authentication method includes the following steps:

[0062] Step S201, obtaining the current logged-in user information. If the current logged-in user information is inconsistent with the historical logged-in user information, clearing the historical two-way authentication data associated with the historical logged-in user information in the first cache area; wherein the historical two-way authentication data includes the historical client root certificate and the historical client verification object.

[0063] The currently logged-in user information refers to the user information of the user who is currently (this time) logged in to the client. The user information includes a unique identifier, which may be a User ID or the like.

[0064] Historical login user information refers to the user information of the user who last logged in to the client.

[0065] In some embodiments, login is a service that can be used to distinguish the certificate system required for the two-way authentication process between the client and the server. For example, after a user logs in to a client (e.g., a vehicle control APP (application)), the client can obtain the user information (e.g., user ID) entered by the user, and the user information can be used to identify and distinguish the client.

[0066] For car control APP, user information is more important, so user information can be obtained by logging into the car control APP to distinguish the client, as well as the certificate system required for the two-way authentication process between the client and the server.

[0067] In other implementations, other services may be used to distinguish the certificate systems required to be used in the two-way authentication process between the client and the server.

[0068] In some other implementations, the server may also assign a client identifier to the client, or use other unique identifiers (such as a device code, etc.) to distinguish the clients.

[0069] In one example, assuming that the current login user information obtained by the client is user information A, and the historical login user information read locally is user information B, after comparing user information A with user information B, it is found that the two are inconsistent, then the historical two-way authentication data associated with user information B in the first cache area is cleared.

[0070] In another example, first, if the client obtains the current login user information but does not read the historical login user information locally, there is no need to skip the step of clearing the historical two-way authentication data associated with the historical login user information in the first cache area, and directly jump to step S202.

[0071] The first cache area may be a memory area set in the client. The first cache area is mainly used to store user information and the two-way authentication data associated therewith. In terms of implementation, the cache structure includes but is not limited to variables in the memory, cache pool key-value pairs, and other methods.

[0072] Step S202, reading the current certificate file associated with the currently logged-in user information.

[0073] After the user logs in, the network request two-way authentication between the client and the server usually uses a p12 file issued by a third-party authority.

[0074] Before the user logs in, the network request mutual authentication between the client and the server uses a temporary certificate file.

[0075] In some embodiments, a temporary certificate file can be obtained by the following steps: generating a pair of public-private keys as a client key pair, the key pair including a client public key and a client private key; obtaining a server public key sent by the server, and using the server public key to generate a server certificate; and generating a temporary certificate file based on the server certificate and the client private key.

[0076] For example, assuming that the name of the "temporary certificate file" is: my_certificate.crt; the name of the client private key is: my_private_key.key, then the my_keystore.p12 command used to generate a p12 file is as follows: openssl pkcs12-export-out my_keystore.p12-inkey my_private_key.key-in my_certificate.crt.

[0077] The temporary certificate file contains two parts, one is the client root certificate used by the client to verify the server's verification object; the other is the client verification object provided by the client to the server. These two parts can be stored as 1 p12 file + 1 client root certificate. Preferably, both parts can be stored in one p12 file, so that there are fewer files and it is easier to download, store and manage.

[0078] Temporary certificate files and p12 files are generally stored as pre-installed files in the pre-installed package, that is, the bundle developed by iOS. The structure of temporary certificate files is the same as that of p12 files issued by third-party authorities.

[0079] In this step, the current certificate file read by the client is a binary file.

[0080] Step S203, parse the current certificate file to obtain current two-way authentication data, and store the current two-way authentication data in the first buffer area, where the current two-way authentication data includes the current client root certificate and the current client verification object.

[0081] Step S204: initiate a network request to the server, and receive a server verification object returned by the server in response to the network request.

[0082] Step S205, reading the current client root certificate from the first buffer area, and using the current client root certificate to verify the server verification object.

[0083] Step S206: If the server verification object passes the verification, the current client verification object is read from the first buffer area and sent to the server.

[0084] Step S207: If a verification pass message is received from the server for the current client verification object, the two-way authentication process for the network request is completed.

[0085] The technical solution provided by the embodiment of the present application obtains the current certificate file associated with the currently logged-in user information before the client initiates a network request to the server, parses it to obtain the current two-way authentication data, and stores the current two-way authentication data in the first cache area. On the one hand, it can ensure that the client's local computer only retains the current two-way authentication data required for the subsequent two-way authentication process, which can effectively prevent the problem of confusion in the certificate binding server verification object, thereby preventing the problem of occasional verification failure; on the second hand, it can effectively solve the problem of dirty reading and writing errors of certificate files due to concurrent multi-threaded read and write operations; on the third hand, it can effectively shorten the time of client two-way authentication, improve the problem of interface timeout and occasional system crash, thereby improving the operating efficiency and stability of the system.

[0086] In some embodiments, if the client obtains the current login user information of the client as user information 01, and the historical login user information of the last login to the client read locally is user information 01, that is, the current login user information is consistent with the historical login user information, then there is no need to clean up the historical two-way authentication data in the first cache area. When initiating a network request later, the historical client root certificate can be directly read from the first cache area to verify the server verification object, and after the server verification object is verified, the historical client verification object is read from the first cache area and sent to the server. After receiving the verification pass message returned by the server, the two-way authentication process for the network request is completed, and the two parties begin data exchange. In this way, the time consumption of two-way authentication between the client and the server can be shortened, which is conducive to improving the performance and stability of the system.

[0087] In other embodiments, when the user logs out of the client, the current two-way authentication data in the first buffer can be cleared. The next time the user logs in to the client, the client can directly jump to step S202 after obtaining the user information.

[0088] In some embodiments, parsing the current certificate file to obtain current two-way authentication data and storing the current two-way authentication data in the first buffer area includes:

[0089] Calling the first public acquisition function to determine whether the original data variable in the first buffer area is empty;

[0090] If the original data variable is empty, the first private filling variable function is called to extract the current client root certificate and the current client verification object from the current certificate file;

[0091] Fill the current client root certificate and the current client verification object into the raw data variable.

[0092] Figure 3 It is a flowchart of filling original data variables provided in an embodiment of the present application.

[0093] See also Figure 3 ,First, define a private variable, namely the original data variable, which is used to store the current client root certificate and the current client verification object. The initial value of the original data variable is empty.

[0094] The type of the original data variable can be customized, and its member variables contain all the data, as shown below:

[0095] / / / A custom structure to store the specific information required for two-way authentication:

[0096] struct IdentityAndTrust{

[0097] / / / In two-way authentication, one of the verification objects given to the server for verification is the ID of the local certificate, that is, "the identity extracted from the p12 file".

[0098] var identityRef:SecIdentity?

[0099] / / / In two-way authentication, one of the verification objects given to the server for verification is the local certificate array, which is "the chain extracted from the p12 file".

[0100] var certArray:AnyObject?

[0101] / / / In two-way authentication, verify the local authenticity of the server certificate: the root certificate, which is the first one in the "trust" array extracted from the p12 file, that is, the root certificate.

[0102] var clientCertRoot:CFData?

[0103] / / / In two-way authentication, verify the local certificate of the server certificate: the secondary certificate, which is the second in the "trust extracted from the p12 file" array, that is, the secondary certificate.

[0104] var clientCertSub:CFData?

[0105] }.

[0106] In the first public acquisition function facing the outside world, write: determine whether the original data variable is empty; if not, return; if it is empty, execute the steps of filling the original data variable.

[0107] Then, the first public acquisition function is called to determine whether the original data variable in the first buffer is empty. If the original data variable is empty, the first private filling variable function is called to extract the current client root certificate and the current client verification object from the current authentication file (p12 file). The current client root certificate and the current client verification object are filled into the original data variable.

[0108] By encapsulating the steps of filling the original data variable into a first private filling variable function, after obtaining the current certificate file, extracting the current client root certificate and the current client verification object from the current certificate file and filling them into the original data variable, various information of the current certificate file can be directly stored in the client's memory. In the subsequent two-way authentication process, the current client root certificate and the current client verification object required can be directly read from the first cache area without repeatedly parsing the current certificate file, which is conducive to shortening the overall time of the two-way authentication process, improving the problems of interface timeout and occasional system crashes, thereby improving the system's operating efficiency and stability.

[0109] In some embodiments, the raw data variables include a first variable and a second variable;

[0110] Fill the current client root certificate and the current client verification object into the raw data variable, including:

[0111] Call the second public acquisition function to determine whether the first variable is empty;

[0112] If the first variable is empty, the second private fill variable function is called to convert the current client root certificate into a root certificate array;

[0113] Fill the root certificate array into the first variable and fill the current client verification object into the second variable.

[0114] The current client root certificate is used when the client verifies the server's certificate object, and it takes a certain amount of time to load the original data variable into a certificate array, so a cache can be made for the current client root certificate to further shorten the overall time of the two-way authentication process.

[0115] In the second public acquisition function for the outside world, write: determine whether the first variable (ie, the certificate array variable) is empty; if it is not empty, return; if it is empty, execute the step of filling the first variable (certificate array variable).

[0116] Figure 4It is a flowchart of filling original data variables and certificate array variables provided in an embodiment of the present application. Figure 5 This is another flowchart diagram of filling original data variables and certificate array variables provided in an embodiment of the present application.

[0117] See also Figure 4 and Figure 5 First, when the original data variable is empty, call the first private filling variable function to obtain the current client root certificate and the current client verification object, and then fill the current client root certificate and the current client verification object into the original data variable (PKIIdentityAndTrustData). Then, when the first variable is empty, call the second private filling variable function to convert the binary current client root certificate into a root certificate array that can be directly used by the system, and then fill the root certificate array into the first variable (clientCertArray). Fill the current client verification object into the second variable.

[0118] Each element in the binary current client root certificate (trust array) is of type CFData, which cannot be used directly by the system. Therefore, the client can call the system function:

[0119] public func SecCertificateCreateWithData(_allocator:CFAllocator?,_data:CFData)->SecCertificate?

[0120] Convert each element in the binary current client root certificate into a corresponding certificate, and then put these certificates back into an array to obtain a root certificate array.

[0121] The second private filling variable function of the certificate array variable (first variable) uses the return value of the first private filling variable function of the original data variable, that is, the relationship between the certificate array variable and the original data variable is: the certificate array variable depends on the original data variable.

[0122] Since the second private filling variable function of the certificate array variable calls the first public acquisition function of the original data variable, it will internally determine whether the variable has a value. If there is no value, it will execute the filling step, and the filling will only be performed once. Therefore, no matter when the second public acquisition function corresponding to the certificate array variable and the first public acquisition function corresponding to the original data variable are called externally, and no matter which one comes first or later, there will be no problems.

[0123] The current client verification object, including the identity and chain extracted from the current certificate file.

[0124] In actual applications, when a network request occurs, the client can directly call the second public acquisition function of the certificate array variable, extract its member variable certificate array variable from its return value, and verify the server verification object; after the verification is passed, the client can directly call the first public acquisition function of the original data variable, extract its member variables identityRef and certArray from its return value, and submit it to the server. In this way, the overall time consumption of the two-way authentication process can be effectively shortened, thereby improving the operating efficiency and stability of the system.

[0125] In some implementations, when the client (such as a vehicle control APP) is started, when the user logs in, or when the user logs out, a cache cleanup call may be made to determine whether the caches have values. If so, the caches must be cleaned first.

[0126] For example, you can directly assign the "original data variable" and "certificate array variable" to empty. The sample code is as follows:

[0127] / / / Clean up: certificate data used for two-way authentication (client authentication)

[0128] private func clearCachedCertData(){

[0129] clientCertArray=nil

[0130] PKIIdentityAndTrustData=nil

[0131] }.

[0132] After assigning the values ​​of "original data variable" and "certificate array variable" to empty, when the outside needs to call them, the first public acquisition function and the second public acquisition function will be called. When they are found to be empty, the above process will be re-executed to extract the current client root certificate and the current client verification object from the latest certificate file (that is, the current certificate file), and convert the current client root certificate into a root certificate array, and then fill it into the "original data variable" and "certificate array variable".

[0133] In some embodiments, reading a current certificate file associated with currently logged-in user information includes:

[0134] Determine the file reading path and file export password;

[0135] Read the current certificate file associated with the currently logged-in user information according to the file reading path and the file export password.

[0136] Before reading the current certificate file or temporary certificate file, the client needs to determine the file reading path of the current certificate file or temporary certificate file. The file reading paths of the current certificate file and temporary certificate file are usually different. In addition, the file reading paths used may also be different depending on the business environment, the connected server, etc. Therefore, if the file reading path of the current certificate file or temporary certificate file is simply hard-coded in the code, it is easy for attackers to obtain it, thereby increasing the risk of certificate file leakage or attack by attackers.

[0137] Based on this, this application has made some improvements to the solution for determining the file reading path.

[0138] In some implementations, determining a file reading path includes:

[0139] Obtaining a configuration file, wherein the configuration file includes at least two conditional layer variables and one data layer variable, each conditional layer variable forms a top-bottom layer relationship, each conditional layer variable stores at least one conditional object, and the data layer variable stores data corresponding to each conditional object;

[0140] Call the third-party library or the first system function to obtain the condition entity corresponding to each condition layer variable and the data entity corresponding to the data layer variable;

[0141] The file reading path and the file export password are determined according to the upper and lower layer relationships between the conditional layer variables, the conditional entities corresponding to the conditional layer variables, and the data entities corresponding to the data layer variables.

[0142] As an example, assume that the configuration conditions related to the file reading path of the current certificate file (p12 file) include the environment and the server connected to the client, where the environment includes the development environment, the test environment, and the production environment; the servers connected to the client include server A, server B, and server C. The file reading path of the current certificate file can be designed with the environment as the upper layer and the server as the lower layer, as follows:

[0143] In the development environment, the file reading path of the current certificate file (hereinafter referred to as the p12 file) is as follows:

[0144] ①The path of the p12 file pre-installed package used by Server A is: p12-Dev-A-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-A-Bundle.p12".

[0145] ②The p12 file sandbox path used by server A is: p12-Dev-A-Sandbox, and the specific value is: " / var / mobile / xx / sandbox / p12-Dev-A-Sandbox.p12".

[0146] ③The path of the p12 pre-installed package used by server B is: p12-Dev-B-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-B-Bundle.p12".

[0147] ④The p12 sandbox path used by server B is: p12-Dev-B-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-B-Sandbox.p12".

[0148] ⑤The path of the p12 pre-installed package used by server C is: p12-Dev-C-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-C-Bundle.p12".

[0149] ⑥The p12 sandbox path used by server C is: p12-Dev-C-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-C-Sandbox.p12".

[0150] In the test environment, the file reading path of the current certificate file (the p12 file below) is as follows:

[0151] ⑦The path of the p12 pre-installed package used by Server A is: p12-Test-A-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Test-A-Bundle.p12".

[0152] ⑧The p12 sandbox path used by server A is: p12-Test-A-Sandbox, and the specific value is: " / var / mobile / xx / sandbox / p12-Test-A-Sandbox.p12".

[0153] ⑨The path of the p12 pre-installed package used by server B is: p12-Test-B-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Test-B-Bundle.p12".

[0154] ⑩The p12 sandbox path used by server B is: p12-Test-B-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Test-B-Sandbox.p12".

[0155] The path of the p12 pre-installed package used by server C is: p12-Test-C-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Test-C-Bundle.p12".

[0156] The p12 sandbox path used by server C is: p12-Test-C-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Test-C-Sandbox.p12".

[0157] In a production environment, the file reading path of the current certificate file (the p12 file below) is as follows:

[0158] The path of the p12 pre-installed package used by Server A is: p12-Produce-A-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-A-Bundle.p12".

[0159] The p12 sandbox path used by server A is: p12-Produce-A-Sandbox, and the specific value is: " / var / mobile / xx / sandbox / p12-Produce-A-Sandbox.p12".

[0160] The path of the p12 pre-installed package used by server B is: p12-Produce-B-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-B-Bundle.p12".

[0161] The p12 sandbox path used by server B is: p12-Produce-B-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-B-Sandbox.p12".

[0162] The path of the p12 pre-installed package used by server C is: p12-Produce-C-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-C-Bundle.p12".

[0163] The p12 sandbox path used by server C is: p12-Produce-C-Sandbox, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-C-Sandbox.p12".

[0164] As another example, the file reading path of the current certificate file can be designed with the server as the upper layer and the environment as the lower layer. The following is an example of designing the file reading path of the current certificate file (p12 file) with server A as the upper layer and the environment as the lower layer.

[0165] When server A is the upper layer and the environment is the lower layer, the file reading path of the current certificate file (hereinafter referred to as p12 file) is as follows:

[0166] The path of the p12 file pre-installed package used in the development environment is: p12-Dev-A-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-A-Bundle.p12".

[0167] The p12 file sandbox path used in the development environment is: p12-Dev-A-Sandbox, and the specific value is: " / var / mobile / xx / Sandbox / p12-Dev-A-Sandbox.p12".

[0168] The path of the p12 file pre-installed package used in the test environment is: p12-Test-A-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Dev-A-Bundle.p12".

[0169] The p12 file sandbox path used in the test environment is: p12-Test-A-Sandbox, and the specific value is: " / var / mobile / xx / Sandbox / p12-Dev-A-Sandbox.p12".

[0170] The path of the p12 file pre-installed package used in the production environment is: p12-ProduceA-Bundle, and the specific value is: " / var / mobile / xx / bundle / p12-Produce-A-Bundle.p12".

[0171] The p12 file sandbox path used in the production environment is: p12-Produce-A-Sandbox, and the specific value is: " / var / mobile / xx / Sandbox / p12-Produce-A-Sandbox.p12".

[0172] Based on the above, the steps to determine the file reading path may be:

[0173] First, a file is generated, and configuration conditions related to the file reading path are stored in the file according to a certain structure (such as a dictionary) to obtain a configuration file. The configuration conditions include but are not limited to the environment, server, and other conditions determined according to business needs.

[0174] Then, using the lazy loading mode, define a lazy loading variable in the program. The variable type structure of this variable is consistent with the configuration file.

[0175] Figure 6 It is a structural diagram of a type of layer provided in an embodiment of the present application. Figure 7 It is a structural diagram of a variable layer provided in an embodiment of the present application.

[0176] See also Figure 6 and Figure 7 , the number of conditional layer variables is determined according to the number of configuration conditions in the configuration file, wherein the number of configuration conditions is the same as the number of conditional layer variables. Each conditional layer variable forms an upper and lower layer relationship, and the last layer is the data layer variable, which is used to store the data corresponding to each conditional object. In combination with the above example, the configuration conditions include the environment and the server, then the conditional layer variables include the conditional layer variable 1 corresponding to the environment, and the conditional layer variable 2 corresponding to the server. If the file structure of the configuration file is based on the environment as the upper layer and the server as the lower layer, then the conditional layer variable corresponding to the environment can be called "variable-upper layer type", and the conditional layer variable corresponding to the server can be called "variable-lower layer type". The last layer is the data layer variable (which can be called "variable-data layer type"), which combines each layer of conditional layer variables.

[0177] The variable-upper type can store at least one condition object, for example, it can include three condition objects: development environment, test environment and production environment:

[0178] struct LocalPKIAccessKeyEnvironmentModel:HandyJSON{

[0179] / / / Development environment

[0180] var dev:LocalPKIAccessKeyValueModel=.init()

[0181] / / / Test environment

[0182] var test:LocalPKIAccessKeyValueModel=.init()

[0183] / / / Production environment

[0184] var prod:LocalPKIAccessKeyValueModel=.init()

[0185] }.

[0186] The variable-lower-layer type can store at least one condition object, for example, it can include three condition objects: TSP server (server A), operation platform server (server B), and big data server (server C):

[0187] struct LocalPKIAccessKeyValueModel:HandyJSON{

[0188] / / / TSP server

[0189] var prod:LocalServerModel=.init()

[0190] / / / Operation platform server

[0191] var uat:LocalServerModel=.init()

[0192] / / / Big Data Server (Server C)

[0193] var test:LocalServerModel=.init()

[0194] }.

[0195] The layer type of the data layer variable is specific data, which can be called variable-data layer type.

[0196] Each conditional layer variable stores at least one conditional object. For example, the conditional layer variable 1 corresponding to the environment (conditional class) includes three environments: development environment, test environment, and production environment, so it stores three conditional objects: development environment, test environment, and production environment. For another example, the conditional layer variable 2 corresponding to the server (conditional class) includes server A, server B, and server C, so it stores three conditional objects: server A, server B, and server C.

[0197] After the client obtains the configuration file (in binary format), it can convert the configuration file into entity conditions corresponding to each conditional layer variable and entity data corresponding to the data layer variable by calling a third-party library or the first system function (such as the system function that comes with iOS). Then, each entity condition is filled into the corresponding conditional layer variable, and each entity data is filled into the corresponding data layer variable. In this way, the values ​​of each configuration item in the configuration file can be directly stored in the client memory, further reducing the overall time consumption of the client's two-way authentication process.

[0198] It is worth noting that the configuration file cache does not need to be cleared.

[0199] In some embodiments, the file export password can be stored in the variable-data layer type, provided that the configuration of the file export password function and the file reading path of the p12 file are substantially consistent.

[0200] For example, struct LocalServerModel:HandyJSON{

[0201] / / / This is the path

[0202] var p12Path:String=""

[0203] / / / This is the export password

[0204] var passcode:String=""

[0205] }.

[0206] In some embodiments, reading the current client root certificate from the first cache area and verifying the server verification object using the current client root certificate includes:

[0207] Call the second system function and pass in the server verification object and root certificate array;

[0208] The third system function is called, and the server verification object and associated parameters are passed in. The associated parameters are used to indicate the association relationship between the server verification object and the root certificate array.

[0209] As an example, the client may call the second system function: public funcSecTrustSetAnchorCertificates(_trust:SecTrust, _anchorCertificates:CFArray?)->OSStatus, where the first parameter passed into the function is the server certificate object, and the second parameter is the root certificate array.

[0210] In order to improve system performance and prevent the system from loading more but unnecessary certificates, the third system function can be further called: public func SecTrustSetAnchorCertificatesOnly(_trust:SecTrust,_anchorCertificatesOnly:Bool)->OSStatus, the first parameter passed to the function is the server verification object, and the second parameter is the associated parameter, that is, true. The purpose of passing in the associated parameter is to use only the root certificate array associated with the function just passed in when verifying the server verification object, without the need to verify additional certificates in the system.

[0211] In some embodiments, reading a current certificate file corresponding to the currently logged-in user information includes:

[0212] Clear the historical certificate files corresponding to the historical login user information;

[0213] Sending a certificate acquisition request to the server, the certificate acquisition request including the current logged-in user information, so that the server clears the historical certificate files corresponding to the historical logged-in user information in its second cache area;

[0214] If the current certificate file corresponding to the currently logged-in user information returned by the server in response to the certificate acquisition request is not received, then read the pre-stored temporary certificate file;

[0215] The temporary certificate file is determined as the backup certificate file, and the thread is restarted to initiate a certificate acquisition request to the server again until the current certificate file corresponding to the currently logged-in user information is successfully obtained.

[0216] As an example, after detecting that the current user has logged in, the client obtains the current logged-in user information. If the current logged-in user information is inconsistent with the historical logged-in user information of the last time the client logged in, the historical certificate file corresponding to the historical logged-in user information is cleared. The client uses the current logged-in user information as a parameter, selects an encryption method (such as an RSA encryption algorithm), sets a password and a key length, generates a certificate application file (hereinafter referred to as a p10 file), and then sends a certificate acquisition request to the server, the certificate acquisition request including the p10 file. After receiving the certificate acquisition request, the server extracts the p10 file in the certificate acquisition request, decrypts the p10 file, and obtains the current logged-in user information; compares the current logged-in user information with the historical logged-in user information to see if they are consistent. If they are inconsistent, the historical certificate file corresponding to the historical logged-in user information in the second cache area is cleared.

[0217] If the user fails to obtain the current certificate file corresponding to the currently logged-in user information due to reasons such as failure to extract data, failure to parse, or failure to import SecPKCS12Import after logging in to the client, the pre-stored temporary certificate file can be used as a backup certificate file to perform the subsequent two-way authentication process. At the same time, the client restarts the thread and initiates a certificate acquisition request to the server again until the current certificate file corresponding to the currently logged-in user information is successfully obtained. After obtaining the current certificate file, the two-way authentication process of subsequent network requests will use the current certificate file.

[0218] Through the above solution, even if the current certificate file corresponding to the current logged-in user information fails to be obtained due to reasons such as failure to extract data, failure to parse, and failure to import SecPKCS12Import, the two-way authentication process can still be performed normally, thereby avoiding the phenomenon that the authentication process is stagnant or fails due to the client's failure to obtain the current certificate file.

[0219] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present application, which will not be described one by one here.

[0220] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0221] Figure 8 Schematic diagram of a two-way authentication device provided in an embodiment of the present application. Figure 8 As shown, the two-way authentication device includes:

[0222] The acquisition module 801 is configured to acquire the current login user information, and if the current login user information is inconsistent with the historical login user information, clear the historical two-way authentication data associated with the historical login user information in the first buffer area; wherein the historical two-way authentication data includes the historical client root certificate and the historical client verification object;

[0223] The reading module 802 is configured to read the current certificate file associated with the current logged-in user information;

[0224] The parsing module 803 is configured to parse the current certificate file to obtain current two-way authentication data and store the current two-way authentication data in the first buffer area, wherein the current two-way authentication data includes the current client root certificate and the current client verification object;

[0225] The request module 804 is configured to initiate a network request to the server and receive a server verification object returned by the server in response to the network request;

[0226] The verification module 805 is configured to read the current client root certificate from the first buffer area and verify the server verification object using the current client root certificate;

[0227] The sending module 806 is configured to read the current client verification object from the first buffer area and send it to the server if the server verification object passes the verification;

[0228] The receiving module 807 is configured to complete the two-way authentication process for the network request if a verification pass message fed back by the server for the current client verification object is received.

[0229] In some embodiments, the above-mentioned parsing module 803 includes:

[0230] A calling unit is configured to call a first common acquisition function to determine whether the original data variable in the first buffer area is empty;

[0231] an extraction unit, configured to call a first private fill variable function to extract a current client root certificate and a current client verification object from a current authentication file if the original data variable is empty;

[0232] The filling unit is configured to fill the current client root certificate and the current client verification object into the original data variable.

[0233] In some embodiments, the raw data variables include a first variable and a second variable.

[0234] The above-mentioned filling unit comprises:

[0235] A first calling component is configured to call a second public acquisition function to determine whether the first variable is empty;

[0236] A second calling component is configured to call a second private filling variable function to convert the current client root certificate into a root certificate array if the first variable is empty;

[0237] The filling component is configured to fill the root certificate array into the first variable and fill the current client verification object into the second variable.

[0238] In some embodiments, the reading module 802 includes:

[0239] A determination unit, configured to determine a file reading path and a file export password;

[0240] The first reading unit is configured to read a current certificate file associated with the current login user information according to a file reading path and a file export password.

[0241] In some embodiments, the reading unit includes:

[0242] An acquisition component is configured to acquire a configuration file, wherein the configuration file includes at least two conditional layer variables and one data layer variable, each conditional layer variable forms a top-bottom layer relationship, each conditional layer variable stores at least one conditional object, and the data layer variable stores data corresponding to each conditional object;

[0243] A calling component is configured to call a third-party library or a first system function to obtain a condition entity corresponding to each condition layer variable and a data entity corresponding to the data layer variable;

[0244] The path determination component is configured to determine the file reading path according to the upper and lower layer relationships between the conditional layer variables, the conditional entities corresponding to the conditional layer variables, and the data entities corresponding to the data layer variables.

[0245] In some embodiments, the verification module 805 includes:

[0246] The first calling unit is configured to call the second system function and pass in the server verification object and the root certificate array;

[0247] The second calling unit is configured to call the third system function, and pass in the server verification object and associated parameters, where the associated parameters are used to indicate the association relationship between the server verification object and the root certificate array.

[0248] In some embodiments, the reading module 802 further includes:

[0249] a clearing unit configured to clear historical certificate files corresponding to historical login user information;

[0250] A sending unit is configured to send a certificate acquisition request to the server, wherein the certificate acquisition request includes the current logged-in user information, so that the server clears the historical certificate file corresponding to the historical logged-in user information in its second buffer area;

[0251] The second reading unit is configured to read a pre-stored temporary certificate file if the current certificate file corresponding to the current logged-in user information returned by the server in response to the certificate acquisition request is not received;

[0252] The request unit is configured to determine the temporary certificate file as a backup certificate file, reopen the thread, and initiate a certificate acquisition request to the server again until the current certificate file corresponding to the current logged-in user information is successfully acquired.

[0253] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0254] Fig. 9 Schematic diagram of an electronic device 9 provided in an embodiment of the present application. Fig. 9 As shown, the electronic device 9 of this embodiment includes: a processor 901, a memory 902, and a computer program 903 stored in the memory 902 and executable on the processor 901. When the processor 901 executes the computer program 903, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 901 executes the computer program 903, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0255] The electronic device 9 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 9 may include, but is not limited to, a processor 901 and a memory 902. Those skilled in the art will appreciate that Fig. 9 The electronic device 9 is merely an example and does not limit the electronic device 9 , and may include more or less components than those shown in the figure, or different components.

[0256] The processor 901 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0257] The memory 902 may be an internal storage unit of the electronic device 9, for example, a hard disk or memory of the electronic device 9. The memory 902 may also be an external storage device of the electronic device 9, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 9. The memory 902 may also include both an internal storage unit of the electronic device 9 and an external storage device. The memory 902 is used to store computer programs and other programs and data required by the electronic device.

[0258] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0259] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0260] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A two-way authentication method, characterized in that: include: Acquire the current logged-in user information, and if the current logged-in user information is inconsistent with the historical logged-in user information, clear the historical two-way authentication data associated with the historical logged-in user information in the first cache area; wherein the historical two-way authentication data includes the historical client root certificate and the historical client verification object; Reading the current certificate file associated with the currently logged-in user information; Parsing the current certificate file to obtain current two-way authentication data, and storing the current two-way authentication data in the first buffer area, wherein the current two-way authentication data includes a current client root certificate and a current client verification object; Initiate a network request to a server, and receive a server verification object returned by the server in response to the network request; Read the current client root certificate from the first buffer area, and use the current client root certificate to verify the server verification object; If the server verification object passes the verification, the current client verification object is read from the first buffer area and sent to the server; If a verification pass message is received from the server for the current client verification object, the two-way authentication process for the network request is completed.

2. The method according to claim 1, characterized in that Parsing the current certificate file to obtain current two-way authentication data, and storing the current two-way authentication data in the first buffer area, includes: Calling a first public acquisition function to determine whether the original data variable in the first buffer area is empty; If the original data variable is empty, calling the first private filling variable function to extract the current client root certificate and the current client verification object from the current certificate file; The current client root certificate and the current client verification object are filled into the original data variable.

3. The method according to claim 2, characterized in that The original data variables include a first variable and a second variable; Filling the current client root certificate and the current client verification object into the original data variable includes: Calling a second public acquisition function to determine whether the first variable is empty; If the first variable is empty, calling the second private fill variable function to convert the current client root certificate into a root certificate array; The root certificate array is filled into the first variable, and the current client verification object is filled into the second variable.

4. The method according to claim 1, characterized in that: Reading the current certificate file associated with the currently logged-in user information includes: Determine the file reading path and file export password; According to the file reading path and the file export password, the current certificate file associated with the currently logged-in user information is read.

5. The method according to claim 4, characterized in that Determine the file reading path, including: Obtaining a configuration file, wherein the configuration file includes at least two conditional layer variables and one data layer variable, each of the conditional layer variables forms a top-bottom layer relationship, each of the conditional layer variables stores at least one conditional object, and the data layer variable stores data corresponding to each of the conditional objects; Calling a third-party library or a first system function to obtain the condition entities corresponding to each of the condition layer variables and the data entities corresponding to the data layer variables; The file reading path is determined according to the upper and lower layer relationships between the conditional layer variables, the conditional entities corresponding to the conditional layer variables, and the data entities corresponding to the data layer variables.

6. The method according to claim 3, characterized in that Reading the current client root certificate from the first cache area, and using the current client root certificate to verify the server verification object, includes: Call the second system function, passing in the server verification object and the root certificate array; The third system function is called to pass in the server verification object and associated parameters, where the associated parameters are used to indicate the association relationship between the server verification object and the root certificate array.

7. The method according to claim 1, characterized in that Reading the current certificate file corresponding to the currently logged-in user information includes: Clearing the historical certificate files corresponding to the historical login user information; Sending a certificate acquisition request to the server, wherein the certificate acquisition request includes the current logged-in user information, so that the server clears the historical certificate file corresponding to the historical logged-in user information in its second cache area; If the current certificate file corresponding to the currently logged-in user information returned by the server in response to the certificate acquisition request is not received, reading a pre-stored temporary certificate file; The temporary certificate file is determined as a backup certificate file, and the thread is reopened to initiate a certificate acquisition request to the server again until the current certificate file corresponding to the current logged-in user information is successfully acquired.

8. A two-way authentication device, characterized in that: include: an acquisition module configured to acquire current login user information, and if the current login user information is inconsistent with the historical login user information, clear the historical two-way authentication data associated with the historical login user information in the first cache area; wherein the historical two-way authentication data includes a historical client root certificate and a historical client verification object; A reading module, configured to read a current certificate file associated with the currently logged-in user information; A parsing module is configured to parse the current certificate file to obtain current two-way authentication data, and store the current two-way authentication data in the first buffer area, wherein the current two-way authentication data includes a current client root certificate and a current client verification object; A request module, configured to initiate a network request to a server, and receive a server verification object returned by the server in response to the network request; A verification module, configured to read the current client root certificate from the first cache area, and use the current client root certificate to verify the server verification object; a sending module, configured to read the current client verification object from the first buffer area and send it to the server if the server verification object passes the verification; The receiving module is configured to complete the two-way authentication process for the network request if a verification pass message fed back by the server for the current client verification object is received.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images