Two-way authentication method, device, electronic device and storage medium

Abstract

The present application relates to the field of information security, and provides a two-way authentication method, device, electronic device and storage medium. The method includes: reading the current certificate file associated with the current logged-in user information and parsing it to obtain the current two-way authentication data, and storing the current two-way authentication data in the first cache area, the current two-way authentication data including the current client root certificate and the current client verification object; initiating a network request to the server, receiving the server verification object returned by the server in response to the network request; reading the current client root certificate from the first cache area, and using the current client root certificate to verify the server verification object; if the server verification object passes the verification, then reading the current client verification object from the first cache area and sending it to the server; if the verification pass message is received from the server, then completing the two-way authentication process for the network request. The present application can effectively shorten the time of two-way authentication and improve the operating efficiency and stability of the system.

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, both the client and the server must verify their identity to ensure both parties are legitimate before data exchange begins. Because network requests can be concurrent, both the client and server must perform a two-way authentication process for each concurrent request. For the client, completing the two-way authentication process in the shortest possible time ensures efficient and stable system operation.

[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 perform 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 bidirectional authentication method, including:

[0007] 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 buffer; 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] 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, the current two-way authentication data including the current client root certificate and the current client verification object;

[0010] Initiate a network request to the server and receive the 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 verify the server verification object using the current client root certificate;

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

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

[0014] A second aspect of the embodiments of the present application provides a bidirectional authentication device, including:

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

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

[0017] a parsing module 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 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 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. 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 the following: 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 subsequently initiating a network request, 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. This 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 following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. 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 any creative work.

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

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

[0028] Figure 3 This is a flow chart of filling raw data variables provided by an embodiment of the present application;

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

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

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

[0032] Figure 7 This is a schematic diagram of the structure 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] Figure 9 This is a structural 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 and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may 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 avoid obscuring the description of the present application with unnecessary detail.

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

[0037] Figure 1 FIG1 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] Client 101 can be either hardware or software. If client 101 is hardware, it can be any electronic device that supports communication with server 102, including but not limited to smartphones, tablets, laptops, desktop computers, smart cars, etc. If client 101 is software, it can be installed in any of the aforementioned electronic devices. As an example, client 101 can be a car control app (application program) installed on a smartphone.

[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 impose any restrictions on this.

[0040] It should be noted that the server 102 can be hardware or software. The specific type, quantity and combination of the client 101 and the server 102 can be adjusted according to the actual needs of the application scenario, and the embodiment of the application does 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) to the server 102.

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

[0045] 3) Upon receiving the server verification object, the client 101 formulates a verification policy and binds the verification policy to the server verification object. In the iOS system, the client 101 can obtain the verification policy by calling a system function. For example, an x509 policy can be obtained by calling the system function SecPolicyCreateBasicX509. Furthermore, the client 101 can bind the verification policy 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 policy (i.e., x509 policy).

[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 format 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. For example, 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) Client 101 associates (binds) the client root certificate with the server's anchor, that is, loads the client root certificate into the system and associates the client root certificate with the server's anchor. For example, client 101 can call the system function: public func SecTrustSetAnchorCertificates(_trust:SecTrust, _anchorCertificates:CFArray?)->OSStatus; the parameters passed to this function include the server's anchor 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. For example, the client 101 can 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 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 verification 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 inventors of this application discovered during the long-term practice of the client-side 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 performed crosswise, 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 interface timeout problem.

[0058] Typically, after logging into a client, a user will perform many business operations, including but not limited to two-way authentication. However, the aforementioned two-way authentication process presents the following issues: After logging into client 101, client 101 deletes its local p12 file and simultaneously initiates a network request to read a local p12 file list to retrieve one of the p12 files (theoretically, only one). This concurrent multi-threaded read and write operation, without data locking to protect it, is prone to problems such as dirty reads and write errors. Furthermore, depending on the specific deployment scenario, these operations either call system methods or tool libraries provided by third-party authorities. However, external parties cannot determine whether these operations are locked or whether the locking is effective. Consequently, this can cause system crashes due to system function calls that shouldn't crash, or crashes due to issues such as report display anomalies or certificate array index exceeding. Furthermore, if the certificate used by the client to verify the server's verification object is a dirty read p12 file, rather than the correct p12 file used for subsequent verification, verification may occasionally fail.

[0059] Normally, a client will connect to multiple servers. If a client uses different certificates for two-way authentication for each server, then when it executes 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 failure. For example, if a client connects to server A and server B, and a set of certificate A is used for two-way authentication for server A, and a set of certificate B is used for two-way authentication for server B, then when the client executes the two-way authentication process for server A and server B concurrently, 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 failure.

[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 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 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 subsequently initiating a network request, 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. This 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 This 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, obtain the current login user information. 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 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 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 into the client.

[0065] In some implementations, 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, when a user logs in to a client (e.g., a vehicle control app), the client can obtain the user information (e.g., user ID) entered by the user, which can be used to identify and distinguish the client.

[0066] For car control apps, 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 differentiate the certificate systems required for use 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 and 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, then 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 can be a memory area set in the client. The first cache area is primarily used to store user information and associated two-way authentication data. In terms of implementation, the cache structure includes but is not limited to in-memory variables, cache pool key-value pairs, and other methods.

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

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

[0074] Before the user logs in, the network request bidirectional 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 and private keys as a key pair of the client, the key pair including a client public key and a client private key; obtaining a server public key sent by the server, and generating a server certificate using the server public key; and generating a temporary certificate file based on the server certificate and the client private key.

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

[0077] The temporary certificate file consists of two parts: the client's root certificate, which the client uses to verify the server's verification object; and the client's verification object, which the client provides to the server. These two parts can be stored as a single p12 file and a client root certificate. Preferably, both parts can be stored in a single p12 file, which reduces the file size and makes it easier to download, store, and manage.

[0078] Temporary certificate files and P12 files are typically stored as pre-installed files in the pre-installed package, which is the iOS development bundle. Temporary certificate files have the same structure as 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. 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: Read the current client root certificate from the first buffer area, and use the current client root certificate to verify the server verification object.

[0083] Step S206: If the server verification object passes, the current client verification object is read from the first buffer 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 a 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 subsequent two-way authentication processes, which can effectively prevent the problem of confusion in the certificate binding server verification objects, 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 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 problems of interface timeout and occasional system crashes, 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 clear 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. 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 consumed for two-way authentication between the client and the server can be shortened, thereby helping to improve 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 cache area may be cleared. The next time the user logs in to the client, the client may 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 a 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, call the first private fill variable function 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 This is a flow chart of filling original data variables provided in an embodiment of the present application.

[0093] See also Figure 3 First, define a private variable, 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 used 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 local certificate ID, 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, that 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" array extracted from the p12 file, that is, the secondary certificate.

[0104] var clientCertSub:CFData?

[0105] }.

[0106] In the first public acquisition function directed to 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] Next, the first public get function is called to determine whether the raw data variable in the first buffer is empty. If the raw data variable is empty, the first private fill variable function is called to extract the current client root certificate and the current client verification object from the current authentication file (p12 file). These current client root certificate and the current client verification object are then filled into the raw 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, the current client root certificate and the current client verification object are extracted from the current certificate file and filled into the original data variable, the 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 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. Loading the original data variable into the certificate array also takes a certain amount of time, 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 external use, write: determine whether the first variable (ie, the certificate array variable) is empty; if not, return; if empty, execute the step of filling the first variable (certificate array variable).

[0116] Figure 4This is a flow chart of filling original data variables and certificate array variables provided in an embodiment of the present application. Figure 5 This is another flowchart 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, if the original data variable is empty, the first private variable filling function is called to obtain the current client root certificate and the current client verification object. These are then filled into the original data variable (PKIIdentityAndTrustData). Then, if the first variable is empty, the second private variable filling function is called to convert the binary current client root certificate into a root certificate array that the system can directly use. This root certificate array is then filled into the first variable (clientCertArray). The current client verification object is then filled into the second variable.

[0118] Each element in the binary current client root certificate (trust array) is of type CFData and 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 to say, 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 is called 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 practice, when a network request occurs, the client can directly call the second public getter function on the certificate array variable, extract its member variable, the certificate array variable, from its return value, and verify the server's verification object. After verification, the client can directly call the first public getter function on the raw data variable, extract its member variables, identityRef and certArray, from its return value, and submit them to the server. This effectively shortens the overall time of the two-way authentication process, thereby improving system efficiency and stability.

[0125] In some implementations, when the client (such as the vehicle control APP) is started, when the user logs in, or when the user logs out, a cache cleanup function may be called to determine whether the cache has any value. If so, the cache 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, and the current client root certificate and the current client verification object will be extracted from the latest certificate file (that is, the current certificate file), and the current client root certificate will be converted into a root certificate array, and then filled 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 based on the file reading path and file export password.

[0136] Before reading the current or temporary certificate file, the client must first determine the file read path for the current or temporary certificate file. These paths are typically different for the current and temporary certificate files. Furthermore, the file read paths used may vary depending on the business environment and the connected server. Therefore, simply hard-coding the file read path for the current or temporary certificate file in the code can easily allow attackers to obtain it, increasing the risk of certificate file leakage or attacks.

[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, wherein each conditional layer variable forms a hierarchical 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 file export password are determined based on the upper and lower layer relationships between each conditional layer variable, the conditional entity corresponding to each conditional layer variable, and the data entity corresponding to the data layer variable.

[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. 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 as follows, with the environment as the upper layer and the server as the lower layer:

[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 (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 server can be the upper layer and the environment can be the lower layer to design the file reading path of the current certificate file. The following example illustrates the design of 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 the 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 p12 file pre-installed package path for 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 p12 file pre-installed package path for 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 can 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. Configuration conditions include but are not limited to the environment, server, and other conditions determined according to business needs.

[0174] Then, using 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 This is a structural diagram of a type of layer provided in an embodiment of the present application. Figure 7 This 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 conjunction 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 Department Server (Server C)

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

[0194] }.

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

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

[0197] After obtaining the configuration file (in binary format), the client can convert it into entity conditions corresponding to each conditional layer variable and entity data corresponding to each data layer variable by calling a third-party library or a first system function (such as the system function provided by 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 stored directly 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 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] To improve system performance and prevent the system from loading unnecessary certificates, you can further call a third system function: public func SecTrustSetAnchorCertificatesOnly(_trust:SecTrust,_anchorCertificatesOnly:Bool)->OSStatus. The first parameter passed to this function is the server verification object, and the second parameter is the associated parameter, which is true. The associated parameter is used to verify the server verification object using only the root certificate array associated with the function, without verifying any 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 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 buffer area;

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

[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 includes 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, after a user logs in to the client, the current certificate file corresponding to the currently logged-in user fails to be obtained due to reasons such as data extraction failure, parsing failure, or SecPKCS12Import import failure, the pre-stored temporary certificate file can be used as a fallback certificate file to perform subsequent two-way authentication processes. At the same time, the client restarts the thread and initiates another certificate acquisition request to the server 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 for subsequent network requests will use the current certificate file.

[0218] Through the above solution, even if the acquisition of the current certificate file corresponding to the currently logged-in user information fails due to reasons such as data extraction failure, parsing failure, and SecPKCS12Import import failure, the two-way authentication process can still be performed normally, thereby avoiding the phenomenon of authentication process stagnation and failure due to the client's failure to obtain the current certificate file.

[0219] All of the above optional technical solutions can be combined in any way to form optional embodiments of the present application, and will not be described in detail here.

[0220] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0221] Figure 8 This is a 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 information of a currently logged-in user and, if the currently logged-in user information is inconsistent with historically logged-in user information, clear historical two-way authentication data associated with the historically logged-in user information in the first buffer; wherein the historical two-way authentication data includes historical client root certificates and historical client verification objects;

[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. 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 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 configured to call a first public acquisition function to determine whether the original data variable in the first buffer area is empty;

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

[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 includes:

[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 configured to call a second private fill 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 logged-in 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 configured to acquire a configuration file, wherein the configuration file includes at least two conditional layer variables and one data layer variable, wherein each conditional layer variable forms a hierarchical 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 each conditional layer variable, the conditional entity corresponding to each conditional layer variable, and the data entity corresponding to the data layer variable.

[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 configured to send 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 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 currently 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 currently 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 this application.

[0254] Figure 9 Schematic diagram of the electronic device 9 provided in the embodiment of the present application. Figure 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 by the processor 901. When the processor 901 executes the computer program 903, the steps of the above-described method embodiments are implemented. Alternatively, when the processor 901 executes the computer program 903, the functions of the modules / units in the above-described 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 understand that Figure 9 This is merely an example of the electronic device 9 and does not limit the electronic device 9 . The electronic device 9 may include more or fewer components than 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 can be an internal storage unit of the electronic device 9, such as a hard disk or memory of the electronic device 9. The memory 902 can also be an external storage device of the electronic device 9, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. equipped on the electronic device 9. The memory 902 can 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 will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by 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 units 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 (such as 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, etc. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic 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 various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A two-way authentication method, characterized in that: include: Obtaining current logged-in user information, and if the current logged-in user information is inconsistent with historical logged-in user information, clearing 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 a historical client root certificate and a historical client verification object; Read 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, the current two-way authentication data including the current client root certificate and the current client verification object; Initiating a network request to a server, and receiving a server verification object returned by the server in response to the network request; Reading the current client root certificate from the first cache area, and verifying the server verification object using the current client root certificate; If the server verification object passes verification, reading the current client verification object from the first buffer area and sending it 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, including: 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 fill variable function to extract the current client root certificate and the current client verification object from the current certificate file; Fill the current client root certificate and the current client verification object 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, wherein Reading the current certificate file associated with the currently logged-in user information includes: Determine the file reading path and file export password; The current certificate file associated with the currently logged-in user information is read according to the file reading path and the file export password.

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, wherein each of the conditional layer variables forms a hierarchical relationship, each of the conditional layer variables stores at least one conditional object, and the data layer variables store data corresponding to each of the conditional objects; Calling a third-party library or a first system function to obtain the condition entity corresponding to each of the condition layer variables and the data entity corresponding to the data layer variable; 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 verifying the server verification object using the current client root certificate, including: Call the second system function and pass 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, 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; If the current certificate file corresponding to the currently logged-in user information is not received from the server in response to the certificate acquisition request, 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 currently logged-in user information is successfully acquired.

8. A two-way authentication device, characterized in that: include: an acquisition module configured to acquire current logged-in user information and, if the current logged-in user information is inconsistent with historical logged-in user information, clear historical two-way authentication data associated with the historical logged-in user information in the first buffer; wherein the historical two-way authentication data includes a historical client root certificate and a historical client verification object; A reading module is configured to read a current certificate file associated with the currently logged-in user information; a parsing module 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 verify the server verification object using the current client root certificate; 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, wherein: 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