Seamless integrated identity authentication system and method based on symmetric key dynamic derivation mechanism

Abstract

The invention discloses a seamless integrated identity authentication system and method based on a symmetric key dynamic derivation mechanism, the system comprises an authentication client, a password graph card server, an authentication server and a target information system, and a login entrance guard integrated with the target information system forwards a received authentication request to the authentication server; the authentication server sends the authentication request to an authentication client which has an account binding relationship with the user account identifier through a secure communication channel; the authentication client sends a client user authentication key material to the authentication server, and the authentication server derives a user authentication key according to the client and the server user authentication key material, calculates an authentication token and sends the authentication token to the authentication client; the authentication client verifies the authentication right label by using a locally stored user authentication key, calculates a response right label and sends the response right label to the authentication server; and after the authentication server verifies the response right mark, a permission token is generated and returned to the login entrance guard. According to the invention, seamless integration can be realized and the security is higher.

Description

Technical Field

[0001] This invention relates to identity authentication technology, and more particularly to a seamless integrated identity authentication system and method based on a symmetric key dynamic derivation mechanism. Background Technology

[0002] With the rapid growth of enterprise information systems and cloud services, various target information systems coexist, including web applications, database systems, and Linux / Windows servers. Identity authentication has gradually evolved from a localized function within a single system to a fundamental security capability across platforms and network boundaries. Currently, mainstream centralized authentication methods include Single Sign-On (SSO), directory services, and identity authentication gateways, which typically achieve unified authentication through proxy or forwarding. However, while these methods reduce system modification costs in engineering, they generally suffer from structural security problems such as wide exposure of authentication credentials, unsecured authentication chains, and untrusted key sources.

[0003] In existing architectures, authentication clients are mostly deployed in soft computing environments (such as terminals, virtual machines, or containers). Their key materials are typically stored in the form of configuration files, API tokens, or software credentials, which cannot rely on trusted hardware protection and are vulnerable to attacks such as debug injection, memory theft, offline analysis, and dictionary attacks. Meanwhile, after the target system obtains the user's entered account information, it sends the authentication request to the authentication client or authentication gateway, which then verifies the signature, password, or credentials with the authentication server—an environment outside the password security domain. This makes user credentials extremely easy to steal or tamper with in system logs, API calls, and proxy chains, resulting in a lack of security in the authentication chain.

[0004] On the other hand, in existing authentication systems, the authentication server often needs to store the static symmetric keys or their derivatives from each client for a long time before it can perform authentication. This not only introduces the risk of key leakage due to centralized storage, but also lacks guarantees for the freshness and uniqueness of each session, making it vulnerable to replay attacks. In addition, existing systems are difficult to use hardware cryptographic modules (such as HSM, TPM, TEE) in soft computing environments, and cannot achieve controlled derivation and secure execution of device authentication keys or user authentication keys.

[0005] To address the aforementioned issues, existing technologies have attempted to improve security through external physical carriers or hardware cryptographic modules, but most of these only solve single-point problems: either they cannot obtain account information in the target information system's native login process, or they still require modifications to the target system's underlying authentication framework, lacking seamless integration capabilities for large-scale deployment; or although hardware root keys have been introduced, the risks of authentication links spanning multiple systems and credentials being exposed during transmission at different network nodes have not been resolved. Summary of the Invention

[0006] To address the problems existing in the prior art, the purpose of this invention is to provide a seamlessly integrated identity authentication system and method based on a symmetric key dynamic derivation mechanism, which offers enhanced security, ensures seamless integration, prevents credential exposure across multiple systems, and provides a more secure authentication link.

[0007] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0008] A seamless integrated identity authentication system based on a symmetric key dynamic derivation mechanism includes:

[0009] A password card server is used to provide password cards to users. The password cards contain trusted initialization information to support the secure operation and key processing of authentication clients, and help authentication clients register and bind with one or more authentication servers.

[0010] An authentication client is used to work with the authentication server to derive at least one symmetric authentication key based on the trusted initialization information in the cryptographic card, and to cooperate with the authentication server to perform entity identity authentication of the user account identifier belonging to the user logging into the target information system based on the symmetric authentication key.

[0011] The authentication server is used to work with the authentication client to derive the symmetric authentication key; and based on the symmetric authentication key, work with the authentication client to complete the entity identity authentication of the user account to which the login target information system belongs; and output the entity identity authentication result obtained from the interaction with the authentication client to the integrated login gatekeeper;

[0012] An integrated login gatekeeper is seamlessly integrated into the target information system as a plug-in or module. It is used to obtain the login user account identifier during the login process of the target information system, relay the authentication-related information associated with the user account identifier to the authentication server, receive the entity identity authentication result from the authentication server, and transmit the entity identity authentication result to the target information system.

[0013] The authentication client establishes a secure communication channel with the authentication server, and performs at least the following functions based on this secure communication channel:

[0014] The authentication server provides cryptographic computation service resources to the authentication client through the secure communication channel, enabling the authentication client to perform key processing-related operations using the secure cryptographic capabilities of the authentication server.

[0015] The authentication server forwards authentication-related information from the integrated login gatekeeper to the authentication client through the secure communication channel, enabling the target information system to complete the user identity authentication process without directly communicating with the authentication client.

[0016] Furthermore, the authentication client is configured as follows:

[0017] After receiving the cipher card from the cipher card server, perform initialization processing to start the authentication client;

[0018] Based on the trusted initialization information in the cryptographic card, a local symmetric authentication key and encryption parameters for encrypting the symmetric authentication key are generated.

[0019] The symmetric authentication key is stored locally for protective purposes based on the encryption parameters.

[0020] The password image card server is configured as follows:

[0021] Based on the initialization request from the authentication client, generate a cryptographic card containing trusted initialization information and provide it to the authentication client;

[0022] The server-side symmetric authentication key material associated with the authentication client is encrypted and forwarded to the authentication server, thereby enabling the authentication client to register and bind with one or more authentication servers;

[0023] Furthermore, the authentication client is configured as follows:

[0024] When a user account is associated with an authentication client, an account binding request containing the authentication client identifier and the user account identifier is sent to the authentication server.

[0025] After receiving the data related to account binding returned by the authentication server, perform account binding related processing;

[0026] Based on the trusted initialization information in the password card, the processing results related to account binding are stored protectively.

[0027] The authentication server is configured as follows:

[0028] Generate account binding-related data based on the account binding request and return it to the authentication client;

[0029] Establish and record the account binding relationship between user account identifiers and authentication client identifiers.

[0030] Furthermore, the authentication server and authentication client are configured as follows:

[0031] The authentication server interacts with the authentication client, using a symmetric authentication key to implement an entity authentication protocol based on a symmetric algorithm, thus completing the entity authentication of the authentication client by the authentication server.

[0032] The authentication server interacts with the authentication client, using the server's private key to implement an entity authentication protocol based on an asymmetric algorithm, thus completing the authentication client's entity authentication of the authentication server.

[0033] When the two-way entity authentication is successful, a secure communication channel is established between the authentication server and the authentication client;

[0034] Furthermore, the authentication server is configured as follows:

[0035] The authentication-related information from the integrated login gatekeeper is forwarded to the authentication client that has an account binding relationship with the logged-in user account identifier through the secure communication channel;

[0036] Based on the received client symmetric authentication key material and the locally stored server symmetric authentication key material, a symmetric authentication key for user authentication is derived, and the derived symmetric authentication key is used in conjunction with the authentication client to authenticate the user's identity.

[0037] After the user's identity is successfully authenticated, login permission information is generated and returned to the integrated login gatekeeper;

[0038] The authentication client is configured as follows:

[0039] Generate client-side symmetric authentication key material and send it to the authentication server;

[0040] Based on the symmetric authentication key stored locally for user authentication, the system collaborates with the authentication server to authenticate the user's identity.

[0041] Furthermore, a context parameter is introduced when deriving the symmetric authentication key. The context parameter includes at least one or more of the following: a unique identifier for the cryptographic card, an authentication client identifier, a timestamp, or a random number.

[0042] Furthermore, the authentication client is configured to register and bind with one or more authentication servers. When performing the registration and binding, the authentication server submits its identity public key to the cipher card server. The cipher card server uses the identity public key to encrypt and send the server-side symmetric authentication key material corresponding to the authentication client to the authentication server, thereby realizing the registration and binding between the authentication client and the authentication server.

[0043] Furthermore, after authentication is completed, the authentication client performs secure erasure of the temporary data used during the session.

[0044] Furthermore, the cryptographic card carries additional information to assist the authentication client in performing local protective processing. When the authentication client verifies the trustworthiness of the cryptographic card, it performs protective processing on the client's local data related to the symmetric authentication key based on the additional information.

[0045] Furthermore, the authentication client cryptographic module receives information from the cryptographic card through peripheral interaction, and, after verifying the trustworthiness of the cryptographic card, uses the trusted initialization information in the cryptographic card to construct a protective area for storing authentication-related data.

[0046] Furthermore, after receiving the login permission information sent by the authentication server, the integrated login gatekeeper shall at least verify the consistency between the signature or MAC, the expiration time and the user account identifier. If the verification fails or the timeout does not return, the login request shall be rejected by default.

[0047] Furthermore, each time the authentication server successfully completes entity identity authentication based on the symmetric authentication key, it immediately updates the symmetric authentication key and securely erases the old symmetric authentication key.

[0048] A seamless integrated identity authentication method based on a symmetric key dynamic derivation mechanism includes:

[0049] The integrated login gatekeeper obtains the user account identifier during the login process of the target information system and relays the authentication-related information associated with the user account identifier to the authentication server; wherein, the integrated login gatekeeper is seamlessly integrated into the target information system in the form of a plug-in or module;

[0050] The authentication server, based on a symmetric authentication key, collaborates with the authentication client to authenticate the entity identity of the user account to which the login target information system belongs. The symmetric authentication key is derived from trusted initialization information in a cryptographic card and is obtained collaboratively with the authentication client. The cryptographic card is provided to the user by the cryptographic card server and contains trusted initialization information to support the secure operation and key processing of the authentication client.

[0051] The authentication server outputs the entity identity verification result obtained from the interaction with the authentication client to the integrated login gatekeeper;

[0052] The integrated login gatekeeper receives the entity identity authentication result from the authentication server and transmits the entity identity authentication result to the target information system;

[0053] The authentication client and the authentication server establish a secure communication channel, and at least the following functions are implemented based on this secure communication channel:

[0054] The authentication server provides cryptographic computation service resources to the authentication client through the secure communication channel, enabling the authentication client to perform key processing-related operations using the secure cryptographic capabilities of the authentication server.

[0055] The authentication server forwards authentication-related information from the integrated login gatekeeper to the authentication client through the secure communication channel, enabling the target information system to complete the user identity authentication process without directly communicating with the authentication client.

[0056] Compared with the prior art, the beneficial effects of this invention are as follows: The integrated login gatekeeper of this invention is seamlessly integrated into the target information system without changing the underlying login framework of the target information system. It achieves seamless integration with its native authentication process. The target information system does not directly interact with the authentication client, nor does it process user credentials or key materials. The authentication link is completely closed within the secure communication channel established between the authentication client and the authentication server, reconstructing the authentication link and the password security boundary, thereby realizing a highly secure and scalable multi-factor authentication system. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of the overall structure of an embodiment of the seamless integrated identity authentication system based on the dynamic derivation mechanism of symmetric keys provided by the present invention;

[0058] Figure 2 This is an initialization flowchart of the authentication client provided in an embodiment of the present invention;

[0059] Figure 3 This is a flowchart illustrating the process of binding an authentication client to a target information system account, as provided in this embodiment of the invention.

[0060] Figure 4 This is a flowchart illustrating the establishment of a secure channel between the authentication client and authentication server based on two-way entity authentication, as provided in this embodiment of the invention.

[0061] Figure 5 This is a flowchart illustrating the identity authentication method provided in an embodiment of the present invention. Detailed Implementation

[0062] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0063] like Figure 1As shown, in one embodiment of this application, a seamless integrated identity authentication system 100 based on a symmetric key dynamic derivation mechanism is provided. The system includes an authentication client 110, a cryptographic card server 120, an authentication server 130, a target information system 140 (with an integrated login gatekeeper 141), and a cryptographic card 150. The cryptographic card server 120 generates the cryptographic card 150 for the authentication client 110. Furthermore, the system includes hardware cryptographic resources (hardware cryptographic resource 131 and hardware cryptographic resource 121, respectively) deployed on the authentication server and the cryptographic card server sides, providing high-strength random number generation, secure storage, and cryptographic computation capabilities, thereby enhancing overall cryptographic security.

[0064] In one embodiment, the authentication client 110 can be deployed in a soft computing environment such as a terminal, virtual machine, or container, and has an internal authentication client cryptographic module 111, which is used to derive at least one symmetric authentication key in collaboration with the authentication server 130 based on the trusted initialization information in the cryptographic card, and to perform entity identity authentication of the user account identifier belonging to the user who logged into the target information system 140 based on the symmetric authentication key.

[0065] During the initialization phase, the authentication client 110 interacts with the cryptographic card server 120 to import the registration initialization data generated by the cryptographic card server, as well as the device protection key 151 and related parameters encapsulated in the cryptographic card 150. The authentication client 110 generates a client device authentication key material DevT and, combined with the server device authentication key material DevR from the cryptographic card server, derives the device authentication key DevK through dynamic key derivation. The derived DevK is encapsulated and stored by the device protection key 151 in the cryptographic card 150, forming a device identity credential for bidirectional entity authentication in subsequent authentication phases.

[0066] In one embodiment, the trusted initialization information in the cryptographic card includes a random number from the cryptographic card server. This can be a key used directly for data encryption and storage protection on the authentication client, such as the device protection key mentioned above, or it can be a key or key seed used to generate data encryption and storage protection on the authentication client.

[0067] During the login authentication phase, the authentication client 110 collaborates with the authentication server 130 through the established secure communication channel to generate the client user authentication key material UserT, and participates in identity authentication based on dynamic key derivation after user authorization, thereby ensuring multi-factor security verification of the login account of the target information system 140.

[0068] In one embodiment, the cryptographic card server 120 internally includes a cryptographic card server cryptographic module 122 and hardware cryptographic resources 121. The cryptographic card server cryptographic module 122 and hardware cryptographic resources 121 work together to perform high-strength random number generation, key generation, key material generation, and encrypted issuance operations. The cryptographic card server cryptographic module 122 generates a cryptographic card 150 for the authentication client 110. The cryptographic card 150 contains trusted initialization information to support the secure operation and key processing of the authentication client. The cryptographic card server 120 can record the mapping relationship between the cryptographic card 150 and the user identifier for subsequent auditing and identity traceability.

[0069] In one embodiment, the password card can be: cardmsg||S PrivK (cardmsg), where: cardmsg=AppID||VerID||E PinK (DevPK) represents the mixed information of the graphics card. DevPK is the device protection key 151, which is randomly generated by the authentication server based on a hardware random number generator; E PinK (DevPK) represents the ciphertext obtained by encrypting DevPK with the device password key PinK. The encryption method can be SM4-CBC. The device password key PinK can be derived from the device password Pin (at least eight characters, containing at least one number, at least one uppercase character, at least one lowercase character, and at least one special character) and the device salt PinSalt (a random number generated by hardware cryptographic resources) using GM / T0091-2020 "Password-Based Key Derivation Specification"; S PrivK (cardmsg) is the digital signature value obtained by calculating cardmsg using the server's private key PrivK.

[0070] In one embodiment, the additional information carried by the password card may include the device password that the user needs to remember, and / or the device salt value.

[0071] In one embodiment, the QR code data can be stored in the physical form of a QR code card; in another embodiment, the QR code data can also be stored in other storage devices, such as a smart key, in the form of a data file; in yet another embodiment, the data of the QR code card can also be stored in the smart key in the format of a data file.

[0072] In this embodiment, the authentication client 110 can import the cryptographic card information via scanning, NFC, Bluetooth, or USB, and generate an encrypted storage area after verifying the signature to store the device-level derivation result (DevK). During the generation of the cryptographic card 150, the cryptographic card server 120 can use encryption and signature algorithms conforming to national or international standards (including but not limited to SM2, SM3, SM4, RSA, and AES) to encrypt and issue the card content, thereby ensuring the integrity and security of the card.

[0073] In one embodiment, the symmetric authentication key can be distinguished into a device authentication key specifically for entity authentication of the authentication client and a user authentication key specifically for entity authentication of the login account of the information system. In this case, the device authentication key can be derived from server-side device authentication key material generated by the authentication server and client-side device authentication key material generated by the authentication client, and the user authentication key can be derived from server-side user authentication key material generated by the authentication server and client-side user authentication key material generated by the authentication client. In this case, the server-side symmetric authentication key material can be either server-side device authentication key material or server-side user authentication key material, and the client-side symmetric authentication key material can be either client-side device authentication key material or client-side user authentication key material.

[0074] In another embodiment of this application, the symmetric authentication key may also be the same user authentication key used for both entity authentication of the authentication client and entity authentication of the login account of the information system. In this embodiment, the user authentication key and the device authentication key may be the same symmetric authentication key. In this case, the symmetric authentication key may be derived from the server-side symmetric authentication key material generated by the authentication server and the client-side symmetric authentication key material generated by the authentication client. In this case, the server-side symmetric authentication key material may be both the server-side device authentication key material and the server-side user authentication key material, while the client-side symmetric authentication key material may be both the client-side device authentication key material and the client-side user authentication key material.

[0075] In one embodiment of this application, the encryption parameter used to encrypt and protect the symmetric encryption key can be a device protection key used to encrypt and protect the device authentication key, or a user protection key used to encrypt and protect the user authentication key; in another embodiment of this application, the encryption parameter used to encrypt and protect the symmetric encryption key can be both a device protection key used to encrypt and protect the device authentication key and a user protection key used to encrypt and protect the user authentication key.

[0076] In one embodiment, the authentication server 130 internally includes an authentication server cryptographic module 132 and a corresponding hardware cryptographic resource 131. The authentication server 130 provides high-quality random number generation, secure storage, and symmetric / asymmetric cryptographic operation functions through the authentication server cryptographic module 132 and the hardware cryptographic resource 131, providing controlled cryptographic computation capabilities to the authentication client 110. The authentication server 130 is used to collaboratively derive the symmetric authentication key with the authentication client 110; and based on the symmetric authentication key, collaborates with the authentication client 110 to complete the entity identity authentication of the user to whom the target information system login account belongs; and outputs the entity identity authentication result obtained based on the interaction with the authentication client 110 to the integrated login gatekeeper 141.

[0077] Before the system runs, authentication client 110 and authentication server 130 perform two-way entity authentication based on device identity credentials: authentication server 130 verifies the client's identity using the device authentication key, and authentication client 110 verifies the server's identity using the authentication server's identity credentials (such as a public key or certificate). Once both parties successfully verify each other's identities, they negotiate and generate a session key and establish a secure communication channel. This channel is used for subsequent account binding, dynamic key derivation, and entity authentication processes. All authentication interactions are completed through this secure channel, thereby ensuring the confidentiality and integrity of communication.

[0078] During the account binding phase, the authentication server 130 generates a server-side user authentication key material UserR and sends it to the authentication client 110 for the client to derive a user authentication key UserK. The authentication server 130 records the account binding relationship between the target information system account and the authentication client. During the authentication phase, based on the login request forwarded by the integrated login gatekeeper 141, the authentication server 130 locates the corresponding authentication client 110 according to the account binding relationship, initiates authentication interaction, and returns the authentication result to the integrated login gatekeeper 141 after authentication is completed.

[0079] In one embodiment, the target information system 140 is a real-world application environment requiring enhanced identity authentication, which may be a web system, a database system, or a Linux or Windows operating system. The integrated login gatekeeper 141 is integrated into the native authentication extension point of the target information system 140 as a plugin or module, such as the PAM module for Linux, the SubAuth / LSA extension for Windows, a database or web login plugin, etc. Without altering the underlying login framework of the target information system, the integrated login gatekeeper 141 intercepts the native account information in the login process and forwards the authentication request to the corresponding authentication client 110 via the authentication server 130. The integrated login gatekeeper 141 is used to obtain the user account identifier during the login process of the target information system 140 and relay the authentication-related information associated with that user account identifier to the authentication server; receive the entity identity authentication result for the user from the authentication server; and transmit the entity identity authentication result to the target information system. The integrated login gatekeeper 141 does not communicate directly with the authentication client; all its authentication interactions are relayed through the authentication server 130 in a secure communication channel. After authentication is completed, the authentication server 130 returns the login permission token to the integrated login gatekeeper 141. The integrated login gatekeeper 141 verifies the signature or MAC field and then controls the login access to the target information system. If the verification fails or no response is returned after a timeout, the login request is rejected by default.

[0080] In one embodiment, either the authentication server 130 or the integrated login gatekeeper 141 can be used to maintain the registration and binding relationship between the target information system account and the authentication client. This registration and binding relationship record includes at least the target information system identifier, the original account identifier, the authentication client identifier, the registration and binding version, a timestamp, and status information. Upon receiving an authentication request forwarded by the integrated login gatekeeper 141, the authentication server 130 locates the authentication client 110 that needs to participate in authentication based on the registration and binding relationship and forwards authentication data to it within a secure communication channel.

[0081] like Figure 1As shown, the authentication request chain in this embodiment is reconstructed as follows: Target Information System 140 → Integrated Login Gatekeeper 141 → Authentication Server 130 ↔ (Secure Communication Channel) ↔ Authentication Client 110 → Authentication Server 130 → Integrated Login Gatekeeper 141 → Target Information System 140. The Target Information System 140 and Integrated Login Gatekeeper 141 are outside the cryptographic security boundary; the secure communication channel between the Authentication Server 130 and the Authentication Client 110, and the key derivation, authentication verification, and cryptographic calculation processes executed internally, are all within the cryptographic security boundary. This structural design achieves seamless integration with the target information system's native authentication process without altering the underlying login framework, and reconstructs the authentication chain and cryptographic security boundary at the system level, thereby realizing a highly secure and scalable multi-factor authentication system.

[0082] This structural design achieves seamless integration with the target information system's native authentication process without altering the underlying login framework, and reconstructs the authentication chain and password security boundaries at the system level, thereby realizing a highly secure and scalable multi-factor authentication system.

[0083] In one specific implementation, the login interface or login interface of the target information system remains unchanged. After the user enters account information, this account information is first captured by an integrated login gatekeeper (e.g., integrated into the target information system as a plugin). The integrated login gatekeeper does not verify the account information but encapsulates it into an authentication request and forwards it to the authentication server through a pre-configured communication interface. Upon receiving the account information from the integrated login gatekeeper, the authentication server initiates an authentication interaction with the corresponding authentication client based on the account binding relationship between the target information system and the authentication client. To ensure that the authentication interaction is not intercepted or tampered with, a secure communication channel is pre-established between the authentication client and the authentication server through dynamic derivation of a symmetric key and bidirectional entity authentication. This channel is used for the encrypted transmission of subsequent authentication requests, intermediate verification data, and authentication results. Throughout the authentication process, there is no direct communication path between the target information system and the authentication client, nor does the target information system participate in key negotiation or the generation and verification of authentication credentials. The target information system only receives the authentication result from the authentication server and performs login permission or denial accordingly. The target information system cannot access the encrypted communication content between the authentication client and the authentication server.

[0084] In this way, the user's account information and authentication request are separated from the target information system's native authentication process and all converged into the secure communication link built between the authentication server and the authentication client. This achieves the unification of the authentication request link and the scope of credential protection, forming an encrypted domain composed of a secure channel, reducing the risk of exposure or leakage of user credentials during transmission, storage, or processing inside and outside the system.

[0085] The identity authentication method provided in this embodiment specifically includes the initialization steps of the authentication client 110, the account binding steps of the authentication client 110 and the user account, the establishment steps of the secure communication channel, and the identity authentication steps.

[0086] In one embodiment, the initialization steps of the authentication client 110 mainly include interaction between the cryptographic card server 1 and the authentication client. To achieve initialization, the authentication client is configured to: upon receiving a cryptographic card from the cryptographic card server, execute initialization processing to start the authentication client; generate a local symmetric authentication key and encryption parameters for encrypting the symmetric authentication key based on the trusted initialization information in the cryptographic card; and perform local protective storage of the symmetric authentication key based on the encryption parameters. The cryptographic card server is configured to: generate a cryptographic card containing trusted initialization information according to the initialization request from the authentication client and provide it to the authentication client. Specific steps are as follows... Figure 2 As shown below:

[0087] S201, The user triggers or the authentication client 110 actively initiates an initialization request to the password card server 120.

[0088] The initialization request is triggered by the user or initiated by the authentication client 110. Specifically, it can be triggered when the user registers with the password card server 120, or it can be initiated automatically by the authentication client, or it can be manually triggered by the user in the terminal application.

[0089] S202, Password card server 120 generates initialization-related data based on the received initialization request.

[0090] In this embodiment, the initialization-related data includes at least the server-side device authentication key material DevR and the authentication client identifier AppID. DevR is randomly generated by the cryptographic module 122 of the cryptographic card server 120 in combination with its hardware cryptographic resources 121 to ensure the randomness and uniqueness of DevR.

[0091] In one embodiment, the aforementioned initialization-related data may be an initialization QR code generated by the password image card server: barcode=barmsg||S PrivK (barmsg), where:

[0092] barmsg=requestId||AppID|| VerID ||PinSalt||E DevPK2 (DevR||SessR0)

[0093] In the formula, barmsg represents initialization integration information, || represents the connection operation, requestId is the task identifier, specifically a random number, AppID is the authentication client identifier assigned by the cipher card server 120 to the authentication client, specifically a new random number used to uniquely identify the authentication client that needs to be initialized; VerID is the version number of the cipher card used; PinSalt is the salt value used in the process of generating the cipher card; DevR is the server device authentication key material; SessionR0 is the session initiation key material, used to generate the session key for establishing a secure channel, specifically randomly generated for each authentication client; S PrivK (barmsg) is the digital signature value calculated using the private key PrivK of the cryptographic card server. PrivK is pre-stored in the hardware cryptographic resources of the cryptographic card server. DevPK2 () indicates that DevPK is used to perform encryption operations.

[0094] S203. After receiving the initialization-related data, the authentication client randomly generates a client device authentication key material DevT and performs device-level dynamic key derivation using the client device authentication key material DevT and the server device authentication key material DevR to obtain the device authentication key DevK.

[0095] In this embodiment, the client device authentication key material DevT is the local random number resource and / or local timestamp of the authentication client. DevT is not necessarily a hardware-level random number, but since it is derived together with DevR when the final derived key is generated, and DevR is a hardware-level random number, it does not affect the entropy value of the final derived key.

[0096] In one embodiment, to prevent replay and collisions, the derivation process introduces context parameters, which include at least one or more of the following: CardID (unique identifier for cipher card), DeviceID (device identifier), timestamp, or random number.

[0097] In one embodiment, the device authentication key DevK can be derived using one or more of KDF, HKDF, HMAC-KDF, PBKDF2, scrypt, Argon2, or a dynamic key derivation function based on SM3. The device authentication key DevK is the aforementioned symmetric authentication key.

[0098] S204. The password card server generates a password card based on the initialization data and sends it to the authentication client.

[0099] In this embodiment, the cryptographic card 150, in addition to the authentication client identifier, also includes an encrypted device protection key 151 and a cryptographic card version number, etc., which form trusted initialization information. During the issuance process, the cryptographic card server can use encryption and signature algorithms conforming to national or international standards (such as SM2, SM3, SM4, RSA, AES, etc.) to encrypt and sign the card content to ensure the integrity and trustworthiness of the card content. The cryptographic card can be imported into the authentication client via scanning a QR code, reading an NFC tag, Bluetooth, or USB interface.

[0100] S205. After receiving the password card, the authentication client verifies the password card and extracts the device protection key from the password card.

[0101] In this embodiment, after receiving the cryptographic card, the authentication client 110 first verifies the legality and integrity of the card's signature. Upon successful verification, the authentication client calculates the device protection key 151 based on the parameters within the cryptographic card. The device protection key 151 is the encryption parameter used to encrypt the symmetric authentication key.

[0102] S206. The authentication client uses the device protection key to encrypt the derived device authentication key and then stores it locally.

[0103] In this embodiment, the authentication client 110 uses the device protection key 151 from the cryptographic card to encrypt and encapsulate the derived device authentication key DevK, and generates an encrypted storage area locally to store protected sensitive data and related metadata. The encrypted storage area is used to resist attacks such as memory debugging, disk mirroring, and local injection, thereby ensuring the secure storage of device-level keys in a soft computing environment.

[0104] S207. The authentication client sends a registration completion confirmation message to the password card server.

[0105] In this embodiment, after the issuance of the cryptographic card, key derivation, and protection encapsulation processes are completed, the authentication client 110 sends a registration completion confirmation to the cryptographic card server 120. The cryptographic card server records the binding relationship between the cryptographic card and the cryptographic card user account and returns confirmation information; at this point, the registration process of the authentication client ends. Here, the cryptographic card user account is the account of the authentication client owner on the cryptographic card server. The cryptographic card server assigns a unique cryptographic card user account to each user.

[0106] In one embodiment, after the authentication client completes registration with the cryptographic card server, a registration binding mechanism between the authentication client and the authentication server is further provided to establish a cross-domain secure trust relationship and provide key support for the establishment of subsequent secure communication channels.

[0107] In this embodiment, after completing registration, the authentication client obtains its public key and authentication domain identifier information from the target authentication server and submits the authentication server's public key to the cryptographic card server. The cryptographic card server, acting as a trusted intermediary, extracts the server-side device authentication key material (DevR) generated for the authentication client from its key storage area and encrypts and encapsulates the DevR using the authentication server's public key to form ciphertext. This encryption and encapsulation is performed by the cryptographic module of the cryptographic card server, employing asymmetric encryption and signature algorithms (such as SM2, RSA, ECC, etc.) that conform to national or international standards to ensure the confidentiality and data integrity during transmission.

[0108] In this embodiment, the cryptographic card server returns the encrypted DevR ciphertext to the authentication client. Without decrypting the ciphertext, the authentication client securely forwards it to the corresponding authentication server via its protected communication channel. Upon receiving the encapsulated data, the authentication server uses its private key to decrypt and obtain the DevR, thereby establishing a copy of the device authentication key material for that authentication client on the server side.

[0109] Based on the above information, the authentication server and client can then perform bidirectional entity authentication using DevR and DevT, negotiate and generate a session key, and establish a secure communication channel. This secure communication channel is used to carry subsequent operations such as dynamic key derivation, authentication calculation, random number distribution, and user authentication.

[0110] In this embodiment, an authentication client can register and bind with multiple different authentication servers. The cryptographic card server records the DevR encapsulation mapping relationship between each authentication client and different authentication servers, thereby supporting the authentication client to establish independent secure communication channels in multiple independent authentication domains and provide multi-domain identity authentication services in conjunction with different target information systems. This mechanism not only ensures the confidentiality and non-repudiation of DevR during transmission, but also enables the authentication client to flexibly expand to multi-authentication server scenarios, improving the system's cross-domain adaptability and security isolation capabilities.

[0111] The account binding process between the authentication client and the target information system user account is mainly completed collaboratively by the authentication client and the authentication server, with the participation of a password card for protection, to ensure the secure generation and storage of account binding credentials. To achieve account binding, the authentication client is configured to: send an account binding request containing the authentication client identifier and the user account identifier to the authentication server when the user account is associated with the authentication client; after receiving the account binding-related data returned by the authentication server, perform account binding-related processing; and protectively store the processing results related to account binding based on the trusted initialization information in the password card. The authentication server is configured to: generate account binding-related data according to the account binding request and return it to the authentication client; and establish and record the account binding relationship between the user account identifier and the authentication client identifier.

[0112] As shown in Figure 3, the account binding process includes the following steps:

[0113] S301, the authentication client 110 initiates an account binding request to establish an account binding relationship with a specified login account in the target information system 140. In one embodiment, the authentication client 110 initiates an account binding request to establish an account binding relationship with a specified login account in the target information system 140. This request can be triggered by the login gatekeeper 141 when the user logs in, or it can be initiated independently by the authentication client after registration.

[0114] S302. The authentication client generates an account binding request and sends it to the authentication server.

[0115] In this embodiment, the account binding request includes at least the authentication client identifier AppID and the user account identifier AccountName that require account binding, which are used to uniquely identify the target information system and its login account.

[0116] S303. After receiving the account binding request, the authentication server randomly generates server-side user authentication key materials.

[0117] In this embodiment, upon receiving an account binding request, the cryptographic module 132 of the authentication server 130 calls its hardware cryptographic resource 131 to generate a server-side user authentication key material UserR, which serves as the account binding-related data. UserR is a high-strength random variable with sufficient entropy and uniqueness to ensure the security of subsequent key derivation.

[0118] In one embodiment, the account binding data bindToken sent by the authentication server to the authentication client can be:

[0119] bindToken = bindmsg|| H DevK1(bindmsg),

[0120] bindmsg=AppID||request||AInfo|| E DevK2 (UserR||UserPR),

[0121] AInfo=CustomerId&gqid&accountName,

[0122] Bindmsg contains comprehensive account binding information, AInfo contains user information, DevK is the device authentication key established during registration on the authentication client. In practical applications, this key is divided into two parts: DevK1 is used for integrity calculations, and DevK2 is used for confidentiality calculations. request is a random task identifier; UserR is the server-side user authentication key material, and UserPR is the user protection key material used to protect the user authentication key on the authentication client. It is a hardware random number randomly generated by the authentication server. HDevK1() represents the Message Authentication Code (MAC) calculated using DevK1 as the key. CustomerID is an identifier of the owner of a target information system on the authentication server, and gqid is the identifier of the target information system on the authentication server. These two identifiers, together with AccountName, uniquely identify a login account in a specific target information system on the authentication server. Such an authentication server can support identity authentication services for multiple target information systems from multiple organizations.

[0123] S304. The authentication server sends the server-side user authentication key material UserR as account binding related data to the authentication client.

[0124] S305. After receiving the server's user authentication key material, the authentication client randomly generates client user authentication key material locally, and derives the user authentication key based on the server's user authentication key material and the client's user authentication key material.

[0125] In this embodiment, after receiving UserR, the cryptographic module 111 of the authentication client 110 generates a client user authentication key material UserT locally. UserT is generated by the authentication client using a local random source and / or timestamp, thereby introducing an independent random number or time factor to enhance the dynamic nature and replay protection of the key. The authentication client then executes a dynamic key derivation function with UserR and UserT as inputs to obtain the user authentication key UserK. This derivation function can employ one or more of the KDF, HKDF, PBKDF2, or SM3 derivation algorithms to ensure key derivation strength.

[0126] S306. The authentication client verifies the legality of the password card and derives the user protection key after successful verification.

[0127] The user protection key can be generated using local cryptographic resources.

[0128] S307. The authentication client encrypts the user authentication key using a user protection key and stores it locally.

[0129] Specifically, the authentication client 110 uses a derived user protection key to encrypt and encapsulate UserK, storing it securely locally only in ciphertext form and not sending it back to the authentication server in plaintext. This ensures the protective storage of processing results related to account binding. This design guarantees that UserK is held and used only on the client side, thereby preventing the server or third parties from obtaining user-level authentication credentials.

[0130] S308. The authentication client sends an account binding completion confirmation message to the authentication server.

[0131] S309. The authentication server generates a user account-authentication client account binding relationship by binding the authentication client identifier and user account identifier to the account, and records it in the account binding management table.

[0132] The authentication server 130 records the account binding relationship in its account binding management table. The record includes at least the user account identifier (AccountName), the authentication client identifier (AppID), the account binding version, timestamp, and status information. The system supports one-to-one or one-to-many account binding configurations. That is, an authentication client can bind its account to the user's account identifier (AccountName) in a specific target information system for authentication when logging into the target information system. Alternatively, an authentication client can bind its account to multiple user account identifiers (AccountName) in multiple target information systems to accommodate the need for the same user to log in across terminals and multiple target information systems. Both the authentication server and the login gatekeeper 141 can read and maintain this account binding relationship for subsequent client location and verification in authentication requests.

[0133] In one embodiment, a secure communication channel is established between the authentication client and the authentication server through a collaborative process of device-level dynamic key derivation and bidirectional entity authentication to ensure the confidentiality and integrity of subsequent authentication data interactions. To establish the secure communication channel, the authentication server and authentication client are configured as follows: the authentication server interacts with the authentication client, using a symmetric authentication key to implement an entity authentication protocol based on a symmetric algorithm, completing the authentication server's entity authentication of the authentication client; the authentication server also interacts with the authentication client, using the server's private key to implement an entity authentication protocol based on an asymmetric algorithm, completing the authentication client's entity authentication of the authentication server; upon successful bidirectional entity authentication, a secure communication channel is established between the authentication server and the authentication client. As shown in Figure 4, the specific method for establishing the secure communication channel is as follows:

[0134] S401. The authentication server uses its local identity private key to digitally sign the session initiation parameters, generates the first session token TokenCSP, and sends it to the authentication client.

[0135] In this embodiment, the authentication server 130 invokes its cryptographic module 132 to digitally sign the session initiation parameters using its own private key, generating a TokenCSP as information related to session initiation. This token is used to prove the true identity of the authentication server and prevent impersonation and man-in-the-middle attacks. The session initiation parameters can be a timestamp, a random number, or a sequence number, generated by the authentication server itself.

[0136] S402. After receiving the first session token TokenCSP, the authentication client verifies the first session token TokenCSP based on the pre-stored authentication server's identity public key to identify the authentication server entity.

[0137] In this system, the authentication server's private key and public key are a key pair. The authentication client verifies the first session authorization token TokenCSP based on the pre-stored authentication server's public key, primarily to verify the authenticity and integrity of the authentication server's identity. If the verification passes, the authentication server is confirmed as a trusted entity.

[0138] S403. Start the authentication server to authenticate the entity of the authentication client.

[0139] S404. The authentication client sends the locally generated client device authentication key material (DevT) to the authentication server.

[0140] S405. The authentication server uses its stored server device authentication key material DevR and the client device authentication key material DevT sent by the authentication client to derive the device authentication key DevK and save it locally. Then, it uses the device authentication key to calculate the second session token TokenAS as the response information containing the symmetric authentication key.

[0141] In this embodiment, the authentication server 130 uses DevR and DevT as inputs to execute a dynamic key derivation function to obtain the device authentication key DevK. The second session token TokenAS can be obtained from the device authentication key DevK using a symmetric entity authentication algorithm based on Message Authentication Code (MAC) or Authentication Encryption (AEAD). The algorithm includes, but is not limited to, one or more combinations of SM4-GCM, SM4-CBC combined with HMAC, AES-GCM, or AES-CBC combined with HMAC. Message authentication uses HMAC-SM3, HMAC-SHA-256, or an equal-strength algorithm.

[0142] S406. The authentication server sends the generated second session token TokenAS to the authentication client.

[0143] S407. The authentication client parses the second session token TokenAS and extracts the device authentication key DevK. When the extracted device authentication key DevK is consistent with the local device authentication key DevK, the verification is deemed successful, and the third session token TokenApp is calculated based on the locally stored device authentication key DevK.

[0144] In this embodiment, the third session token TokenApp can be obtained by applying a symmetric entity authentication algorithm based on Message Authentication Code (MAC) or Authentication Encryption (AEAD) to the device authentication key DevK. This algorithm includes, but is not limited to, one or more combinations of SM4-GCM, SM4-CBC combined with HMAC, AES-GCM, or AES-CBC combined with HMAC. Message authentication uses HMAC-SM3, HMAC-SHA-256, or an equal-strength algorithm. TokenApp embodies the client's actual ownership of DevK and is used to complete the server's verification of the client.

[0145] S408, the authentication client sends the third session token TokenApp to the authentication server.

[0146] S409. The authentication server parses the received third-party session token TokenApp and extracts the device authentication key DevK. If the extracted device authentication key DevK matches the local device authentication key DevK, the verification is considered successful. If the verification is successful, the two-way entity authentication process is completed.

[0147] S410. When both the authentication client and the authentication server successfully verify the authentication, the authentication client and the authentication server generate a session key through a key negotiation algorithm and establish a secure communication channel based on the session key.

[0148] In this embodiment, the secure communication channel may use TLS 1.3 two-way certificate authentication, a two-way authentication protocol that complies with the national commercial cryptography system, or an encrypted communication protocol of equivalent strength as a bearer to encrypt and protect the integrity of subsequent interactive data.

[0149] In this embodiment, the authentication server opens its hardware cryptographic resources (including a hardware random number generation module, a secure storage module, and a cryptographic operation module) to the authentication client through the secure communication channel to support operations such as dynamic key derivation, random number generation, and entity authentication.

[0150] In one embodiment, the authentication system supports an on-demand update mechanism for device identity credentials to prevent key replay and long-term exposure risks. After the authentication client 110 and the authentication server 130 complete entity authentication based on the device authentication key DevK, the authentication server immediately triggers a key update process. The authentication server generates a new random seed and time parameters and sends them to the authentication client through a secure channel. Both parties use the new random quantity and the original key materials DevR and DevT as inputs to derive a new device authentication key DevK′. The authentication client uses the device protection key 151 in the cryptographic card 150 to encrypt and encapsulate DevK′ and replace the old key instance, while performing secure erasure (including zeroing or random overwriting) on ​​the old DevK and derived intermediate values. Through this on-demand update mechanism, the device authentication key is automatically updated and the old key is securely destroyed after each successful authentication, thereby improving the system's anti-replay capability and overall security level.

[0151] In one embodiment, all key material exchange and authentication data interaction related to account binding and login authentication are completed within a secure communication channel established between the authentication server 130 and the authentication client 110. This secure communication channel is established based on the aforementioned two-way entity authentication mechanism. At the start of the session, both parties negotiate and generate a session key, which is used to encrypt and protect the integrity of all data transmitted through the channel. During the account binding phase, the user authentication key material UserR generated by the server, UserT generated by the client, and the derived UserK are all transmitted or processed within this secure channel. During the login authentication phase, the interaction of challenge random numbers, authentication tokens, and Message Authentication Codes (MACs) is also protected by this channel.

[0152] In one embodiment, there is no direct communication path between the login gatekeeper 141 or the target information system 140 and the authentication client 110. All authentication interactions with the authentication client are relayed and controlled by the authentication server 130 through an established secure communication channel. During the login process, the login gatekeeper 141 is only responsible for intercepting the native login request from the target information system 140 and forwarding it to the authentication server 130; the authentication server determines the corresponding authentication client 110 based on the account binding relationship and initiates authentication interaction with it through the secure communication channel. After verification, the authentication server returns the authentication result to the target information system via the integrated login gatekeeper. This design logically isolates the authentication client and the target information system, effectively preventing authentication information from being forged or tampered with, and ensuring that all authentication processes are conducted in a controlled encrypted channel, thereby enhancing the overall security and controllability of the system.

[0153] In one embodiment of this application, the authentication client and the authentication server perform symmetric entity authentication based on user-level dynamic key derivation to complete the identity verification of the login account, and generate a login permission token and send it back to the target information system after successful authentication. To achieve identity authentication, the authentication server is configured to: forward authentication-related information from the integrated login gatekeeper to the authentication client that has an account binding relationship with the logged-in user account identifier through the secure communication channel; derive a symmetric authentication key for user authentication based on the received client user authentication key material and local processing results, and use the symmetric authentication key to cooperate with the authentication client to authenticate the user's identity; after successful user authentication, generate login permission information and return it to the integrated login gatekeeper; the authentication client is configured to: generate client user authentication key material and send it to the authentication server; and cooperate with the authentication server to authenticate the user's identity based on the locally stored symmetric authentication key for user authentication. As shown in Figure 5, the identity authentication steps specifically include:

[0154] S501. When the login gatekeeper of the target information system receives a user's login authentication request, it forwards the login authentication request to the authentication server.

[0155] In this embodiment, the login authentication request, as authentication-related information, may include user account identifier (e.g., AInfo = CustomerId&gqid&accountName) and session information (a random number used to uniquely authenticate this time and prevent re-attacks).

[0156] S502. The authentication server sends the login authentication request to the authentication client that is bound to the user account identifier through a pre-established secure communication channel, based on the pre-stored user account-authentication client account binding relationship.

[0157] S503. After receiving the login authentication request, the authentication client requests the user to make a login authorization decision.

[0158] In this embodiment, after receiving a login authentication request, the authentication client 110 displays login information or a target system identifier on the user authorization interface, prompting the user to confirm or reject the authentication. The authentication client only initiates the subsequent authentication process if the user explicitly authorizes it.

[0159] S504. After the user confirms the login authorization, the authentication client starts the authentication process and calls the local password module to perform key derivation and message authentication operations.

[0160] S505. Send the randomly generated client user authentication key material UserT to the authentication server through a secure communication channel.

[0161] S506. The authentication server uses the client user authentication key material UserT and the locally stored server user authentication key material UserR to derive the user authentication key UserK, and uses the user authentication key UserK to calculate the authentication token TokenS.

[0162] In this embodiment, the user authentication key UserK is obtained by taking UserR and UserT as input and executing a dynamic key derivation function. The dynamic key derivation function can be a KDF, HKDF, HMAC-KDF, or a derivation function based on SM3. The derived UserK is used only for this authentication session and is destroyed after authentication. UserK is the symmetric authentication key used for user authentication.

[0163] In this embodiment, TokenS is defined as follows:

[0164] TokenS = Heads|| AppID||AInfo||ref||F1||U1, where:

[0165] Heads =E SessK2 (UserPR)||H SessK1 (UserPR)

[0166] F1 = E UserK2 (R),

[0167] U1= S privK (F1||AppID||AInfo||ref),

[0168] Heads is the header information, ref is the random task identifier, F1 is the first encrypted information, U1 is the second encrypted information, R is a random challenge generated by the authentication server, which can be a random number, timestamp, or other contextual information to prevent replay attacks, and SessK is the session key for the current secure communication channel, used in two parts: SessK1 is used for integrity calculation, and SessK2 is used for confidentiality calculation; H SessK1 (), E SessK2 () indicates that SessK1 and SessK2 encryption are used. UserK is the current user authentication key, which is used in two parts: UserK1 is used for integrity calculations, and UserK2 is used for confidentiality calculations; E UserK2 () indicates that UserK2 encryption is used.

[0169] S507. The authentication server sends the authentication token (TokenS) to the authentication client.

[0170] S508. After receiving the authentication token, the authentication client uses the locally stored user authentication key to parse and verify the authentication token, extracts the random challenge, calculates the response token TokenU based on the random challenge R, and sends it to the authentication server.

[0171] In this embodiment, the calculation of the response token TokenU can be performed on random challenges using a symmetric entity authentication algorithm based on Message Authentication Code (MAC) or Authentication Encryption (AEAD). The algorithm includes, but is not limited to, one or more combinations of SM4-GCM, SM4-CBC combined with HMAC, AES-GCM, or AES-CBC combined with HMAC. Message authentication uses HMAC-SM3, HMAC-SHA-256, or an equal-strength algorithm.

[0172] S509. Provided that the user authorization is still valid, the authentication client will send the generated response TokenU to the authentication server to complete the two-way authentication verification.

[0173] S510. After receiving the response token, the authentication server parses and verifies the response token, extracts the random challenge R. If the extracted random challenge is consistent with the local random challenge, the authentication is deemed successful.

[0174] The key update mechanism is triggered immediately after authentication: that is, after each successful user authentication based on UserK, the system will automatically update the user authentication key to ensure that user credentials are "updated as needed" and at the same time perform secure erasure of the old key instance and related derived intermediate values.

[0175] S511. After successful authentication, the authentication server generates a login permission token and returns it to the integrated login gatekeeper.

[0176] In this embodiment, the login permission token includes at least a session identifier, a target information system identifier, a native account identifier, an expiration time, and an integrity verification field, and is protected by the authentication server using a digital signature or MAC address. After integrating the login gatekeeper to verify the permission token, the result is fed back to the target information system 140 to control login access.

[0177] In one embodiment of this application, the aforementioned login permission information may include the user authentication result of the login account of the target information system generated by the authentication server, a corresponding random identifier, and a digital signature generated for the aforementioned information using the authentication server's private key; in another embodiment of this application, the aforementioned login permission information may include the user authentication result of the login account of the target information system generated by the authentication server, a corresponding random identifier, and a message authentication code calculated using a symmetric key shared by the authentication server and the login gatekeeper, the message authentication code being generated by the authentication server and verified by the receiving gatekeeper.

[0178] In one embodiment, after authentication is complete, the authentication client performs a secure erasure of the temporary data used during the session. The erased data includes the session instance of the user authentication key UserK, derived intermediate values, challenge random numbers, and cached data. The erasure method employs a zeroing or random overwrite technique that meets security requirements to ensure that sensitive information is unrecoverable.

[0179] Through the above process, this embodiment realizes a high-security symmetric entity authentication mechanism based on user-level dynamic key derivation. Combined with user authorization triggering, instant key update and secure erasure strategies, it ensures the controllability, replay resistance and end-to-end encryption integrity of the authentication process, thereby supporting multi-factor, low-intrusion security authentication of the target information system.

[0180] In one embodiment, as shown in Figure 1, the login gatekeeper 141 is integrated into the native authentication extension point of the target information system 140 in the form of a plug-in or module, in order to intercept native account information and trigger external multi-factor authentication process during user login.

[0181] Through this integration method, the integrated login gatekeeper can seamlessly enhance the native account login process without altering the underlying login framework of the target information system.

[0182] In this embodiment, the integration methods of the login gatekeeper 141 include, but are not limited to, the following:

[0183] (1) PAM module (Pluggable Authentication Module) in Linux system environment: The login gatekeeper is deployed as a shared library that conforms to the PAM interface specification. It can be dynamically called during system login, remote access (SSH) or privileged operation (sudo). It intercepts the original account verification request through the pam_sm_authenticate() interface and forwards the authentication request to the authentication server 130.

[0184] (2) SubAuth or LSA extension in Windows system environment: The login gatekeeper registers with LocalSecurity Authority (LSA) as a DLL module, captures user login information when the system calls the LsaLogonUser() interface to perform authentication, and sends the original account identifier to the authentication server 130 through a secure channel to perform multi-factor authentication.

[0185] (3) Multi-factor authentication plugin for database systems: For databases such as MySQL, PostgreSQL or SQL Server, the integrated login gatekeeper can be implemented as a database authentication plugin. It captures the username and connection request through its native authentication hook function and sends them to the authentication server as external authentication input parameters.

[0186] (4) Login plugin for Web target information system: The integrated login gatekeeper can be embedded in the authentication extension point of the Web server (such as Nginx, Apache) or application framework. When the / login / auth request is detected, the user credentials are intercepted and the native account information is transferred to the authentication server 130 to initiate authentication.

[0187] In another embodiment, when the login gatekeeper 141 obtains the native account information in the login process of the target information system, it can also simultaneously collect context information related to the login attempt and forward it to the authentication server 130.

[0188] The context information includes at least one or more of the following:

[0189] Client source address (e.g., IP address or device identifier);

[0190] Login entry identifier (e.g., login page, access interface, or terminal type);

[0191] A timestamp is used to uniquely represent the time of a login operation.

[0192] Session identifiers are used to distinguish different login sessions.

[0193] The authentication server can use this contextual information to perform anomaly detection, geolocation comparison, or risk assessment, thereby enhancing the security and audit traceability of the authentication process.

[0194] In another embodiment, after receiving the login permission token returned by the authentication server, the login gatekeeper 141 will perform a strict verification of the token. The verification steps include at least:

[0195] Verify signature or message authentication code (MAC): Login gatekeeper 141 uses the authentication server's public key or shared key to verify the token's signature or MAC field to ensure the token has not been tampered with.

[0196] The login gatekeeper verifies the token's validity period by parsing the expiration time field in the token. If the token has expired, the login request is rejected.

[0197] Verify account consistency: The login gatekeeper 141 compares the original account identifier contained in the token with the account in the current login request to prevent token replay or cross-account abuse.

[0198] If any verification step fails, or if the authentication result is not received from the authentication server within the specified time, the login gatekeeper 141 will reject the login request by default.

[0199] Through the above design, Login Guard 141 provides end-to-end security control capabilities, from login interception and context auditing to token verification, while ensuring low-intrusion system integration.

[0200] This embodiment ensures trusted relay and integrity protection of authentication requests within the boundary of the target information system, further improving the login security and protection strength of the target information system.

[0201] In one embodiment of this application, the authentication server 130 possesses a robust audit record and log protection mechanism to meet security traceability and compliance requirements. During each account binding, identity authentication, and secure channel establishment process, the authentication server 130 automatically generates audit logs. The log content includes at least: the target information system identifier, the native account identifier, the authentication client identifier (DeviceID or ClientID), a timestamp, a session identifier, and the authentication result. To prevent log tampering or forgery, the authentication server protects the log integrity using Message Authentication Code (MAC) or digital signatures, and can periodically archive or write the logs to tamper-proof storage media. This mechanism ensures end-to-end traceability of authentication activities and provides reliable data support for system security auditing, risk analysis, and compliance verification.

[0202] In one embodiment of this application, the identity authentication system, through an adaptive authentication integration mechanism, can interface with various types of target information systems, such as web target information systems, databases, Linux operating systems, and Windows operating systems, to achieve cross-platform, unified multi-factor authentication. The system's integrated login gatekeeper module can be adapted based on the native authentication extension interfaces of different target information systems: for example, it can be integrated as a PAM module in a Linux environment; as a SubAuth or LSA extension in a Windows environment; as a multi-factor authentication plugin in a database system; and as a login plugin or reverse proxy module in a web application. Through this mechanism, the system achieves consistent authentication logic and unified security policies across multiple platforms without changing the underlying login framework of the target information system.

[0203] In another embodiment of this application, the identity authentication system can also work in conjunction with an organization's unified identity management system or directory service (such as LDAP, Active Directory, etc.). When interacting with the directory service, the authentication server generates one-time verification credentials through a dynamic key derivation mechanism, which are used to strengthen authentication and access control of user identities in the directory, thereby extending the security advantages of dynamic key derivation to a centralized identity management environment. This design enables the system to be deployed independently on heterogeneous target information systems, while also seamlessly integrating with existing enterprise identity management infrastructure, achieving a unified security authentication and access control system across platforms and domains.

[0204] Based on the above technical solutions, this application has the following advantages:

[0205] (1) The authentication link is completely closed within the encrypted domain: all credentials, key operations and authentication requests are transmitted only in the secure channel between the authentication client and the authentication server, and the target information system does not process any keys or user credentials.

[0206] (2) Implement device identity authentication: Protect DevK on the authentication client through a cryptographic card, and complete device trusted verification based on DevK.

[0207] (3) No server-side long-term key retention, supporting dynamic key derivation and freshness guarantee: Key materials are generated instantly during the authentication process and expire after use. The server does not need to store user authentication keys or device authentication keys. The cryptographic card provides the authentication client with a device protection key for storing DevK. Based on DevK, device trusted verification is completed. Then, a secure communication channel is established between the authentication server and the authentication client. Based on the secure communication channel, a user protection key is provided to the authentication client for storing UserK on the authentication client. Throughout the process, the authentication server does not store DevK and UserK.

[0208] (4) The soft computing environment has hardware-level security capabilities: the authentication server can import hardware cryptographic resources into the authentication client, enabling it to have capabilities such as random number generation, symmetric encryption, and key protection, and resist memory attacks and image restoration.

[0209] (5) Zero modification to the target system and seamless cross-platform access: The integrated gatekeeper can be installed simply by using its native login extension point. No adjustment to the original system code is required. It can be adapted to various types of systems such as web applications, databases, Linux, and Windows.

[0210] 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 including a computer-readable medium carrying computer-usable instructions for one or more processors. The medium can be provided in various forms, including non-transitory forms such as, but not limited to, one or more disks, optical disks, magnetic tapes, chips, and magnetic and electronic storage.

[0211] 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, that is, a copy of the program in computer memory ready to be executed by the computer's central processing unit (CPU). This application refers to the processor of a computer system and the operations performed by the processor of a computer system. It should be understood that such reference includes 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.

[0212] It should be understood that the embodiments and descriptions above are only the principles, main features and advantages of the present invention. Various changes and modifications can be made to the present invention without departing from the spirit and scope of the invention, and all such changes and modifications fall within the protection scope of the present invention.

Claims

1. A seamless integrated identity authentication system based on a symmetric key dynamic derivation mechanism, characterized in that, include: A password card server is used to provide password cards to users. The password cards contain trusted initialization information to support the secure operation and key processing of authentication clients, and help authentication clients register and bind with one or more authentication servers. An authentication client is used to work with the authentication server to derive at least one symmetric authentication key based on the trusted initialization information in the cryptographic card, and to cooperate with the authentication server to perform entity identity authentication of the user account identifier belonging to the user logging into the target information system based on the symmetric authentication key. The authentication server is used to work with the authentication client to derive the symmetric authentication key; and based on the symmetric authentication key, work with the authentication client to complete the entity identity authentication of the user account to which the login target information system belongs; and output the entity identity authentication result obtained from the interaction with the authentication client to the integrated login gatekeeper; An integrated login gatekeeper is seamlessly integrated into the target information system as a plug-in or module. It is used to obtain the user account identifier during the login process of the target information system and relay the authentication-related information associated with the user account identifier to the authentication server. It receives the entity identity authentication result from the authentication server; and transmits the entity identity authentication result to the target information system; The authentication client establishes a secure communication channel with the authentication server, and performs at least the following functions based on this secure communication channel: The authentication server provides cryptographic computation service resources to the authentication client through the secure communication channel, enabling the authentication client to perform key processing-related operations using the secure cryptographic capabilities of the authentication server. The authentication server forwards authentication-related information from the integrated login gatekeeper to the authentication client through the secure communication channel, enabling the target information system to complete the user identity authentication process without directly communicating with the authentication client.

2. The seamless integrated identity authentication system based on symmetric key dynamic derivation mechanism according to claim 1, characterized in that: The authentication client is configured as follows: After receiving the cipher card from the cipher card server, perform initialization processing to start the authentication client; Based on the trusted initialization information in the cryptographic card, a local symmetric authentication key and encryption parameters for encrypting the symmetric authentication key are generated. The symmetric authentication key is stored locally for protective purposes based on the encryption parameters. The password image card server is configured as follows: Based on the initialization request from the authentication client, generate a cryptographic card containing trusted initialization information and provide it to the authentication client; The server-side symmetric authentication key material associated with the authentication client is encrypted and forwarded to the authentication server, thereby enabling the authentication client to register and bind with one or more authentication servers.

3. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that: The authentication client is configured as follows: When a user account is associated with an authentication client, an account binding request containing the authentication client identifier and the user account identifier is sent to the authentication server. After receiving the data related to account binding returned by the authentication server, perform account binding related processing; Based on the trusted initialization information in the password card, the processing results related to account binding are stored protectively. The authentication server is configured as follows: Generate account binding-related data based on the account binding request and return it to the authentication client; Establish and record the account binding relationship between user account identifiers and authentication client identifiers.

4. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that: The authentication server and authentication client are configured as follows: The authentication server interacts with the authentication client, using a symmetric authentication key to implement an entity authentication protocol based on a symmetric algorithm, thus completing the entity authentication of the authentication client by the authentication server. The authentication server interacts with the authentication client, using the server's private key to implement an entity authentication protocol based on an asymmetric algorithm, thus completing the authentication client's entity authentication of the authentication server. When two-way entity authentication is successful, a secure communication channel is established between the authentication server and the authentication client.

5. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that: The authentication server is configured as follows: The authentication-related information from the integrated login gatekeeper is forwarded to the authentication client that has an account binding relationship with the logged-in user account identifier through the secure communication channel; Based on the received client symmetric authentication key material and the locally stored server symmetric authentication key material, a symmetric authentication key for user authentication is derived, and the derived symmetric authentication key is used in conjunction with the authentication client to authenticate the user's identity. After the user's identity is successfully authenticated, login permission information is generated and returned to the integrated login gatekeeper; The authentication client is configured as follows: Generate client-side symmetric authentication key material and send it to the authentication server; Based on the symmetric authentication key stored locally for user authentication, the system collaborates with the authentication server to authenticate the user's identity.

6. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that, The symmetric authentication key is derived by introducing context parameters, which include at least one or more of the following: a unique identifier for the cryptographic card, an authentication client identifier, a timestamp, or a random number.

7. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 2, characterized in that, The authentication client is configured to register and bind with one or more authentication servers. When registering and binding, the authentication server submits its public key to the cipher card server. The cipher card server uses the public key to encrypt and send the server-side symmetric authentication key material corresponding to the authentication client to the authentication server, thereby realizing the registration and binding between the authentication client and the authentication server.

8. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that, After authentication is completed, the authentication client performs a secure erase of the temporary data used during the session.

9. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that, The cryptographic card carries additional information to assist the authentication client in performing local protective processing. When the authentication client verifies the trustworthiness of the cryptographic card, it performs protective processing on the client's local data related to the symmetric authentication key based on the additional information.

10. The seamless integrated identity authentication system based on the symmetric key dynamic derivation mechanism according to claim 1, characterized in that: The authentication client cryptographic module receives information from the cryptographic card through peripheral interaction, and, after verifying the trustworthiness of the cryptographic card, uses the trusted initialization information in the cryptographic card to construct a protective area for storing authentication-related data.

11. The seamless integrated identity authentication system based on a symmetric key dynamic derivation mechanism according to claim 5, characterized in that, After receiving the login permission information sent by the authentication server, the integrated login gatekeeper shall at least verify the consistency between the signature or MAC, the expiration time and the user account identifier. If the verification fails or the timeout does not return, the login request shall be rejected by default.

12. The seamless integrated identity authentication system based on a symmetric key dynamic derivation mechanism according to claim 1, characterized in that, Each time the authentication server successfully authenticates an entity based on the symmetric authentication key, it immediately updates the symmetric authentication key and securely erases the old symmetric authentication key.

13. A seamless integrated identity authentication method based on a symmetric key dynamic derivation mechanism, characterized in that, The method includes: The integrated login gatekeeper obtains the user account identifier during the login process of the target information system and relays the authentication-related information associated with the user account identifier to the authentication server; wherein, the integrated login gatekeeper is seamlessly integrated into the target information system in the form of a plug-in or module; The authentication server, based on a symmetric authentication key, collaborates with the authentication client to authenticate the entity identity of the user account to which the login target information system belongs. The symmetric authentication key is derived from trusted initialization information in a cryptographic card and is obtained collaboratively with the authentication client. The cryptographic card is provided to the user by the cryptographic card server and contains trusted initialization information to support the secure operation and key processing of the authentication client. The authentication server outputs the entity identity verification result obtained from the interaction with the authentication client to the integrated login gatekeeper; The integrated login gatekeeper receives the entity identity authentication result from the authentication server and transmits the entity identity authentication result to the target information system; The authentication client and the authentication server establish a secure communication channel, and at least the following functions are implemented based on this secure communication channel: The authentication server provides cryptographic computation service resources to the authentication client through the secure communication channel, enabling the authentication client to perform key processing-related operations using the secure cryptographic capabilities of the authentication server. The authentication server forwards authentication-related information from the integrated login gatekeeper to the authentication client through the secure communication channel, enabling the target information system to complete the user identity authentication process without directly communicating with the authentication client.

Images