Symmetrical entity identification method based on server dynamic key derivation

Abstract

The invention discloses a symmetric entity authentication method based on server dynamic key derivation, relates to the technical field of information system security, and under the architecture of the method, an authentication server does not know an authentication key before each authentication and cannot derive the authentication key. Only when an authentication client initiates an entity authentication request, a client authentication key material is sent to an authentication server, and the authentication server immediately exports an authentication key based on a previously stored server authentication key material and the received client authentication key material. And executing an entity authentication protocol based on a symmetric algorithm by using the authentication key. According to the method, while good quantum security adaptability and symmetric authentication efficiency are achieved, centralized storage and long-term mastering of authentication keys of all authentication clients by an authentication server are avoided, the security and expandability of the system are remarkably improved, and the method is suitable for various security sensitive scenes such as a cloud platform, an identity authentication terminal and an edge node.

Description

Technical Field

[0001] The present application relates to the field of information system security technology, and in particular to a symmetric entity authentication method based on server-side dynamic key derivation. Background Art

[0002] In the security architecture of information systems, entity authentication is a key means of ensuring the trustworthy identities of both communicating parties. It is widely used in security scenarios such as terminal access control, service authorization management, and sensitive data protection. Existing entity authentication technologies are primarily divided into two categories: symmetric and asymmetric. The following describes these two types of entity authentication mechanisms, using entity authentication between an authentication server and an authentication client as an example.

[0003] Traditional entity authentication mechanisms based on symmetric algorithms typically require the authentication server and client to pre-share a common symmetric key, which serves as the authentication credential. The authentication server uses this symmetric key to verify the data transmitted by the authentication client for a specific authentication object, thereby determining the validity of the identity of the authentication object. This approach offers advantages such as low computational cost and fast response time, making it particularly suitable for resource-constrained or high-frequency authentication environments. However, such approaches often suffer from a security bottleneck: the identity keys of all authentication clients must be centrally stored on the authentication server. If the authentication server is attacked or data is leaked, the identity information of all authentication clients in the system will be at risk of synchronization failure and cannot be independently restored. This architecture creates a "single point of trust" dependency on the authentication server for security, requiring authentication clients to establish "unconditional trust" in the authentication server. This not only reduces the system's resilience to attacks but also introduces complex key management and high key update costs in actual operations and maintenance.

[0004] To overcome these issues, entity authentication mechanisms based on asymmetric algorithms have emerged. This type of entity authentication mechanism typically involves the authentication client holding a private key specific to the authentication target, while the authentication server holds the corresponding public key. Identity / entity authentication is then performed based on an asymmetric algorithm. The authentication server does not need to store the client's private information, thus avoiding the security risks associated with centralized key storage. Even if the authentication server is compromised, the client's authentication credentials will not be directly leaked. However, this entity authentication mechanism relies on asymmetric algorithms, which generally rely on mathematical problems such as factoring large numbers and elliptic curve discrete logarithms. Their security relies on the limitations of current computing power. Symmetric algorithms (such as HMAC and SM4) offer greater security resilience against quantum attacks, and increasing key length can effectively resist brute force attacks from quantum computing. However, asymmetric algorithms do not possess the same high efficiency and strong quantum security as symmetric algorithms. Especially with the continued development of quantum computing, traditional asymmetric algorithms face the potential risk of being cracked, raising concerns about their long-term security in future systems.

[0005] In summary, the existing entity authentication method based on symmetric algorithms has a structural security weakness in that the authentication server centrally holds the identity keys of all authentication clients. When the authentication server is attacked and data is leaked, the identity information of the authentication client will also become invalid. Even if the server is restored, the original client cannot continue to be used for secure identity authentication. The existing method based on asymmetric algorithms faces the risks brought by future quantum computing. The security of these two existing entity authentication methods still needs to be improved. Summary of the Invention

[0006] In response to the above problems and technical requirements, this application proposes a symmetric entity authentication method based on server-side dynamic key derivation. The technical solution of this application is as follows:

[0007] A symmetric entity authentication method based on server-side dynamic key derivation, the symmetric entity authentication method comprising:

[0008] After receiving the login request containing the application system login account, the authentication server containing the hardware password resource forwards the login request to the authentication client bound to the application system login account;

[0009] After receiving the login authorization for the login request, the authentication client sends the client authentication key material UserT corresponding to the application system login account to the authentication server. The authentication client also pre-stores the authentication key UserK corresponding to the application system login account;

[0010] The authentication server performs dynamic key derivation based on the server authentication key material UserR corresponding to the application system login account stored in its own storage, combined with the received client authentication key material UserT, and instantly obtains the authentication key UserK corresponding to the application system login account;

[0011] The authentication server uses the identification key UserK derived from the dynamic key based on a symmetric algorithm to authenticate the login user of the application system login account associated with the authentication client.

[0012] A further technical solution is that the authentication server uses the identification key UserK derived from the dynamic key based on a symmetric algorithm to authenticate the login user of the application system login account associated with the authentication client, including:

[0013] The authentication server immediately generates a random challenge value R, and combines it with the authentication key UserK derived from the dynamic key to generate an authentication challenge token TokenS and send it to the authentication client;

[0014] The authentication client uses the pre-saved authentication key UserK corresponding to the application system login account to verify and parse the received authentication challenge token TokenS to obtain a random challenge value R';

[0015] The authentication client uses the parsed random challenge value R' as a random response, and uses the pre-saved authentication key UserK corresponding to the application system login account to calculate the authentication response token TokeU and return it to the authentication server;

[0016] The authentication server uses the identification key UserK derived from the dynamic key to verify and parse the received authentication response token TokeU to obtain the random challenge value R"; when it is determined that the random challenge value R" obtained by parsing is consistent with the random challenge value R, it is determined that the identity authentication of the login user of the application system login account associated with the authentication client is successful, and the login request is confirmed and responded to.

[0017] A further technical solution is that the symmetric entity identification method further includes:

[0018] The authentication server uses the built-in hardware random source to generate random numbers to generate the server authentication key material UserR for the legitimate application system login account, stores the server authentication key material UserR in correspondence with the application system login account, and sends the server authentication key material UserR to the authentication client bound to the legitimate application system login account;

[0019] The authentication client generates the client authentication key material UserT corresponding to the application system login account, and combines it with the received server authentication key material UserR to derive the authentication key UserK, and stores the authentication key UserK, the client authentication key material UserT and the application system login account in correspondence.

[0020] A further technical solution is that the symmetric entity identification method further includes:

[0021] After the authentication server successfully authenticates the identity of the user logged in to the application system account associated with the authentication client, it generates a new server-side authentication key material UserR and encrypts it and sends it to the corresponding authentication client;

[0022] The authentication client regenerates the client authentication key material UserT, and re-derives the key based on the received new server authentication key material UserR, and obtains the updated authentication key UserK which is stored in correspondence with the application system login account.

[0023] A further technical solution is that the authentication server uses an encryption key based on a symmetric encryption algorithm to encrypt the newly generated server authentication key material UserR and then sends it to the authentication client. The authentication client uses the encryption key based on the symmetric encryption algorithm to decrypt and obtain the new server authentication key material UserR. The encryption key is a random challenge and random response generated during the identity authentication process and shared between the authentication server and the authentication client, or a derived value of the random challenge and random response.

[0024] Alternatively, a secure communication channel is pre-established between the authentication server and the authentication client. The authentication server uses the session key of the secure communication channel to encrypt the newly generated server authentication key material UserR, and then sends it to the authentication client via the secure communication channel. The authentication client uses the session key of the secure communication channel to decrypt it to obtain the new server authentication key material UserR.

[0025] A further technical solution is that the symmetric entity identification method further includes:

[0026] When registering an application system login account bound to an authentication client, the authentication server generates a user password for the application system login account, and uses the user password and the key derived from the password key to encrypt the server authentication key material UserR generated for the application system login account. The application system login account and its encrypted server authentication key material UserR are included in the registration QR code; the authentication client signs the registration QR code with the signature private key and sends it to the authentication client;

[0027] The authentication client scans the registration QR code and uses the preset authentication server's signature verification public key to verify the digital signature in the registration QR code. After the verification is successful, the user password is obtained to derive the password key, and the password key is used to decrypt the encrypted server authentication key material to obtain the server authentication key material UserR.

[0028] Its further technical solution is that the information carried by the registration QR code includes barmsg||S PrivK (barmsg), where:

[0029] S PrivK (barmsg) is the result of digitally signing barmsg using the signature private key PrivK of the authentication server 120;

[0030] barmsg=Qid.AccountName||requestID||appID||verID||PinSalt||E PinK (UserR);

[0031] Among them, Qid.AccountName is the application system login account; requestID is a random task identifier; appID is the device identifier of the authentication client 130, verID is a version number, PinSalt is a salt value used to derive the password key; E PinK (UserR) represents the result of encrypting the server authentication key material UserR using the password key PinK derived from the user password using a symmetric encryption algorithm; || represents a sequential concatenation operation.

[0032] A further technical solution is that the authentication client uses the pre-stored public key of the authentication server to encrypt the client authentication key material UserT corresponding to the application system login account and sends it to the authentication server. The authentication server uses its own private key to decrypt the client authentication key material UserT.

[0033] Alternatively, a secure communication channel is established between the authentication server and the authentication client in advance. The authentication client uses the session key of the secure communication channel to encrypt the client identification key material UserT corresponding to the application system login account, and then sends it to the authentication server via the secure communication channel. The authentication server uses the session key of the secure communication channel to decrypt and obtain the client identification key material UserT.

[0034] A further technical solution is that the authentication client generates the client identification key material UserT including:

[0035] The authentication client uses the kernel-state entropy pool mechanism to generate a system random number to obtain the client authentication key material UserT;

[0036] Alternatively, the authentication client generates a pseudo-random value based on the local timestamp and the local system random number through an HMAC function to obtain the client authentication key material UserT.

[0037] A further technical solution is that the authentication client uses the first security key corresponding to the application system login account to encrypt, store and decrypt the identification key UserK corresponding to the application system login account;

[0038] Alternatively, the authentication client uses the secure storage mechanism of the local operating system to protect the authentication key UserK corresponding to the locally stored application system login account. The secure storage mechanism implements the non-exportability and access control of the authentication key UserK based on the hardware security module, and limits the authentication key to be bound to a specific application signature and device status for use.

[0039] A further technical solution is that the symmetric entity identification method further includes:

[0040] Collect and verify user feature information, and use the user feature verification success event to generate a session context or derive a first security key from the protected hardware module that is only accessible after the user feature information is verified.

[0041] A further technical solution is that the symmetric entity identification method further includes:

[0042] A secure communication channel is established between the authentication server and the authentication client based on the user feature information of the authentication client. The authentication client obtains a first security key from the authentication server via the secure communication channel and uses the first security key to decrypt the encrypted authentication key UserK.

[0043] Its further technical solution is that the authentication server stores the correspondence between the server authentication key material UserR and the application system login account in the hardware password security storage space of the authentication server;

[0044] Alternatively, the authentication server encrypts the generated server authentication key material UserR using the second security key stored in the hardware password security storage space, and stores the encrypted server authentication key material UserR in correspondence with the application system login account.

[0045] A further technical solution is that the authentication client sends the client identification key material UserT corresponding to the application system login account to the authentication server, including:

[0046] The authentication client uses the pre-embedded identity certificate of the authentication server to perform a one-time entity authentication of the authentication server based on a digital signature, and after successfully authenticating the entity of the authentication server, it sends the client authentication key material UserT corresponding to the pre-stored application system login account to the authentication server.

[0047] Its further technical solution is that the authentication challenge token TokenS generated by the authentication server is:

[0048] TokenS=appID||Qid.AccountName||ref||E UserK2 (R)||S PrivK (E UserK2 (R)||appID||Qid.AccountName||ref)

[0049] The authentication response token TokeU calculated by the authentication client is:

[0050] TokenU=appID||ref||E UserK2 (M UserK1 (appID||ref||R')||R')

[0051] Among them, UserK=UserK1||UserK2,|| represents the sequential splicing operation; appID is the device identifier of the authentication client, Qid.AccountName is the application system login account, and ref is the task identifier; E UserK2 (R) represents the result of encrypting the random challenge value R using the symmetric encryption algorithm using the key UserK2; S PrivK (E UserK2 (R)||appID||Qid.AccountName||ref) indicates the use of the signature private key PrivK of the authentication server to authenticate E UserK2 (R)||appID||Qid.AccountName||refThe signature generated by the signature transformation; E UserK2 (M UserK1 (appID||ref||R')||R') indicates that the key UserK2 is used to identify M UserK1 (appID||ref||R')||R' is encrypted by the symmetric encryption algorithm; M UserK1 (appID||ref||R') represents a cryptographic verification value generated by a cryptographic verification function using the key UserK1 and the data string appID||ref||R' as input.

[0052] A further technical solution is that the authentication server and the authentication client use a key derivation function that meets the national cryptographic standards to derive a key to obtain an identification key UserK.

[0053] The beneficial technical effects of this application are:

[0054] The present application discloses a symmetric entity authentication method based on dynamic key derivation on the server side. The authentication server side has hardware cryptographic resources for generating high-entropy server-side authentication key material and sending it to the authentication client. The authentication client generates client authentication key material in combination with a local entropy source and / or nanosecond timestamp, and derives an authentication key based on the received server-side authentication key material and the client-side authentication key material and saves it locally on the authentication client. The authentication server side does not know the authentication key before each authentication and cannot derive the authentication key. Only when the authentication client initiates an entity authentication request, the client authentication key material is sent to the authentication server side. The authentication server side immediately derives the authentication key based on the previously saved server-side authentication key material and the received client-side authentication key material, and uses the authentication key to execute an entity authentication protocol based on a symmetric algorithm. While having good quantum security adaptability and symmetric authentication efficiency, this method avoids the authentication server side from centrally storing and long-term control of the authentication keys of all authentication clients, significantly improving system security and scalability, avoiding long-term sharing of symmetric keys, and improving security. It is suitable for a variety of security-sensitive scenarios including cloud platforms, identity authentication terminals, and edge nodes.

[0055] In this method, after each successful round of identity authentication, the authentication server immediately generates new server-side authentication key material and sends it to the authentication client associated with the application system login account used by the logged-in user who successfully completed the identity authentication. The authentication client then generates new client-side authentication key material and updates the authentication key stored in the authentication client, thereby further improving security.

[0056] This method overcomes the security bottleneck of the traditional symmetric authentication mechanism's "centralized server-side key storage." By constructing a "stateless" authentication / entity authentication model on the authentication server, the authentication server does not store or possess the authentication client's authentication credentials (authentication keys) during the entity authentication process, nor can it derive the value of the authentication key without the authentication client's cooperation. This significantly reduces the authentication server's security exposure as a high-risk center in the system. Under the architecture of the present invention, the authentication server does not hold any authentication keys that can be used for long-term entity authentication, nor does it store key materials that can directly derive the client's authentication key. The entire server has a "zero key leakage surface" feature in the authentication chain. Even if the server is compromised, the attacker cannot steal the client's authentication keys in bulk or forge the authentication process, effectively blocking the systemic identity forgery risk caused by server-side leaks in the symmetric key mechanism. Even if the server is compromised and data is leaked, as long as the server is reconstructed to plug the server-side vulnerability, the existing authentication client can resume normal and secure identity authentication operations. Because it is impossible to forge any client's authentication object based on server-side data, there is no risk of client forgery. This method uses a standard symmetric encryption algorithm for identity authentication, does not rely on difficult assumptions or computational complexity for security, and has a natural ability to resist quantum attacks. In addition, since the authentication server cannot forge the authentication client's identification key on its own, the authentication client does not need to establish "unconditional trust" in the server, so it has strong anti-spoofing capabilities. Moreover, there is no need to deploy a complex public key infrastructure (PKI), and a decentralized identity trust structure under a symmetric algorithm can be realized. It is particularly suitable for large-scale distributed authentication systems, edge computing devices, security-aware terminals and other environments, and has high adaptability and deployability. This mechanism combines high-intensity random number generation and key derivation technology to achieve a key security protection effect in a symmetric authentication model that is similar to an asymmetric structure. It has the comprehensive advantages of simple structure, efficient calculation, and high security. It achieves a good balance between system efficiency, security isolation and resistance to quantum threats, and is particularly suitable for identity authentication systems that are highly sensitive to key control risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 It is a schematic diagram of an application scenario of a symmetric entity identification method in an embodiment of the present application.

[0058] Figure 2 This is a schematic diagram of the initialization registration process in one embodiment of the present application.

[0059] Figure 3 This is a schematic diagram of the identity authentication process for an application system login account in one embodiment of the present application. DETAILED DESCRIPTION

[0060] The specific implementation of this application will be further described below with reference to the accompanying drawings.

[0061] This application discloses a symmetric entity authentication method based on server-side dynamic key derivation, which is applied to Figure 1 In the symmetric entity authentication system shown, the symmetric entity authentication system includes an application system 110, an authentication server 120, and an authentication client 130. User 140 has a corresponding login account in the application system 110, and user 140 holds the authentication client 130. The authentication server 120 includes hardware cryptographic resources, which include a high-quality hardware random source generated based on physical noise, a cryptographic computing component with trusted execution capability, a sensitive data storage module with physical protection capability, and a complete key lifecycle management system (covering key generation, storage, distribution, use, and destruction).

[0062] In one embodiment, the authentication client 130 is a client program deployed on a user terminal device (such as a personal computer), including a Windows client program and a Linux client program.

[0063] The authentication client 130 establishes a communication connection with the authentication server 120 through an initialization registration process. During the registration stage, the authentication client 130 will send registration information such as device identification, user identification, and system environment information to the authentication server 120. The authentication server 120 completes the device uniqueness verification based on this information, and establishes a binding relationship between the authentication client 130 and a specific application system login account in the application system 110. This binding relationship can be maintained through a mapping table inside the authentication server 120 for association identification in subsequent identity authentication processes.

[0064] First, the initialization registration process is introduced as follows, including the following steps, please refer to Figure 2 The flow chart shown:

[0065] In step 210 , the authentication client 130 performs entity authentication on the authentication server 120 .

[0066] Before accessing authentication server 120, authentication client 130 uses its pre-embedded identity certificate to perform a one-time digital signature-based entity authentication of authentication server 120. Authentication server 120 sends a timestamp or random number signed with the private key to authentication client 130. Authentication client 130 verifies the signature and confirms the identity of authentication server 120. It proceeds only after authentication client 130 successfully authenticates the entity of authentication server 120.

[0067] In step 220 , the authentication server 120 initiates a registration invitation.

[0068] The authentication server 120 uses an offline identity confirmation mechanism, and the administrator verifies offline the identity information of the user holding the application system login account to which the authentication client 130 belongs. After confirming that the application system login account is legitimate, the authentication server 120 generates a server-side authentication key material UserR for the legitimate application system login account, stores the server-side authentication key material UserR in correspondence with the application system login account, and sends the server-side authentication key material UserR to the authentication client 130 bound to the legitimate application system login account.

[0069] In one embodiment, the authentication server 120 has hardware cryptographic resources including a hardware random source. The authentication server 120 uses the built-in hardware random source to generate random numbers and generate a server authentication key material UserR.

[0070] The hardware password resources included in the authentication server 120 also include a hardware password security storage space. In order to improve the storage security of the server-side authentication key material UserR in the authentication server 120, in one embodiment, the authentication server 120 stores the correspondence between the server-side authentication key material UserR and the application system login account in the hardware password security storage space of the authentication server. Alternatively, in another embodiment, the authentication server 120 uses a second security key to encrypt the generated server-side authentication key material UserR, and stores the encrypted server-side authentication key material UserR in correspondence with the application system login account, while the second security key used for encryption and decryption of the server-side authentication key material UserR is stored in the hardware password security storage space.

[0071] In one embodiment, the authentication server 120 generates a password for the application system login account, and uses the password to derive a password key. After encrypting the server authentication key material UserR with the password key, a registration QR code carrying the application system login account and the encrypted server authentication key material UserR is generated. This registration QR code is signed by the authentication server 120 using the signature private key PrivK in the hardware password resource to protect its authenticity and integrity. Then, based on the offline identity authentication of the user 140, the authentication server administrator provides the registration QR code to the user 140 and also tells the user 140 the corresponding password. The user 140 uses the authentication client 130 to scan the registration QR code, and the authentication client 130 then uses the preset authentication server 120 signature verification public key to verify the digital signature in the registration QR code. The authentication client 130 will only continue if the signature verification is qualified, otherwise it will report an error and exit. The authentication client 130 prompts the user to enter a password, and uses the password to derive the same password key, and uses the password key to decrypt the encrypted server authentication key material UserR to obtain the server authentication key material UserR generated by the authentication server 120 for the application system login account.

[0072] In one embodiment, the information carried by the registration QR code includes barmsg||S PrivK (barmsg), where S PrivK (barmsg) is the result of digitally signing barmsg using the signature private key PrivK of the authentication server 120.

[0073] barmsg=Qid.AccountName||requestID||appID||verID||PinSalt||E PinK (UserR)

[0074] Where Qid.AccountName is the login account of the application system, Qid is the identifier of the application system 110, and AccountName is the login account name. requestID is a random task identifier. appID is a random new device identifier of the authentication client 130, verID is a version number, and PinSalt is a salt value used to derive the password key. PinK (UserR) represents the result of encrypting the server authentication key material UserR using the password key PinK derived from the user password using a symmetric encryption algorithm. || represents a sequential concatenation operation.

[0075] In one embodiment, the user 140 may generate the user password himself / herself with the authentication and cooperation of the administrator of the authentication server 120 .

[0076] In some embodiments, the above method of using the registration QR code to transmit the server-side authentication key material UserR can also be in the form of an encrypted data file, or encrypted data transmitted through an encrypted envelope, generated by the authentication server administrator and handed over to the user 120.

[0077] In some embodiments, the above-mentioned method of using digital signatures to protect the authenticity and integrity of the server-side authentication key material UserR can also be a method based on a message authentication code using a symmetric key, such as obtaining a part of sufficient length from the derived key as a symmetric key for protecting the authenticity and integrity of the server-side authentication key material.

[0078] In step 230 , the authentication client 130 derives and stores the authentication key UserK.

[0079] The authentication client 130 locally generates the client authentication key material UserT for the application system login account. In one embodiment, the authentication client 130 uses a kernel-state entropy pool mechanism to generate a system random number to obtain the client authentication key material UserT. The entropy pool is replenished by non-deterministic events during system operation, including at least one of user input events (such as touch and slide), system interruptions, sensor data changes, and network fluctuations.

[0080] In another embodiment, the authentication client 130 generates a pseudo-random value based on the local timestamp and the local system random number through an HMAC function to obtain the client authentication key material UserT.

[0081] The authentication client 130 then uses the generated client authentication key material UserT and the received server authentication key material UserR to derive the corresponding authentication key UserK of the application system login account, and stores the authentication key UserK, the client authentication key material UserT and the application system login account in correspondence.

[0082] To improve the storage security of the authentication key UserK in the authentication client 130, the authentication client 130 locally encrypts and protects the authentication key UserK. In one embodiment, the authentication client 130 uses the local operating system's secure storage mechanism to protect the locally stored authentication key UserK corresponding to the application system login account. This secure storage mechanism, based on a hardware security module, implements the non-exportability and access control of the authentication key UserK and limits the use of the authentication key UserK to specific application signatures and device states. Alternatively, in another embodiment, the authentication client 130 uses a first security key corresponding to the application system login account to encrypt and store the authentication key UserK corresponding to the application system login account. In one embodiment, the first security key is a key derived from user feature information, where the user feature information is a user password or biometric information, including a fingerprint, facial features, or iris. In one embodiment, the authentication client 130 collects and verifies the user feature information. After completing the user feature information verification, it does not directly retrieve or store the original user feature information. Instead, it uses the user feature verification success event to generate a session context or derives a first security key from the protected hardware module, which is accessible only after the user feature information verification is successful, for encryption and decryption of the authentication key UserK.

[0083] After the above initialization registration process, the authentication server 120 stores the binding relationship between the application system login account and the authentication client 130, and the authentication server 120 also stores the corresponding relationship between the application system login account and the server authentication key material UserR. The authentication client 130 bound to the application system login account stores the authentication key UserK corresponding to the application system login account and the client authentication key material UserT. The authentication server 120 and the authentication client 130 can then implement symmetric entity authentication to authenticate the login account in the application system. The authentication process includes the following steps, please refer to Figure 3 The flowchart shown:

[0084] In step 310 , when the user 140 attempts to log in to the application system 110 using the application system login account, the application system 110 receives a login request including the application system login account initiated by the user 140 and forwards the login request to the authentication server 120 .

[0085] In step 320 , after receiving the login request including the application system login account, the authentication server 120 first identifies the authentication client 130 bound to the application system login account, and then forwards the login request to the authentication client 130 bound to the application system login account.

[0086] In step 330 , after receiving the login request, the authentication client 130 prompts the user 140 to confirm the login, including confirmation by local biometrics, PIN code input, or physical token confirmation.

[0087] In step 340 , after receiving the login authorization from the user 140 , the authentication client 130 initiates a symmetric entity authentication process, first sending the client authentication key material UserT corresponding to the application system login account stored locally to the authentication server 120 .

[0088] In one embodiment, the authentication client 130 uses the pre-embedded identity certificate of the authentication server 120 to perform a one-time entity authentication of the authentication server 120 based on a digital signature, and after successfully authenticating the entity of the authentication server 120, sends the client authentication key material UserT corresponding to the pre-stored application system login account to the authentication server 120.

[0089] In step 350, after receiving the client authentication key material UserT corresponding to the application system login account sent by the authentication client 130, the authentication server 120 performs dynamic key derivation based on the server authentication key material UserR corresponding to the application system login account stored in its own storage, and immediately obtains the authentication key UserK corresponding to the application system login account.

[0090] To improve security, in one embodiment, in step 340, the authentication client 130 encrypts the client authentication key material UserT corresponding to the application system login account and sends it to the authentication server 120. Accordingly, the authentication server 120 decrypts the encrypted key material UserT to obtain the client authentication key material UserT. In one implementation, the authentication client 130 uses a pre-stored public key of the authentication server 120 to encrypt the client authentication key material UserT corresponding to the application system login account and sends it to the authentication server 120. The authentication server 120 decrypts the encrypted key material UserT using its own private key. In another implementation, a secure communication channel is pre-established between the authentication server 120 and the authentication client 130. The authentication client 130 encrypts the client authentication key material UserT corresponding to the application system login account using the session key of the secure communication channel and sends the encrypted key material UserT to the authentication server 120 via the secure communication channel. The authentication server 120 decrypts the encrypted key material UserT using the session key of the secure communication channel.

[0091] In step 360, the authentication server 120 uses the identification key UserK derived from the dynamic key based on a symmetric algorithm to authenticate the login user of the application system login account associated with the authentication client 130, including the following steps:

[0092] In step 361 , the authentication server 120 generates a random challenge value R in real time, and generates an authentication challenge token TokenS based on the authentication key UserK derived from the dynamic key, and sends the token to the authentication client 130 .

[0093] In one embodiment, UserK = UserK1 || UserK2. That is, the authentication key UserK is divided into UserK1 and UserK2. The authentication key UserK is 64 bytes, while the keys UserK1 and UserK2 are each 32 bytes. UserK1 and UserK2 are used for SM4 CBC-MAC calculations and SM4-CBC encryption and decryption calculations, respectively (16-byte key and 16-byte IV).

[0094] In one embodiment, the authentication challenge token TokenS is:

[0095] TokenS=appID||Qid.AccountName||ref||E UserK2 (R)||S PrivK (E UserK2 (R)||appID||Qid.AccountName||ref).

[0096] Wherein, appID is the device identifier of the authentication client 130, Qid.AccountName is the application system login account, and ref is the task identifier. UserK2 (R) represents the result of encrypting the random challenge value R using the key UserK2 using a symmetric encryption algorithm. In one example, the symmetric encryption algorithm used is SM4 and the encryption mode is CBC. PrivK (E UserK2 (R)||appID||Qid.AccountName||ref) indicates the use of the signature private key PrivK of the authentication server 120 to E UserK2 The signature generated by performing a signature transformation on (R)||appID||Qid.AccountName||ref. The authentication server 120's private signature key, PrivK, is generated and managed by the authentication server 120's hardware cryptographic resources. In one example, the SM signature algorithm is used for signature transformation. "||" indicates a sequential concatenation operation.

[0097] In step 362 , the authentication client 130 uses the pre-stored authentication key UserK corresponding to the application system login account to verify and parse the received authentication challenge token TokenS to obtain a random challenge value R′.

[0098] When the authentication client 130 encrypts and stores the authentication key UserK corresponding to the application system login account using the first security key corresponding to the application system login account, the authentication key UserK is decrypted using the first security key before use. One implementation method is to derive the first security key by collecting user profile information. Another implementation method is to store the first security key only on the authentication server 120. To use the first security key, a secure communication channel must first be established between the authentication server 120 and the authentication client 130 based on the user profile information of the authentication client 130. The authentication client 130 then obtains the first security key from the authentication server 120 via the secure communication channel and uses the first security key to decrypt the encrypted authentication key UserK for use.

[0099] In step 363 , the authentication client 130 uses the parsed random challenge value R′ as a random response, calculates an authentication response token TokeU using the pre-stored authentication key UserK corresponding to the application system login account, and returns the token to the authentication server 120 .

[0100] In one embodiment, the authentication response token TokeU is:

[0101] TokenU=appID||ref||E UserK2 (M UserK1 (appID||ref||R')||R').

[0102] Among them, M UserK1 (appID||ref||R') represents a cryptographic check value generated by a cryptographic check function that takes the key UserK1 and the data string appID||ref||R' as input. In one example, the cryptographic check function used is a MAC value calculation based on the SM4-CBC block cipher algorithm, denoted as the SM4 CBC-MAC message authentication code algorithm. UserK2 (M UserK1 (appID||ref||R')||R') indicates that the key UserK2 is used to identify M UserK1 (appID||ref||R')||R' is the result of encryption using the symmetric encryption algorithm,

[0103] In step 364, the authentication server 120 uses the authentication key UserK derived from the dynamic key to verify and parse the received authentication response token TokeU to obtain a random challenge value R", and compares the obtained random challenge value R" with the random challenge value R initially generated in step 361. When it is determined that the random challenge value R" obtained by parsing is consistent with the random challenge value R, it is determined that the identity authentication of the login user of the application system login account associated with the authentication client 130 is successful, and the login request of the application system login account is passed and responded to, and the application system 110 allows the user 140 to log in using the application system login account. Otherwise, it is determined that the identity authentication of the login user of the application system login account associated with the authentication client 130 has failed, and the application system 110 refuses the user 140 to log in using the application system login account. The request and response data in the above-mentioned entity authentication process both contain an anti-replay mechanism field to prevent passive attackers from replaying historical authentication messages.

[0104] It can be seen that only when user 140 confirms on the associated authentication client 130 that possesses the correct authentication key UserK, and the authentication client 130 correctly cooperates with the authentication server 120, will the authentication server 120 determine that the authentication is successful and then notify the application system to log in. Furthermore, in the above process, the authentication server 120 is primarily responsible for coordinating the authentication process and making authentication decisions. It does not store the authentication key UserK prior to identity authentication, nor is it able to derive the final authentication key UserK. Only when the authentication client 130 initiates an entity authentication request and sends the client authentication key material UserT to the authentication server 120, will the authentication server 120 immediately derive the authentication key UserK based on the previously stored server authentication key material UserR and the received client authentication key material UserT, and use this authentication key UserK to execute the entity authentication protocol based on the symmetric algorithm. Since the authentication server 120 never holds the authentication key UserK of any authentication client 130 during the entire process, and only temporarily and dynamically derives and uses it in the verification session, it can ensure that the authentication server 120 is non-derivable and adheres to the principle of minimum information disclosure for the authentication key UserK of each authentication client 130 under normal circumstances. While having good quantum security adaptability and symmetric authentication efficiency, it avoids long-term sharing of symmetric keys and improves security. It can be well applied to various security-sensitive scenarios including cloud platforms, identity authentication terminals, edge nodes, etc.

[0105] In another embodiment, after the authentication server 120 successfully authenticates the identity of the login user of the application system login account associated with the authentication client 130, it generates new server-side authentication key material UserR and encrypts it and sends it to the above-mentioned associated authentication client 130. The authentication client 130 regenerates new client-side authentication key material UserT and re-derives the key based on the received new server-side authentication key material UserR, obtaining an updated authentication key UserK and storing it in correspondence with the application system login account. Therefore, after each successful round of identity authentication, the server-side authentication key material UserR, client-side authentication key material UserT, and authentication key UserK corresponding to the application system login account are all updated accordingly for subsequent identity authentication. This key update mechanism further improves security.

[0106] To improve security, in one embodiment, the authentication server 120 encrypts the newly generated server authentication key material UserR and sends it to the authentication client 130. Correspondingly, the authentication client 130 decrypts the server authentication key material UserR.

[0107] In one implementation, the authentication server 120 encrypts the server authentication key material UserR using an encryption key based on a symmetric encryption algorithm and then sends the encrypted key to the authentication client 130. The authentication client then decrypts the encrypted key using the symmetric encryption algorithm to obtain the server authentication key material UserR. The encryption key used is the random challenge and random response generated during the identity authentication process and shared between the authentication server 120 and the authentication client 130, or a derivative of the random challenge and random response.

[0108] Another implementation method is to establish a secure communication channel between the authentication server 120 and the authentication client 130 in advance. The authentication server 120 uses the session key of the secure communication channel to encrypt the server authentication key material UserR, and then sends it to the authentication client 130 via the secure communication channel. The authentication client 130 uses the session key of the secure communication channel to decrypt and obtain the server authentication key material UserR.

[0109] It should be noted that the terms "identity authentication" and "entity identification" referred to in this application may be used interchangeably in certain contexts. In particular, when a biological individual (such as a logged-in user) is involved as the identification object, for ease of understanding and expression, "identity authentication" is often used to refer to the process of identifying and confirming the biological entity. Although strictly speaking, entity identification focuses on identifying an objectively existing individual, while identity authentication focuses more on confirming whether the individual has certain permissions or qualifications, in this application, the two can be used interchangeably to a certain extent, and the specific meaning should be understood in conjunction with the context.

[0110] In the above embodiment, both the authentication server 120 and the authentication client 130 need to derive the authentication key UserK based on the server authentication key material UserR and the client authentication key material UserT. The key derivation process is completed using a key derivation function that meets the national cryptographic standards.

[0111] In one embodiment, the key derivation function used is the key derivation function KDF(P,S,c,dkLen) based on GM / T 0091-2020 "Password-based Key Derivation Specification". When using the key derivation function for key derivation, the server-side authentication key material UserR is used as the salt value S in the key derivation function, and the client-side authentication key material UserT is used as the password byte stream P in the key derivation function. The key derivation function KDF(P,S,c,dkLen) can be used to implement key derivation. Wherein, c represents the number of iterations, which is a positive integer and can be pre-configured. dkLen represents the length (bytes) of the key to be derived, which is a positive integer, and the maximum value is (2 32 -1)×h Len , h Len Indicates the number of bytes output by the pseudorandom function PRF. In one embodiment, the key derivation function used is the key derivation function based on 5.4.3 of GMT 0003.3-2012 "SM2 Elliptic Curve Public Key Cryptography Algorithm".

[0112] In one embodiment, the aforementioned identity authentication process for the application system login account can be completed based on the establishment of a secure communication channel between the authentication server 120 and the authentication client 130. In this case, one authentication client 130 is associated with one or more application system login accounts, thereby storing multiple application system login accounts and their corresponding authentication keys, UserK. The method for establishing a secure communication channel between the authentication server 120 and the authentication client 130 can be a method and system for constructing a secure resource channel for securely distributing and using remote hardware cryptographic resources in a soft computing environment. This method aims to ensure the secure transmission and controlled use of cryptographic resources in untrusted or open computing environments through cryptographic mechanisms. This method supports the secure introduction of remote hardware-level cryptographic resources in a verifiable, controllable, and isolable manner in various soft computing environments, including cloud computing, local computing, and edge computing, thereby providing data confidentiality, integrity, and authenticity protection capabilities for upper-layer application systems. The "remote cryptographic resources" in this solution include: cryptographic computing components with trusted execution capabilities, a high-quality random number source generated based on physical noise, a sensitive data storage module with physical protection capabilities, and a comprehensive key lifecycle management system (covering key generation, storage, distribution, use, and destruction). These cryptographic resources are deployed in a secure and controlled environment and imported into the authentication client 130 through a strict identity authentication and transmission mechanism. The authentication client 130 and the authentication server 120 first complete bidirectional identity authentication based on cryptographic algorithms to ensure the authenticity and legitimacy of both parties. Based on this authentication, a highly secure transmission channel is established to protect the remote cryptographic resources in the authentication server 120 from eavesdropping, tampering, or replay when crossing untrusted networks. Through this channel, the authentication server 120 can "extend" hardware-level cryptographic capabilities to the authentication client 130. The authentication client 130 further enhances the security of the operating system kernel: kernel-level access control mechanisms ensure that only authorized processes can access imported cryptographic resources; integrity monitoring of system calls and module loading behaviors prevents malicious tampering or unauthorized access; and kernel enhancements to the file system interface ensure that applications running in the authentication client 130's soft computing environment can stably and efficiently access critical cryptographic resources, even in the face of network delays or unstable connections, thereby ensuring the availability and sustainability of security mechanisms. Through the above mechanism, the method and system can build a highly secure resource channel from a remotely controlled hardware cryptographic platform to the application system process in various soft computing environments, realize the secure distribution and controlled use of remote hardware cryptographic resources, support the construction of distributed, elastic, and secure cryptographic service capabilities, and thus improve the data security level of the entire software computing environment.

[0113] In one embodiment, a method for establishing a secure communication channel between the authentication server 120 and the authentication client 130 includes:

[0114] The authentication server 120 uses local hardware resources to generate an identity certificate and embeds this identity certificate into the installation package of the authentication client 130 software; during operation, the authentication client 130 adopts a one-time pass authentication mechanism of digital signature technology and uses the built-in identity certificate of the authentication server 120 to authenticate the authentication server 120.

[0115] During the registration process for authentication clients 130, authentication server 120 pre-configures the sensitive security parameters (SSPs) required for initial connection to authentication server 120 in one or more authentication clients 130 and stores them in secure storage on authentication server 120. These SSPs can be passwords used to derive keys or random keys. Upon initial connection, authentication client 130 inputs its authentication password. A symmetric key is generated using the password-based key derivation protocol. Using a two-pass authentication mechanism using a symmetric encryption algorithm, authentication server 120 authenticates the client 130.

[0116] On the basis of the two-way identity authentication between the authentication server 120 and the authentication client 130 , a secure communication channel is established between the authentication server 120 and the authentication client 130 .

[0117] In one embodiment of the present application, after the authentication client 130 and the authentication server 120 complete bidirectional identity authentication, ECDHE can be used to perform key exchange between the two cryptographic modules to establish a secure channel, including the following steps:

[0118] 1. The authentication client 130 uses the random number encrypted and transmitted from the authentication server 120 during the identity authentication process to generate a pair of public and private keys (dB, HB) using SM2, and sends the public key HB to the authentication server 120.

[0119] 2. The authentication server 120 obtains a random number from a hardware random source, generates a pair of public and private keys (dA, HA) using SM2, sends the public key HA to the authentication client 130 and calculates the shared key S = dAHB.

[0120] 3. The authentication client 130 calculates the shared key S=dBHA and sends an ACK message to the authentication server 120.

[0121] 4. The authentication server 120 generates a session key using a random number, encrypts the session key using a shared key, and then sends it to the authentication client 130.

[0122] 5. The authentication client 130 uses the shared key to decrypt the session key and uses the session key to maintain secure communication with the authentication server 120.

[0123] 6. The authentication server 120 encrypts and sends the random number obtained from the hardware random source to the authentication client according to the configured time period, re-exchanges the key, establishes a new session key, and maintains a secure channel between the authentication client 130 and the authentication server 120.

[0124] In one embodiment of the present application, after the shared key S is exchanged between the authentication server 120 and the authentication client 130 using ECDHE, this shared key S can be used as key material to derive message encryption and decryption keys using a universal key derivation algorithm, and message encryption protection is performed in a one-time pad manner, thereby establishing a secure communication channel between the authentication server 120 and the authentication client 130.

[0125] In some embodiments, after a secure communication channel is established between each authentication client 130 and the authentication server 120, when the identity of the logged-in user of the application system login account is authenticated, the authentication client 130 immediately sends the saved client identification key material UserT to the authentication server 120. The secure communication channel can be used to send the client identification key material UserT. Specifically, the session key of the secure communication channel can be used to encrypt and protect the above-mentioned client identification key material UserT.

[0126] In some embodiments, after successfully authenticating the login user of the application system login account associated with the authentication client, the authentication server immediately generates a new server-side authentication key material UserR for the application system login account associated with the authentication client, and sends it to the above-mentioned authentication client 130. The above-mentioned sending of the new server-side authentication key material UserR can use the above-mentioned secure communication channel. Specifically, the session key of the secure communication channel can be used to encrypt and protect the above-mentioned new server-side authentication key material UserR.

[0127] In the above embodiment, when the authentication server 120 and the authentication client 130 establish a secure communication channel using the above method, during the identity authentication process, the session key generated when the secure communication channel is established can be used to encrypt and protect the data between the authentication server 120 and the authentication client 130.

[0128] In one embodiment, when the authentication server 120 and the authentication client 130 establish a secure communication channel using the above method, the authentication client 130 may also store the key or key seed for encrypting and protecting the identification key on the authentication server 120. When the identification key UserK is needed, the protection key is obtained from the authentication server 120 through the secure communication channel and then used to decrypt the locally stored identification key UserK.

[0129] In another embodiment, when authenticating the application system login account, the authentication client 130 immediately sends the saved client authentication key material UserT to the authentication server 120. The authentication client 130 can use encryption means to encrypt and protect the client authentication key material UserT and then send it to the authentication server 120. The encryption protection of the client authentication key material UserT can be to use the public key of the authentication server 120 to encrypt the data and then send it to the authentication server 120. The authentication server 120 will use its own private key to decrypt it to obtain the client authentication key material UserT.

[0130] At least some of the programs associated with the systems and methods of the embodiments described herein can be distributed in a computer program product comprising a computer-readable medium carrying computer-usable instructions for one or more processors. The medium can be provided in a variety of forms, including non-transitory forms such as, but not limited to, one or more magnetic disks, optical disks, tapes, chips, and magnetic and electronic storage.

[0131] A computer program is a set of instructions that can be executed by a computer (i.e., by a processor). A process is an instance of a program, i.e., a copy of the program in a computer's memory ready for execution by the computer's central processing unit (CPU). This application refers to a processor of a computer system and operations performed by a processor of a computer system. It should be understood that such references include one or more processing elements and the use of one or more processing elements to perform operations, such as one or more processing cores within one or more CPUs.

[0132] The above description is only a preferred embodiment of the present application, and the present application is not limited to the above embodiments. It is understood that other improvements and variations directly derived or imagined by those skilled in the art without departing from the spirit and concept of the present application should be considered to be included in the scope of protection of the present application.

Claims

1. A symmetric entity authentication method based on server-side dynamic key derivation, characterized in that: The symmetric entity identification method comprises: After receiving the login request containing the application system login account, the authentication server containing the hardware password resource forwards the login request to the authentication client bound to the application system login account; After receiving the login authorization for the login request, the authentication client sends the client authentication key material UserT corresponding to the application system login account to the authentication server. The authentication client also pre-stores the authentication key UserK corresponding to the application system login account; The authentication server performs dynamic key derivation based on the server authentication key material UserR corresponding to the application system login account stored in its own storage, combined with the received client authentication key material UserT, and instantly obtains the authentication key UserK corresponding to the application system login account; The authentication server uses the identification key UserK derived from the dynamic key based on a symmetric algorithm to authenticate the login user of the application system login account associated with the authentication client.

2. The symmetric entity identification method according to claim 1, characterized in that: The authentication server uses the identification key UserK derived from the dynamic key based on a symmetric algorithm to authenticate the login user of the application system login account associated with the authentication client, including: The authentication server immediately generates a random challenge value R, and combines it with the authentication key UserK derived from the dynamic key to generate an authentication challenge token TokenS and send it to the authentication client; The authentication client uses the pre-saved authentication key UserK corresponding to the application system login account to verify and parse the received authentication challenge token TokenS to obtain a random challenge value R'; The authentication client uses the parsed random challenge value R' as a random response, and uses the pre-saved authentication key UserK corresponding to the application system login account to calculate the authentication response token TokeU and return it to the authentication server; The authentication server uses the identification key UserK derived from the dynamic key to verify and parse the received authentication response token TokeU to obtain the random challenge value R"; when it is determined that the random challenge value R" obtained by parsing is consistent with the random challenge value R, it is determined that the identity authentication of the login user of the application system login account associated with the authentication client is successful, and the login request is passed and responded to.

3. The symmetric entity identification method according to claim 1, characterized in that: The symmetric entity identification method further comprises: The authentication server generates a random number using a built-in hardware random source to generate a server-side authentication key material UserR for a valid application system login account, stores the server-side authentication key material UserR in correspondence with the application system login account, and sends the server-side authentication key material UserR to the authentication client bound to the valid application system login account; The authentication client generates the client authentication key material UserT corresponding to the application system login account, and combines it with the received server authentication key material UserR to derive the authentication key UserK, and stores the authentication key UserK, the client authentication key material UserT and the application system login account in correspondence.

4. The symmetric entity identification method according to claim 3, characterized in that: The symmetric entity identification method further comprises: After the authentication server successfully authenticates the user of the application system login account with the cooperation of the authentication client, it generates a new server-side authentication key material UserR and encrypts it and sends it to the corresponding authentication client; The authentication client regenerates the client authentication key material UserT, and re-derives the key based on the received new server authentication key material UserR, and obtains the updated authentication key UserK which is stored in correspondence with the application system login account.

5. The symmetric entity identification method according to claim 4, characterized in that: The authentication server encrypts the newly generated server authentication key material UserR using the encryption key based on the symmetric encryption algorithm and sends it to the authentication client. The authentication client decrypts the newly generated server authentication key material UserR using the encryption key based on the symmetric encryption algorithm. The encryption key is the random challenge and random response generated during the identity authentication process and shared between the authentication server and the authentication client, or a derivative of the random challenge and random response. Alternatively, a secure communication channel is pre-established between the authentication server and the authentication client. The authentication server uses the session key of the secure communication channel to encrypt the newly generated server authentication key material UserR, and then sends it to the authentication client via the secure communication channel. The authentication client uses the session key of the secure communication channel to decrypt it to obtain the new server authentication key material UserR.

6. The symmetric entity identification method according to claim 3, characterized in that: The symmetric entity identification method further comprises: When registering an application system login account bound to an authentication client, the authentication server generates a user password for the application system login account, and uses the user password and the key derived from the password key to encrypt the server authentication key material UserR generated for the application system login account. The application system login account and its encrypted server authentication key material UserR are included in the registration QR code; the authentication client signs the registration QR code with the signature private key and sends it to the authentication client; The authentication client scans the registration QR code and uses the preset authentication server's signature verification public key to verify the digital signature in the registration QR code. After the verification is successful, the user password is obtained to derive the password key, and the password key is used to decrypt the encrypted server authentication key material to obtain the server authentication key material UserR.

7. The symmetric entity identification method according to claim 6, characterized in that: The information carried in the registration QR code includes barmsg||S PrivK (barmsg), where: S PrivK (barmsg) is the result of digitally signing barmsg using the signature private key PrivK of the authentication server 120; barmsg=Qid.AccountName||requestID||appID||verID||PinSalt||E PinK (UserR); Among them, Qid.AccountName is the application system login account; requestID is a random task identifier; appID is the device identifier of the authentication client 130, verID is a version number, PinSalt is a salt value used to derive the password key; E PinK (UserR) represents the result of encrypting the server authentication key material UserR using the password key PinK derived from the user password using a symmetric encryption algorithm; || represents a sequential concatenation operation.

8. The symmetric entity identification method according to claim 3 or 4, characterized in that: The authentication client uses the pre-stored public key of the authentication server to encrypt the client authentication key material UserT corresponding to the application system login account and sends it to the authentication server. The authentication server uses its own private key to decrypt the client authentication key material UserT. Alternatively, a secure communication channel is established between the authentication server and the authentication client in advance. The authentication client uses the session key of the secure communication channel to encrypt the client identification key material UserT corresponding to the application system login account, and then sends it to the authentication server via the secure communication channel. The authentication server uses the session key of the secure communication channel to decrypt and obtain the client identification key material UserT.

9. The symmetric entity identification method according to claim 1, characterized in that: The authentication client generates the client authentication key material UserT including: The authentication client uses the kernel-state entropy pool mechanism to generate a system random number to obtain the client authentication key material UserT; Alternatively, the authentication client generates a pseudo-random value based on the local timestamp and the local system random number through an HMAC function to obtain the client authentication key material UserT.

10. The symmetric entity identification method according to claim 1, characterized in that: The authentication client uses the first security key corresponding to the application system login account to encrypt, store and decrypt the identification key UserK corresponding to the application system login account; Alternatively, the authentication client uses the secure storage mechanism of the local operating system to protect the authentication key UserK corresponding to the locally stored application system login account. The secure storage mechanism implements the non-exportability and access control of the authentication key UserK based on the hardware security module, and limits the authentication key to be bound to a specific application signature and device status for use.

11. The symmetric entity identification method according to claim 10, characterized in that: The symmetric entity identification method further comprises: Collect and verify user feature information, and use the user feature verification success event to generate a session context or derive a first security key from the protected hardware module that is only accessible after the user feature information is verified.

12. The symmetric entity identification method according to claim 10, characterized in that: The symmetric entity identification method further comprises: A secure communication channel is established between the authentication server and the authentication client based on the user feature information of the authentication client. The authentication client obtains the first security key from the authentication server via the secure communication channel and uses the first security key to decrypt the encrypted authentication key UserK.

13. The symmetric entity identification method according to claim 1, characterized in that: The authentication server stores the correspondence between the server authentication key material UserR and the application system login account in the hardware password security storage space of the authentication server; Alternatively, the authentication server encrypts the generated server authentication key material UserR using the second security key stored in the hardware password security storage space, and stores the encrypted server authentication key material UserR in correspondence with the application system login account.

14. The symmetric entity identification method according to claim 1, characterized in that: The authentication client sends the client authentication key material UserT corresponding to the application system login account to the authentication server, including: The authentication client uses the pre-embedded identity certificate of the authentication server to perform a one-time entity authentication of the authentication server based on a digital signature, and after successfully authenticating the entity of the authentication server, it sends the client authentication key material UserT corresponding to the pre-stored application system login account to the authentication server.

15. The symmetric entity identification method according to claim 2, characterized in that: The authentication challenge token TokenS generated by the authentication server is: TokenS=appID||Qid.AccountName||ref||E UserK2 (R)||S PrivK (E UserK2 (R)||appID||Qid. AccountName||ref) The authentication response token TokeU calculated by the authentication client is: TokenU=appID||ref||E UserK2 (M UserK1 (appID||ref||R')||R') Among them, UserK=UserK1||UserK2,|| represents the sequential splicing operation; appID is the device identifier of the authentication client, Qid.AccountName is the application system login account, and ref is the task identifier; E UserK2 (R) represents the result of encrypting the random challenge value R using the symmetric encryption algorithm using the key UserK2; S PrivK (E UserK2 (R)||appID||Qid.AccountName||ref) indicates the use of the signature private key PrivK of the authentication server to authenticate E UserK2 (R)||appID||Qid.AccountName||refThe signature generated by the signature transformation; E UserK2 (M UserK1 (appID||ref||R')||R') indicates that the key UserK2 is used to identify M UserK1 (appID||ref||R')||R' is encrypted by the symmetric encryption algorithm; M UserK1 (appID||ref||R') represents a cryptographic verification value generated by a cryptographic verification function using the key UserK1 and the data string appID||ref||R' as input.

16. The symmetric entity identification method according to claim 1, characterized in that: The authentication server and authentication client use a key derivation function that meets national cryptographic standards to derive the authentication key UserK.

Images