Dynamic token authentication method and device, and computer readable storage medium

Abstract

The application relates to the technical field of network identity authentication, and specifically provides a dynamic token authentication method, device and computer readable storage medium, the dynamic token authentication method comprising the following steps: generating a first temporary key pair; obtaining a target user identity identifier; obtaining first signature data corresponding to the first temporary public key, and sending the first temporary public key, the first signature data and the target user identity identifier to a second device; determining a session key based on the first temporary private key and a second temporary public key; constructing key binding data based on the first temporary public key and the second temporary public key; performing second collaborative signature interaction with the second device based on the first private key component to obtain second signature data; performing a cryptography operation on a to-be-authenticated message based on the session key to generate request authentication data; and sending a service request to the second device, wherein the service request carries a current time parameter and the request authentication data. The application realizes anti-leakage and anti-attack through a distributed private key.

Description

Technical Field

[0001] This invention relates to the technical field of network identity authentication, and more specifically, to a dynamic token authentication method, apparatus, and computer-readable storage medium. Background Technology

[0002] In related technologies, stateless Web authentication often adopts the JSON Web Token (JWT) architecture. However, the issuance and verification keys under this architecture are usually centrally stored and managed by the authentication server, which poses a certain risk of single point of failure. Therefore, once the authentication server is compromised and the keys are leaked, a third party can arbitrarily generate a large number of legitimate tokens for users, thereby posing a fundamental threat to the network identity security of the entire system. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] Therefore, the first aspect of the present invention proposes a dynamic token authentication method.

[0005] A second aspect of the present invention provides a dynamic token authentication method.

[0006] A third aspect of the present invention provides a dynamic token authentication device.

[0007] A fourth aspect of the present invention provides a dynamic token authentication device.

[0008] The fifth aspect of this application proposes a computer-readable storage medium.

[0009] In view of this, a first aspect of the present invention provides a dynamic token authentication method applied to a first device, the first device storing a first private key component corresponding to a target user's identity, the dynamic token authentication method comprising: upon detecting a session establishment request between the first device and a second device, generating a first temporary key pair, the first temporary key pair including a first temporary public key and a first temporary private key; obtaining a target user's identity identifier; performing a first collaborative signature interaction with the second device based on the first private key component to obtain first signature data for the first temporary public key, and sending the first temporary public key, the first signature data, and the target user's identity identifier to the second device; and receiving a response from the second device. The system retrieves a second temporary public key and determines a session key based on the first temporary private key and the second temporary public key; constructs key binding data based on the first temporary public key and the second temporary public key; performs a second collaborative signature interaction with the second device on the key binding data based on the first private key component to obtain second signature data, and sends the second signature data to the second device to activate the communication session; obtains the current time parameter and request content data, and performs cryptographic operations on the message to be authenticated containing the request content data and the current time parameter based on the session key to generate request authentication data; and sends a service request to the second device, which carries the current time parameter and request authentication data.

[0010] This application provides a dynamic token authentication method applied to a first device. The first device stores a first private key component corresponding to the target user's identity. By splitting the user's long-term identity private key into independent components held separately by the first device, the complete private key cannot be synthesized from a single private key component, thus avoiding the risk of leakage due to a single device storing the complete key. This application proposes a distributed trust scheme. Upon detecting a session establishment request between the first and second devices, a first temporary key pair is generated. The first temporary key pair includes a first temporary public key and a first temporary private key. By generating exclusive temporary key material for each session, the long-term key is prevented from being exposed during key negotiation, thereby ensuring the forward security of the session key. Even if the key of one session is leaked, it will not affect the security of other sessions. Based on the obtained target user identity identifier, information uniquely identifying the user's identity is read from the first device's local secure storage area, providing a data foundation for subsequently clarifying the identity of the user to be authenticated to the second device, ensuring that the second device can accurately locate the corresponding cryptographic material. Based on the first private key component, a first collaborative signature interaction is performed with the second device to obtain first signature data for the first temporary public key. The first temporary public key, the first signature data, and the target user's identity identifier are sent to the second device. The signature operation is completed collaboratively using the private key components held by both devices, cryptographically binding the first temporary public key with the target user's long-term identity to generate a tamper-proof identity assertion. This allows the second device to verify the legitimate ownership of the temporary public key, initially preventing man-in-the-middle attacks. Based on the second temporary public key returned by the second device, a session key is determined based on the first and second temporary private keys. Key negotiation is conducted using the temporary key materials of both parties to generate a one-time session key valid only in the current session. This ensures the confidentiality and independence of session communication, avoids cross-session security risks caused by key reuse, and improves interaction security. Based on the first and second temporary public keys, key binding data is constructed. By integrating the temporary identity information of both parties, a unique identifier is generated, providing a core basis for subsequent verification of key negotiation consistency and ensuring that both parties have a consistent understanding of the temporary key. Based on the first private key component, a second collaborative signature interaction is performed with the second device for the key binding data to obtain the second signature data, and the second signature data is sent to the second device to activate the communication session. The key negotiation result is confirmed a second time through the second collaborative signature, and the user's long-term identity and temporary session are double-cryptographically bound, thereby blocking the attack path of man-in-the-middle tampering with session information to a certain extent and ensuring the security of session activation.Based on the obtained current time parameter and request content data, cryptographic operations are performed on the message to be authenticated, which contains the request content data and the current time parameter, using the session key to generate authentication request data. By strongly binding the core content of the business request with the time dimension, authentication information uniquely corresponding to a single request is generated, eliminating the need for a static token with a fixed validity period and preventing the illegal reuse of authentication information after eavesdropping. The business request, carrying the current time parameter and authentication request data, is sent to the second device. A client-side dynamic issuance of authentication credentials model is adopted, eliminating the need for centralized token management on the second device, thus reducing server-side security pressure. This model is also compatible with various stateless authentication scenarios such as web applications and mobile internet services.

[0011] In some embodiments of this application, the first device stores a first private key component corresponding to the target user's identity, including: in response to an identity recovery request for the target user's identity, downloading the encrypted first private key component and a random salt value, wherein both the encrypted first private key component and the random salt value correspond to the target user's identity; performing key derivation based on the obtained password data and the random salt value to obtain a decryption key; decrypting the encrypted first private key component based on the decryption key, and writing the obtained decrypted first private key component into the random access memory of the first device.

[0012] In the above embodiments, the first device stores a first private key component corresponding to the target user's identity. This includes downloading the encrypted first private key component and a random salt value in response to an identity recovery request for the target user's identity. Both the encrypted first private key component and the random salt value correspond to the target user's identity. By transmitting and storing the first private key component in ciphertext, plaintext leakage during transmission is avoided. Simultaneously, the random salt value is introduced as a random factor in key derivation, reducing the probability of being cracked and preventing external decryption attacks, thus ensuring the security of the encrypted material. Based on the obtained password data and the random salt value, a key derivation is performed to obtain a decryption key. The user-input password is converted into a decryption key using a password-based key derivation function, preventing direct password exposure and thus achieving a secure association between the user's identity and the private key component. Only legitimate users with the correct password can generate a valid decryption key. The encrypted first private key component is decrypted based on the decryption key, and the decrypted first private key component is written into the random access memory of the first device. By completing the decryption and temporary storage in volatile memory, the decrypted private key component only exists when the device is running and is automatically cleared when the device is powered off or the process ends. It will not be written to persistent storage media in plaintext, thus preventing the leakage of private key components on the device. At the same time, no dedicated hardware security module is required. Multi-device identity security recovery is achieved by relying on pure software, removing the restriction of identity binding to physical device, and adapting to the user's multi-terminal usage needs.

[0013] In some embodiments of this application, constructing key binding data based on a first temporary public key and a second temporary public key includes: concatenating the first temporary public key and the second temporary public key into bytes, and performing a cryptographic hash operation on the concatenation result to obtain key binding data.

[0014] In the above embodiments, key binding data is constructed based on the first temporary public key and the second temporary public key. This includes concatenating the first temporary public key and the second temporary public key into bytes, and performing a cryptographic hash operation on the concatenated result to obtain the key binding data. The temporary public key information of both communicating parties is integrated through the byte concatenation operation to ensure that the binding data is associated with the temporary identities of both parties. Then, by utilizing the irreversible and collision-resistant properties of the cryptographic hash function, the concatenated result of any length is converted into a unique hash value of fixed length. Any slight change to the original data will result in a completely different hash result, thereby preventing the binding data from being tampered with. This provides a trusted object to be signed for the subsequent second collaborative signature, ensuring that the second device can accurately verify that the key negotiation process has not been tampered with by a man-in-the-middle, and supporting the secure activation of the session.

[0015] In some embodiments of this application, the request content data in the message to be authenticated includes: the Hypertext Transfer Protocol Request Method and the Request Uniform Resource Identifier of the current business request; the Hypertext Transfer Protocol Request Method, the Uniform Resource Identifier and the current time parameter are concatenated in a preset order and adjacent fields are separated by a preset delimiter to determine the message to be authenticated.

[0016] In the above embodiments, the request content data in the message to be authenticated includes the Hypertext Transfer Protocol (HTTP) request method of the current business request and the Request Uniform Resource Identifier (URLI). By using the HTTP request method, which identifies the request operation type, and the URLI, which identifies the request resource path, as the core components of the request content data, the core content of the business request is uniquely determined, directly associating the authentication information with the specific business request. Based on the HTTP request method, the URLI, and the current time parameter, the fields are concatenated in a preset order, with adjacent fields separated by a preset delimiter, to determine the message to be authenticated. By fixing the field concatenation order and delimiters, it is ensured that the logic of constructing the message to be authenticated by the first device and the second device is completely consistent, avoiding authentication failure due to format differences. Simultaneously, the message to be authenticated is associated with the request operation, the target resource, and the time dimension, thereby ensuring that the generated request authentication data corresponds only to the specific request at that time, preventing authentication information from being misappropriated to other requests, and improving the accuracy and security of authentication.

[0017] In some embodiments of this application, the first and second collaborative signature interactions adopt the national cryptographic SM2 collaborative signature algorithm; the key derivation adopts the PBKDF2 key derivation function based on SM3, and the cryptographic operation adopts the hash message authentication code algorithm based on SM3; the encryption and decryption of the encrypted first private key component both adopt the national cryptographic SM4 symmetric encryption algorithm.

[0018] In the above embodiments, the first and second collaborative signature interactions employ the SM2 collaborative signature algorithm, a national cryptographic standard. Leveraging the high security and threshold signature characteristics of the SM2 elliptic curve cryptography algorithm, the first and second devices collaboratively complete digital signatures without exposing their respective private key components. This adapts to the signature requirements of a distributed private key architecture and ensures the security of the signature process. Key derivation utilizes the PBKDF2 (Password-Based Key Derivation Function 2) key derivation function based on SM3, using the SM3 hash algorithm as a pseudo-random function. Through multiple iterative operations, the user password and random salt value are transformed into a high-strength decryption key, thereby enhancing the security strength of the password-derived key and effectively resisting forced cracking attacks. Cryptographic operations employ the SM3-based hash message authentication code algorithm, combining the session key and the message to be authenticated to generate a tamper-proof message authentication code. This simultaneously verifies the integrity of the requested data and authenticates the source identity, ensuring that the business request has not been tampered with and originates from a legitimate user. The encryption and decryption of the first private key component both employ the national standard SM4 symmetric encryption algorithm. Leveraging the high encryption efficiency and strong anti-attack capabilities of the SM4 block cipher algorithm, the confidentiality of the first private key component is ensured during storage and transmission. The entire process uses national standard algorithms SM2, SM3, and SM4, thus complying with relevant information security regulations, achieving independent control over the cryptographic algorithms, and resolving compliance risks and backdoor vulnerabilities associated with non-national standard algorithms.

[0019] A second aspect of this application provides a dynamic token authentication method applied to a second device. The second device stores multiple second private key components corresponding to each user and a unified public key. The dynamic token authentication method includes: receiving a first temporary public key, first signature data, and a target user identity identifier sent by a first device; determining a target user based on the target user identity identifier; obtaining a target unified public key corresponding to the target user's identity from the stored unified public keys corresponding to multiple users; verifying the first signature data based on the target unified public key; generating a second temporary key pair upon successful verification and returning the second temporary public key from the second temporary key pair to the first device; constructing local key binding data based on the first temporary public key and the second temporary public key; receiving the second signature data sent by the first device and, based on the target unified public key... The public key verifies whether the second signature data is a valid signature for the data bound to the local key. If the verification is successful, a session key is determined based on the second temporary private key and the first temporary public key in the second temporary key pair, and the communication session is activated. Activation includes associating and storing the session key with the target user's identity and the initial timestamp. A service request sent by the first device is received, which carries a current time parameter and a request for authentication data. The current time parameter is validated for timeliness. If the validation is successful, a local message to be authenticated is constructed based on the content of the service request. Cryptographic operations are performed on the local message to be authenticated based on the activated session key to generate local message authentication data. The local message authentication data is compared with the request authentication data. If the local message authentication data matches the request authentication data, identity authentication is passed and the service request is processed.

[0020] This application proposes a dynamic token authentication method applied to a second device. The second device stores multiple users' respective second private key components and a unified public key. By storing another portion of the user's long-term identity private key separately on the second device, which does not hold the complete private key and cannot independently generate a valid digital signature, the risk of single-point failure due to centralized key storage on the authentication server and subsequent mass misuse of tokens by third parties is reduced. Simultaneously, the unified public key is bound to the user's identity for storage, providing a unified and legitimate credential for signature verification. Based on the first temporary public key, first signature data, and target user identity identifier sent by the first device, the method obtains the identity assertion materials and user identity information submitted by the client, providing input data for subsequent identity verification and key negotiation. The method identifies the target user based on the target user identity identifier, accurately locking the user to be authenticated in a multi-user environment, ensuring that the subsequently obtained cryptographic materials accurately correspond to the user, and avoiding authentication errors caused by user identity confusion. Finally, the method obtains the target unified public key corresponding to the target user's identity from the stored unified public keys corresponding to multiple users, extracting the user's unique public key to provide the correct key basis for verifying the first signature data. Based on the verification of the first signature data using the target unified public key, the legitimacy of the signature is asserted by verifying the identity, confirming the binding relationship between the first temporary public key and the target user's long-term identity, thereby filtering illegal requests and blocking third-party attacks in the early stages of session establishment. Upon successful verification, a second temporary key pair is generated and the second temporary public key from the second temporary key pair is returned to the first device. By generating server-side temporary key materials, a two-way temporary key system is constructed, ensuring that the session key is composed of randomness contributed by both parties, thus improving the security of key negotiation. Based on the first and second temporary public keys, local key binding data is constructed. By constructing the binding data in the same way as the first device, both parties' understanding of the key negotiation result is consistent, providing a benchmark for the verification of the second signature data. Based on the second signature data received from the first device, the second signature data is verified as a valid signature for the local key binding data using the target unified public key. By verifying the legitimacy of the session binding signature, it is confirmed that the key negotiation process has not been tampered with by a man-in-the-middle, thus completing dual signature verification and mitigating man-in-the-middle attacks to a certain extent. Upon successful verification, a session key is determined based on the second temporary private key and the first temporary public key in the second temporary key pair, and the communication session is activated. Activation includes associating and storing the session key with the target user's identity and initial timestamp, generating a session key that is completely identical to the first device, and establishing a session state containing the user's identity and initial timestamp. This provides a state basis for the verification of subsequent business requests and enables session management under stateless communication.Upon receiving a business request from the first device, which carries a current time parameter and authentication request data, the verification process for the business request is initiated by acquiring authentication information dynamically generated by the client. The current time parameter is validated for timeliness. If the validation passes, a local message to be authenticated is constructed based on the content of the business request. This involves first verifying the time validity of the request, filtering out expired and replayed requests, and then constructing a message identical to the one from the first device, thus providing a consistent basis for authentication data comparison. Cryptographic operations are performed on the local message to be authenticated based on the activated session key to generate local message authentication data. Authentication data is independently calculated using the session key stored on the server, enabling server-side self-verification without relying on tokens sent by the client. The local message authentication data is compared with the request authentication data. If they match, authentication is performed, and the business request is processed. Cryptographic comparison confirms the integrity and authenticity of the request's source. Only legitimate users with the correct session key can generate matching authentication data, thus achieving independent authentication for each business request and improving the security of interaction and data transmission.

[0021] In some embodiments of this application, the timeliness of the current time parameter is verified, including: verifying whether the current time parameter is within a preset valid time window; and verifying whether the current time parameter is greater than the latest historical timestamp stored in the second device for the current communication session; and updating the latest historical timestamp to the current time parameter when both verifications pass.

[0022] In the above embodiments, the current time parameter is validated for timeliness, including checking whether the current time parameter is within a preset valid time window. By setting a reasonable time range, expired requests exceeding the server's allowed time deviation and premature requests from the future are filtered out, thus forming the first line of defense against replay attacks. Based on whether the current time parameter is greater than the latest historical timestamp stored in the second device for the current communication session, by requiring request timestamps to strictly increment, requests within the same session are ensured to be submitted in chronological order, thereby preventing replay attacks on valid authentication information within the valid time window. Even if an attacker intercepts authentication information that has not yet expired, they cannot successfully replay it. When both validations pass, the latest historical timestamp is updated to the current time parameter. By dynamically maintaining the latest timestamp state of the session, the validation benchmark for subsequent requests is continuously advanced, thus forming a continuous time-series protection chain and ensuring the continuous effectiveness of the timeliness validation mechanism. The dual time validation mechanisms work together to ensure the freshness of requests from both absolute timeliness and relative sequence dimensions, thereby completely preventing the replay use of authentication information.

[0023] A third aspect of this application provides a dynamic token authentication device applied to a first device. The first device stores a first private key component corresponding to the identity of a target user. The dynamic token authentication device includes: a first detection module, a first acquisition module, a second acquisition module, a first determination module, a first construction module, a third acquisition module, a fourth acquisition module, and a first interaction module. The first detection module generates a first temporary key pair, including a first temporary public key and a first temporary private key, upon detecting a session establishment request between the first device and the second device. The first acquisition module acquires the target user's identity identifier. The second acquisition module performs a first collaborative signature interaction with the second device based on the first private key component to obtain first signature data for the first temporary public key, and sends the first temporary public key, first signature data, and target user identity identifier to the second device. The first determination module receives the second temporary public key returned by the second device and determines the session key based on the first temporary private key and the second temporary public key. The first construction module constructs key binding data based on the first temporary public key and the second temporary public key. The third acquisition module performs a second collaborative signature interaction with the second device based on the first private key component to obtain second signature data for the key binding data, and sends the second signature data to the second device to activate the communication session. The fourth acquisition module acquires the current time parameter and request content data, performs cryptographic operations on the message to be authenticated containing the request content data and the current time parameter based on the session key, and generates request authentication data. The first interaction module sends a service request to the second device, carrying the current time parameter and request authentication data.

[0024] This application provides a dynamic token authentication device for a second device. The second device stores multiple users' respective second private key components and a unified public key. The dynamic token authentication device includes: a first receiving module, a second determining module, a fifth obtaining module, a second interaction module, a third interaction module, a fourth interaction module, a fifth interaction module, a first verification module, a second receiving module, a first verification module, a first activation module, and a first comparison module. The first receiving module receives a first temporary public key, first signature data, and a target user identity identifier sent by the first device. The second determining module determines a target user based on the target user identity identifier. The fifth obtaining module obtains a target unified public key corresponding to the target user's identity from the stored multiple users' respective unified public keys. The second interaction module verifies the first signature data based on the target unified public key. The third interaction module generates a second temporary key pair upon successful verification and returns the second temporary public key from the second temporary key pair to the first device. The fourth interaction module verifies the first signature data based on the first temporary public key. The public key and the second temporary public key construct local key binding data; the fifth interaction module is used to receive the second signature data sent by the first device, and verify whether the second signature data is a valid signature for the local key binding data based on the target unified public key; the first verification module is used to determine the session key based on the second temporary private key and the first temporary public key in the second temporary key pair when the verification is successful, and activate the communication session, which includes associating and storing the session key with the target user's identity and the initial timestamp; the second receiving module is used to receive the service request sent by the first device, which carries the current time parameter and the request authentication data; the first verification module is used to perform timeliness verification on the current time parameter, and when the verification is successful, construct a local message to be authenticated based on the content of the service request; the first activation module is used to perform cryptographic operations on the local message to be authenticated based on the activated session key to generate local message authentication data; the first comparison module is used to compare the local message authentication data with the request authentication data, and when the local message authentication data and the request authentication data are consistent, the identity authentication is passed and the service request is processed.

[0025] A fifth aspect of this application provides a dynamic token authentication device applied to a first device. The dynamic token authentication device includes: a first memory for storing a first private key component corresponding to a target user's identity and a computer program; and a first processor for executing the computer program to implement the steps of any of the dynamic token authentication methods described in the above embodiments. Therefore, the dynamic token authentication device possesses all the beneficial effects of the dynamic token authentication method.

[0026] A sixth aspect of this application provides a dynamic token authentication device applied to a second device. The dynamic token authentication device includes: a second memory for storing second private key components corresponding to multiple users, a unified public key, and a computer program; and a second processor for executing the computer program to implement the steps of the dynamic token authentication method as described in the above embodiments. Therefore, the dynamic token authentication device possesses all the beneficial effects of the dynamic token authentication method.

[0027] A seventh aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the dynamic token authentication methods described above. Therefore, the computer-readable storage medium possesses all the beneficial effects of the dynamic token authentication method.

[0028] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0029] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is one of the flowcharts illustrating a dynamic token authentication method according to an embodiment of the present invention; Figure 2 This is a second schematic flowchart of a dynamic token authentication method according to an embodiment of the present invention; Figure 3 This is one of the schematic block diagrams of a dynamic token authentication device according to an embodiment of the present invention; Figure 4 This is a second schematic block diagram of a dynamic token authentication device according to an embodiment of the present invention; Figure 5 This is a schematic block diagram of a dynamic token authentication device according to an embodiment of the present invention; Figure 6 This is a schematic block diagram of a dynamic token authentication device according to an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the workflow of initial user registration and distributed private key generation according to an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating the workflow of a first device responding to an identity recovery request and obtaining a first private key component according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the timing process for dynamic session key negotiation between a first device and a second device according to an embodiment of the present invention; Figure 10This is a schematic diagram illustrating the process of a first device dynamically issuing authentication request data and a second device verifying it, according to an embodiment of the present invention. Detailed Implementation

[0030] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0031] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0032] The following reference Figures 1 to 10 This invention describes a dynamic token authentication method, apparatus, and computer-readable storage medium according to some embodiments of the present invention.

[0033] like Figure 1 As shown, an embodiment of this application provides a dynamic token authentication method applied to a first device. The first device stores a first private key component corresponding to the identity of a target user. The dynamic token authentication method includes: Step 102: When a session establishment request between the first device and the second device is detected, a first temporary key pair is generated, which includes a first temporary public key and a first temporary private key. Step 104: Obtain the target user's identity identifier; Step 106: Perform a first collaborative signature interaction with the second device based on the first private key component to obtain the first signature data for the first temporary public key, and send the first temporary public key, the first signature data and the target user identity identifier to the second device; Step 108: Receive the second temporary public key returned by the second device, and determine the session key based on the first temporary private key and the second temporary public key; Step 110: Construct key binding data based on the first temporary public key and the second temporary public key; Step 112: Based on the first private key component, perform a second collaborative signature interaction with the second device for the key binding data to obtain the second signature data, and send the second signature data to the second device to activate the communication session; Step 114: Obtain the current time parameter and request content data, and based on the session key, perform cryptographic operations on the message to be authenticated containing the request content data and the current time parameter to generate request authentication data; Step 116: Send a service request to the second device. The service request carries the current time parameter and the authentication request data.

[0034] This application provides a dynamic token authentication method applied to a first device. The first device stores a first private key component corresponding to the target user's identity. By splitting the user's long-term identity private key into independent components held separately by the first device, the complete private key cannot be synthesized from a single private key component, thus avoiding the risk of leakage due to a single device storing the complete key. This application proposes a distributed trust scheme. Upon detecting a session establishment request between the first and second devices, a first temporary key pair is generated. The first temporary key pair includes a first temporary public key and a first temporary private key. By generating exclusive temporary key material for each session, the long-term key is prevented from being exposed during key negotiation, thereby ensuring the forward security of the session key. Even if the key of one session is leaked, it will not affect the security of other sessions. Based on the obtained target user identity identifier, information uniquely identifying the user's identity is read from the first device's local secure storage area, providing a data foundation for subsequently clarifying the identity of the user to be authenticated to the second device, ensuring that the second device can accurately locate the corresponding cryptographic material. Based on the first private key component, a first collaborative signature interaction is performed with the second device to obtain first signature data for the first temporary public key. The first temporary public key, the first signature data, and the target user's identity identifier are sent to the second device. The signature operation is completed collaboratively using the private key components held by both devices, cryptographically binding the first temporary public key with the target user's long-term identity to generate a tamper-proof identity assertion. This allows the second device to verify the legitimate ownership of the temporary public key, initially blocking man-in-the-middle attack paths. Based on the second temporary public key returned by the second device, a session key is determined based on the first and second temporary private keys. Key negotiation is conducted using the temporary key materials of both parties to generate a one-time session key valid only in the current session. This ensures the confidentiality and independence of session communication, avoids cross-session security risks caused by key reuse, and improves interaction security. Based on the first and second temporary public keys, key binding data is constructed. By integrating the temporary identity information of both parties, a unique identifier is generated, providing a core basis for subsequent verification of key negotiation consistency and ensuring that both parties have a consistent understanding of the temporary key. Based on the first private key component, a second collaborative signature interaction is performed with the second device for the key binding data to obtain the second signature data, and the second signature data is sent to the second device to activate the communication session. The key negotiation result is confirmed a second time through the second collaborative signature, and the user's long-term identity and temporary session are double-cryptographically bound, thereby blocking the attack path of man-in-the-middle tampering with session information to a certain extent and ensuring the security of session activation.Based on the obtained current time parameter and request content data, cryptographic operations are performed on the message to be authenticated, which contains the request content data and the current time parameter, using the session key to generate authentication request data. By strongly binding the core content of the business request with the time dimension, authentication information uniquely corresponding to a single request is generated, eliminating the need for a static token with a fixed validity period and preventing the illegal reuse of authentication information after eavesdropping. The business request, carrying the current time parameter and authentication request data, is sent to the second device. A client-side dynamic issuance of authentication credentials model is adopted, eliminating the need for centralized token management on the second device, thus reducing server-side security pressure. This model is also compatible with various stateless authentication scenarios such as web applications and mobile internet services.

[0035] Specifically, this invention relates to the field of network identity authentication technology, and more specifically to a dynamic token authentication method based on collaborative signatures. This invention proposes a dynamic token authentication method applied to a first device. The first device stores a first private key component corresponding to the target user's identity. This private key component is an independent part obtained by splitting the user's long-term identity private key using a (2,2) threshold collaborative signature algorithm; no single private key component can synthesize a complete private key. When a session establishment request between the first device and a second device is detected, the first device generates a first temporary key pair containing a first temporary public key and a first temporary private key. After obtaining the target user's identity identifier, it performs a first collaborative signature interaction with the second device based on the first private key component, obtaining first signature data for the first temporary public key. It then sends the first temporary public key, the first signature data, and the target user's identity identifier to the second device, cryptographically binding the temporary public key with the user's long-term identity. After receiving the second temporary public key returned by the second device, the first device determines a one-time session key valid only in the current session based on the first temporary private key and the second temporary public key. It then concatenates the first temporary public key and the second temporary public key byte-wise and performs a cryptographic hash operation on the concatenation result to construct key binding data. Subsequently, the first device performs a second collaborative signature interaction with the second device based on the first private key component, obtaining the second signature data and sending it to the second device to activate the communication session, thus completing the dual binding of the user's long-term identity and temporary session. When initiating a service request, the first device obtains the current time parameter and request content data containing the Hypertext Transfer Protocol request method and the request for a Uniform Resource Identifier. It concatenates these three data points in a preset order, separating adjacent fields with a preset delimiter, to determine the message to be authenticated. Then, based on the session key, it performs cryptographic operations on the message to be authenticated to generate request authentication data, and finally sends a service request carrying the current time parameter and request authentication data to the second device.

[0036] This invention departs from the centralized token issuance model on the server side, instead employing a distributed private key splitting and storage architecture. It achieves dual verification of identity assertion and session binding through two collaborative signatures, while the client dynamically generates one-time authentication information strongly bound to the request content and timestamp. This application constructs a distributed trust architecture, splitting the user's long-term identity private key into two components, held separately by the client and server, eliminating the risk of a single point of failure for the server-side key at the cryptographic level. Secondly, this application designs a key negotiation process with dual collaborative signatures, cryptographically binding the user's long-term identity with the temporary session, effectively resisting man-in-the-middle attacks. Furthermore, this application implements a client-side dynamic authentication issuance mechanism, generating independent authentication information for each business request, thus addressing the limitation of static token reusability. Furthermore, this application addresses the issue that a single leaked private key component cannot generate a valid digital signature, thus mitigating the risk of a single point of failure in the authentication scheme. The dual collaborative signature mechanism ensures that both the temporary public key and the session key are bound to the legitimate user identity, effectively blocking man-in-the-middle attack paths. The authentication information uniquely corresponds to the content and time of each request, preventing replay and theft of authentication information. The private key component is stored and recovered using pure software, requiring no dedicated hardware support, thus removing the restriction of binding identity to physical devices and adapting to multi-device authentication scenarios. Simultaneously, the entire process of this application can be implemented using the national cryptographic standards SM2, SM3, and SM4, complying with relevant specifications.

[0037] In this application, "first device" refers to a terminal device on the user side or client side, such as a smartphone, personal computer, or tablet computer, which is directly operated by the user and stores cryptographic materials bound to the user's identity. "Second device" refers to an authentication server on the network side or server side, responsible for managing the cryptographic materials of multiple users and performing signature verification and authentication processing. "Target user identity" refers to the identity information that uniquely identifies a registered user in the system, such as username or user ID (identity code). "First private key component" refers to a portion of the private key that is independently held by the first device after the user's long-term identity private key is split using the (2,2) threshold collaborative signature algorithm; it is a single share, and no single party can synthesize a complete long-term identity private key from this single share. "Session establishment request" refers to a triggering event detected by the first device that requires establishing a new communication session with the second device, such as a user logging into an application or initiating a business operation. "First temporary key pair" refers to a one-time elliptic curve key pair randomly generated by the first device for the current session, valid only in this session, including a first temporary public key and a first temporary private key. "First Temporary Public Key" refers to the publicly transmittable public key portion of the first temporary key pair, used to send to the second device for key negotiation. "First Temporary Private Key" refers to the private key portion of the first temporary key pair secretly stored by the first device, used to derive the session key. "Target User Identity Identifier" refers to information that uniquely identifies the target user, obtained by the first device from its local secure storage. "First Collaborative Signature Interaction" refers to the interaction process where the first device, based on its first private key component, and the second device, based on its second private key component, jointly execute a (2,2) threshold collaborative signature protocol over the network, collaboratively generating a digital signature without exposing their respective private key components. "First Signature Data" refers to the digital signature generated through the first collaborative signature interaction for the first temporary public key, used to enable the second device to verify that the first temporary public key indeed belongs to the target user, forming an identity assertion. "Second Temporary Public Key" refers to the public key portion of the second temporary key pair generated by the second device for the current session, returned by the second device to the first device for key negotiation. "Session key" refers to the symmetric key derived by the first device using a key negotiation algorithm based on its own first temporary private key and the received second temporary public key. It is valid only in the current session and is used to generate authentication data for subsequent business requests. "Key binding data" refers to data constructed using the first and second temporary public keys, uniquely identifying the participants in this key negotiation, and is used as the object to be signed in the second collaborative signature. "Second collaborative signature interaction" refers to the interaction process where the first device, based on its first private key component, re-executes the collaborative signature protocol with the second device to sign the key binding data, confirming that the key negotiation process has not been tampered with."Second signature data" refers to the digital signature generated through second collaborative signature interaction, which is used to activate the communication session after being sent to the second device. "Current time parameter" refers to the current system timestamp obtained by the first device when generating the service request, used to bind to the request content to prevent replay attacks. "Request content data" refers to the core business information of this service request. "Message to be authenticated" refers to the message formed by combining the request content data with the current time parameter, used as input for cryptographic operations. "Cryptographic operation" refers to the operation of calculating the message authentication code based on the session key. "Request authentication data" refers to the message authentication code generated through cryptographic operations, used by the second device to verify the integrity and legitimacy of the request's source. "Service request" refers to the actual service operation request initiated by the first device to the second device, carrying authentication information.

[0038] In some embodiments of this application, the first device stores a first private key component corresponding to the target user's identity, including: in response to an identity recovery request for the target user's identity, downloading the encrypted first private key component and a random salt value, wherein both the encrypted first private key component and the random salt value correspond to the target user's identity; performing key derivation based on the obtained password data and the random salt value to obtain a decryption key; decrypting the encrypted first private key component based on the decryption key, and writing the obtained decrypted first private key component into the random access memory of the first device.

[0039] In the above embodiments, the first device stores a first private key component corresponding to the target user's identity. This includes downloading the encrypted first private key component and a random salt value in response to an identity recovery request for the target user's identity. Both the encrypted first private key component and the random salt value correspond to the target user's identity. By transmitting and storing the first private key component in ciphertext, plaintext leakage during transmission is avoided. Simultaneously, the random salt value is introduced as a random factor in key derivation, reducing the probability of being cracked and preventing external decryption attacks, thus ensuring the security of the encrypted material. Based on the obtained password data and the random salt value, a key derivation is performed to obtain a decryption key. The user-input password is converted into a decryption key using a password-based key derivation function, preventing direct password exposure and thus achieving a secure association between the user's identity and the private key component. Only legitimate users with the correct password can generate a valid decryption key. The encrypted first private key component is decrypted based on the decryption key, and the decrypted first private key component is written into the random access memory of the first device. By completing the decryption and temporary storage in volatile memory, the decrypted private key component only exists when the device is running and is automatically cleared when the device is powered off or the process ends. It will not be written to persistent storage media in plaintext, thus preventing the leakage of private key components on the device. At the same time, no dedicated hardware security module is required. Multi-device identity security recovery is achieved by relying on pure software, removing the restriction of identity binding to physical device, and adapting to the user's multi-terminal usage needs.

[0040] In some embodiments of this application, constructing key binding data based on a first temporary public key and a second temporary public key includes: concatenating the first temporary public key and the second temporary public key into bytes, and performing a cryptographic hash operation on the concatenation result to obtain key binding data.

[0041] In the above embodiments, key binding data is constructed based on the first temporary public key and the second temporary public key. This includes concatenating the first temporary public key and the second temporary public key into bytes, and performing a cryptographic hash operation on the concatenated result to obtain the key binding data. The temporary public key information of both communicating parties is integrated through the byte concatenation operation to ensure that the binding data is associated with the temporary identities of both parties. Then, by utilizing the irreversible and collision-resistant properties of the cryptographic hash function, the concatenated result of any length is converted into a unique hash value of fixed length. Any slight change to the original data will result in a completely different hash result, thereby preventing the binding data from being tampered with. This provides a trusted object to be signed for the subsequent second collaborative signature, ensuring that the second device can accurately verify that the key negotiation process has not been tampered with by a man-in-the-middle, and supporting the secure activation of the session.

[0042] In some embodiments of this application, the request content data in the message to be authenticated includes: the Hypertext Transfer Protocol Request Method and the Request Uniform Resource Identifier of the current business request; the Hypertext Transfer Protocol Request Method, the Uniform Resource Identifier and the current time parameter are concatenated in a preset order and adjacent fields are separated by a preset delimiter to determine the message to be authenticated.

[0043] In the above embodiments, the request content data in the message to be authenticated includes the Hypertext Transfer Protocol (HTTP) request method of the current business request and the Request Uniform Resource Identifier (URLI). By using the HTTP request method, which identifies the request operation type, and the URLI, which identifies the request resource path, as the core components of the request content data, the core content of the business request is uniquely determined, directly associating the authentication information with the specific business request. Based on the HTTP request method, the URLI, and the current time parameter, the fields are concatenated in a preset order, with adjacent fields separated by a preset delimiter, to determine the message to be authenticated. By fixing the field concatenation order and delimiters, it is ensured that the logic of constructing the message to be authenticated by the first device and the second device is completely consistent, avoiding authentication failure due to format differences. Simultaneously, the message to be authenticated is associated with the request operation, the target resource, and the time dimension, thereby ensuring that the generated request authentication data corresponds only to the specific request at that time, preventing authentication information from being misappropriated to other requests, and improving the accuracy and security of authentication.

[0044] In some embodiments of this application, the first and second collaborative signature interactions adopt the national cryptographic SM2 collaborative signature algorithm; the key derivation adopts the PBKDF2 key derivation function based on SM3, and the cryptographic operation adopts the hash message authentication code algorithm based on SM3; the encryption and decryption of the encrypted first private key component both adopt the national cryptographic SM4 symmetric encryption algorithm.

[0045] In the above embodiments, the first and second collaborative signature interactions employ the SM2 collaborative signature algorithm, a national cryptographic standard. Leveraging the high security and threshold signature characteristics of the SM2 elliptic curve cryptography algorithm, the first and second devices collaboratively complete digital signatures without exposing their respective private key components. This adapts to the signature requirements of a distributed private key architecture and ensures the security of the signature process. Key derivation utilizes the PBKDF2 key derivation function based on SM3, using the SM3 hash algorithm as a pseudo-random function. Through multiple iterative operations, the user password and random salt value are transformed into a high-strength decryption key, thereby enhancing the security strength of the password-derived key and effectively resisting forced cracking attacks. Cryptographic operations employ the SM3-based hash message authentication code algorithm, combining the session key and the message to be authenticated to generate a tamper-proof message authentication code. This simultaneously verifies the integrity of the requested data and authenticates the source identity, ensuring that the business request has not been tampered with and originates from a legitimate user. Encryption and decryption of the encrypted first private key component both employ the SM4 symmetric encryption algorithm, utilizing the high encryption efficiency and strong anti-attack capabilities of the SM4 block cipher algorithm to ensure the confidentiality of the first private key component during storage and transmission. The entire process adopts the national cryptographic standards SM2, SM3, and SM4, thereby complying with relevant information security specifications and achieving independent control over cryptographic algorithms, thus resolving compliance risks and backdoor vulnerabilities associated with non-national cryptographic algorithms.

[0046] like Figure 2 As shown, an embodiment of this application provides a dynamic token authentication method applied to a second device. The second device stores multiple users' respective second private key components and a unified public key. The dynamic token authentication method includes: Step 202: Receive the first temporary public key, the first signature data, and the target user identity identifier sent by the first device; Step 204: Determine the target user based on the target user's identity identifier; Step 206: Obtain the target unified public key corresponding to the target user's identity from the stored unified public keys corresponding to each of the multiple users; Step 208: Verify the first signature data based on the target unified public key; Step 210: Upon successful verification, generate a second temporary key pair and return the second temporary public key from the second temporary key pair to the first device; Step 212: Construct local key binding data based on the first temporary public key and the second temporary public key; Step 214: Receive the second signature data sent by the first device, and verify whether the second signature data is a valid signature for the local key-bound data based on the target unified public key; Step 216: Upon successful verification, determine the session key based on the second temporary private key and the first temporary public key in the second temporary key pair, and activate the communication session. Activation includes associating and storing the session key with the target user's identity and the initial timestamp. Step 218: Receive a service request sent by the first device. The service request carries the current time parameter and the authentication request data. Step 220: Perform a timeliness check on the current time parameter. If the check passes, construct a local authentication message based on the content of the business request. Step 222: Perform cryptographic operations on the local message to be authenticated based on the activated session key to generate local message authentication data; Step 224: Compare the local message authentication data with the request authentication data. If the local message authentication data and the request authentication data are consistent, pass the identity authentication and process the business request.

[0047] This application proposes a dynamic token authentication method applied to a second device. The second device stores multiple users' respective second private key components and a unified public key. By storing another portion of the user's long-term identity private key separately on the second device, which does not hold the complete private key and cannot independently generate a valid digital signature, the risk of single-point failure due to centralized key storage on the authentication server and subsequent mass misuse of tokens by third parties is reduced. Simultaneously, the unified public key is bound to the user's identity for storage, providing a unified and legitimate credential for signature verification. Based on the first temporary public key, first signature data, and target user identity identifier sent by the first device, the method obtains the identity assertion materials and user identity information submitted by the client, providing input data for subsequent identity verification and key negotiation. The method identifies the target user based on the target user identity identifier, accurately locking the user to be authenticated in a multi-user environment, ensuring that the subsequently obtained cryptographic materials accurately correspond to the user, and avoiding authentication errors caused by user identity confusion. Finally, the method obtains the target unified public key corresponding to the target user's identity from the stored unified public keys corresponding to multiple users, extracting the user's unique public key to provide the correct key basis for verifying the first signature data. Based on the verification of the first signature data using the target unified public key, the legitimacy of the signature is asserted by verifying the identity, confirming the binding relationship between the first temporary public key and the target user's long-term identity, thereby filtering illegal requests and blocking identity impersonation in the early stages of session establishment. Upon successful verification, a second temporary key pair is generated and the second temporary public key from the second temporary key pair is returned to the first device. By generating server-side temporary key materials, a two-way temporary key system is constructed, ensuring that the session key is composed of randomness contributed by both parties, thus improving the security of key negotiation. Based on the first and second temporary public keys, local key binding data is constructed. By constructing the binding data in the same way as the first device, both parties' understanding of the key negotiation result is consistent, providing a benchmark for the verification of the second signature data. Based on the second signature data received from the first device, the second signature data is verified as a valid signature for the local key binding data using the target unified public key. By verifying the legitimacy of the session binding signature, it is confirmed that the key negotiation process has not been tampered with by a man-in-the-middle attack, thus completing dual signature verification and mitigating man-in-the-middle attacks to a certain extent. Upon successful verification, a session key is determined based on the second temporary private key and the first temporary public key in the second temporary key pair, and the communication session is activated. Activation includes associating and storing the session key with the target user's identity and initial timestamp, generating a session key that is completely identical to the first device, and establishing a session state containing the user's identity and initial timestamp. This provides a state basis for the verification of subsequent business requests and enables session management under stateless communication.Upon receiving a business request from the first device, which carries a current time parameter and authentication request data, the verification process for the business request is initiated by acquiring authentication information dynamically generated by the client. The current time parameter is validated for timeliness. If the validation passes, a local message to be authenticated is constructed based on the content of the business request. This involves first verifying the time validity of the request, filtering out expired and replayed requests, and then constructing a message identical to the one from the first device, thus providing a consistent basis for authentication data comparison. Cryptographic operations are performed on the local message to be authenticated based on the activated session key to generate local message authentication data. Authentication data is independently calculated using the session key stored on the server, enabling server-side self-verification without relying on tokens sent by the client. The local message authentication data is compared with the request authentication data. If they match, authentication is performed, and the business request is processed. Cryptographic comparison confirms the integrity and authenticity of the request's source. Only legitimate users with the correct session key can generate matching authentication data, thus achieving independent authentication for each business request and improving the security of interaction and data transmission.

[0048] In some embodiments of this application, the timeliness of the current time parameter is verified, including: verifying whether the current time parameter is within a preset valid time window; and verifying whether the current time parameter is greater than the latest historical timestamp stored in the second device for the current communication session; and updating the latest historical timestamp to the current time parameter when both verifications pass.

[0049] In the above embodiments, the current time parameter is validated for timeliness, including checking whether the current time parameter is within a preset valid time window. By setting a reasonable time range, expired requests exceeding the server's allowed time deviation and premature requests from the future are filtered out, thus forming the first line of defense against replay attacks. Based on whether the current time parameter is greater than the latest historical timestamp stored in the second device for the current communication session, by requiring request timestamps to strictly increment, requests within the same session are ensured to be submitted in chronological order, thereby preventing replay attacks on valid authentication information within the valid time window. Even if an attacker intercepts authentication information that has not yet expired, they cannot successfully replay it. When both validations pass, the latest historical timestamp is updated to the current time parameter. By dynamically maintaining the latest timestamp state of the session, the validation benchmark for subsequent requests is continuously advanced, thus forming a continuous time-series protection chain and ensuring the continuous effectiveness of the timeliness validation mechanism. The dual time validation mechanisms work together to ensure the freshness of requests from both absolute timeliness and relative sequence dimensions, thereby completely preventing the replay use of authentication information.

[0050] In one embodiment, the present invention provides an end-to-end dynamic token authentication process that comprehensively applies all the aforementioned technical solutions.

[0051] First, during system initialization, the first and second devices jointly generate the user's long-term identity private key using a (2,2) threshold collaborative signature algorithm. This private key is then split into a first private key component and a second private key component, which are held independently by the first and second devices respectively. A corresponding unified public key is generated and stored on the second device. No single party can synthesize a complete long-term identity private key from its own components, thus eliminating the risk of a single point of failure for the server-side key at the cryptographic level.

[0052] When a user needs to restore their identity on a new device, the first device executes the identity restoration process as described above. In response to the identity restoration request, the first device downloads an encrypted first private key component and a random salt value corresponding to the target user's identity from the cloud. The first device prompts the user for a password and, based on the password and the downloaded random salt value, performs key derivation using the PBKDF2 key derivation function based on SM3 to obtain the decryption key. The first device uses the SM4 symmetric encryption algorithm to decrypt the encrypted first private key component in local random access memory, recovering the plaintext first private key component. This plaintext component resides only in memory and is not persistently stored, thus achieving secure identity restoration across multiple devices without the need for dedicated hardware security modules.

[0053] When a user initiates a business operation, a secure communication session must first be established. After detecting the session establishment request, the first device generates a first temporary key pair containing a first temporary public key and a first temporary private key. The first device obtains the current target user's identity identifier, and then, based on the first private key component it holds, performs a first collaborative signature interaction with the second device to obtain first signature data for the first temporary public key, and sends the first temporary public key, the first signature data, and the target user's identity identifier to the second device.

[0054] After receiving the aforementioned data, the second device identifies the target user based on the target user's identity identifier, retrieves the target unified public key corresponding to the target user from the stored unified public keys corresponding to multiple users, and uses this public key to verify the first signature data. Successful verification confirms that the first temporary public key indeed belongs to the claimed target user. Subsequently, the second device generates a second temporary key pair containing a second temporary public key and a second temporary private key, and returns the second temporary public key to the first device.

[0055] After receiving the second temporary public key, the first device determines the session key using the SM2 key negotiation algorithm based on its own first temporary private key and the received second temporary public key. Simultaneously, following the aforementioned preferred method, the first device concatenates the first and second temporary public keys byte-by-byte and performs an SM3 cryptographic hash operation on the concatenation result to obtain key binding data. Subsequently, the first device again performs a second collaborative signature interaction with the second device based on the first private key component, obtaining second signature data, and sends the second signature data to the second device.

[0056] The second device independently constructs local key binding data identical to that of the first device. After receiving the second signature data, it verifies it using the target unified public key. Successful verification confirms that the key negotiation process has not been tampered with by a man-in-the-middle and that the first device has successfully derived the correct session key. At this point, the second device derives the same session key based on its own second temporary private key and first temporary public key, and activates the communication session. The activation operation includes associating and storing the session key with the target user's identity and the current time as an initial timestamp.

[0057] After the session is activated, the user initiates a specific business request. The first device obtains the current time parameter and request content data containing the HTTP (Hypertext Transfer Protocol) request method and request URI (Uniform Resource Identifier). Following the aforementioned preferred method, it concatenates these fields in a preset order with a preset delimiter to construct a message to be authenticated. The first device uses the session key to perform cryptographic operations on the message to be authenticated using the SM3-HMAC (Hash-based Message Authentication Code) algorithm to generate request authentication data, and sends the business request carrying the current time parameter and request authentication data to the second device.

[0058] After receiving the service request, the second device performs the aforementioned dual timeliness check on the current time parameter: first, it checks whether the current time is within a preset valid time window; second, it checks whether the current time is strictly greater than the latest historical timestamp stored in the current communication session. If both checks pass, the latest historical timestamp is updated to the current time parameter. Subsequently, based on the content of the service request, the second device constructs a local message to be authenticated using the exact same rules as the first device, retrieves the corresponding session key from the session storage, and generates local message authentication data using the same SM3-HMAC algorithm. The second device compares the local message authentication data with the received request authentication data; if they match, authentication is successful and the service request is processed.

[0059] like Figure 3 As shown, this application provides a dynamic token authentication device 300, applied to a first device. The first device stores a first private key component corresponding to the identity of a target user. The dynamic token authentication device 300 includes: a first detection module 310, a first acquisition module 320, a second acquisition module 330, a first determination module 340, a first construction module 350, a third acquisition module 360, a fourth acquisition module 370, and a first interaction module 380. The first detection module 310 is used to generate a first temporary key pair when a session establishment request between the first device and the second device is detected. The first temporary key pair includes a first temporary public key and a first temporary private key. The first acquisition module 320 is used to acquire the identity identifier of the target user. The second acquisition module 330 is used to perform a first collaborative signature interaction with the second device based on the first private key component to acquire first signature data for the first temporary public key, and send the first temporary public key, the first signature data, and the identity identifier of the target user to the second device. The first determination module 340 is used to receive the second temporary public key returned by the second device and determine the session key based on the first temporary private key and the second temporary public key. The construction module 350 is used to construct key binding data based on the first temporary public key and the second temporary public key; the third acquisition module 360 ​​is used to perform a second collaborative signature interaction with the second device on the key binding data based on the first private key component to obtain the second signature data, and send the second signature data to the second device to activate the communication session; the fourth acquisition module 370 is used to acquire the current time parameter and request content data, and perform cryptographic operations on the message to be authenticated containing the request content data and the current time parameter based on the session key to generate request authentication data; the first interaction module 380 is used to send a service request to the second device, the service request carrying the current time parameter and request authentication data.

[0060] The dynamic token authentication device 300 proposed in this application is applied to a first device. The first device stores a first private key component corresponding to the target user's identity. The dynamic token authentication device 300 includes: a first detection module 310, a first acquisition module 320, a second acquisition module 330, a first determination module 340, a first construction module 350, a third acquisition module 360, a fourth acquisition module 370, and a first interaction module 380. By employing the interaction and cooperation of multiple modules, this application abandons the centralized token issuance mode on the server side and instead adopts a distributed private key split storage architecture. It achieves dual verification of identity assertion and session binding through two collaborative signatures, while the client dynamically generates one-time authentication information strongly bound to the request content and timestamp. This application constructs a distributed trust architecture, splitting the user's long-term identity private key into two components held by the client and server respectively, eliminating the risk of single point of failure of the server key from a cryptographic perspective. Secondly, this application designs a key negotiation process with dual collaborative signatures, cryptographically binding the user's long-term identity with the temporary session to effectively resist man-in-the-middle attacks. Simultaneously, this application implements a dynamic client-side authentication mechanism, generating independent authentication information for each business request, thus addressing the limitation of reusable static tokens. Furthermore, this application eliminates the risk of single-point-of-failure in authentication schemes due to the leakage of a single private key component. The dual collaborative signature mechanism ensures that both the temporary public key and the session key are bound to the legitimate user identity, effectively blocking man-in-the-middle attack paths. The authentication information uniquely corresponds to the content and time of each request, preventing replay and theft of authentication information. The private key component is stored and recovered using pure software, requiring no dedicated hardware support, removing the binding restriction between identity and physical devices, and adapting to multi-device authentication scenarios. Moreover, the entire process of this application can be implemented using the national cryptographic standards SM2, SM3, and SM4, complying with relevant specifications.

[0061] like Figure 4As shown, this application provides a dynamic token authentication device 400, applied to a second device. The second device stores multiple users' respective second private key components and a unified public key. The dynamic token authentication device 400 includes: a first receiving module 410, a second determining module 412, a fifth obtaining module 414, a second interaction module 416, a third interaction module 418, a fourth interaction module 420, a fifth interaction module 422, a first verification module 424, a second receiving module 426, a first verification module 428, a first activation module 430, and a first comparison module 440. The receiving module 410 is used to receive the first temporary public key, the first signature data, and the target user identity identifier sent by the first device; the second determining module 412 is used to determine the target user based on the target user identity identifier; the fifth obtaining module 414 is used to obtain the target unified public key corresponding to the target user identity from the stored unified public keys corresponding to multiple users; the second interaction module 416 is used to verify the first signature data based on the target unified public key; the third interaction module 418 is used to generate a second temporary key pair when the verification is successful, and return the second temporary key in the second temporary key pair to the first device. The system includes: a public key; a fourth interaction module 420 for constructing local key binding data based on a first temporary public key and a second temporary public key; a fifth interaction module 422 for receiving second signature data sent by a first device and verifying whether the second signature data is a valid signature for local key binding data based on the target unified public key; a first verification module 424 for determining a session key based on the second temporary private key and the first temporary public key in the second temporary key pair when verification is successful, and activating a communication session, including associating and storing the session key with the target user's identity and initial timestamp; a second receiving module 426 for receiving a service request sent by a first device, the service request carrying a current time parameter and a request authentication data; a first verification module 428 for performing a timeliness verification on the current time parameter, and constructing a local message to be authenticated based on the content of the service request when verification is successful; a first activation module 430 for performing cryptographic operations on the local message to be authenticated based on the activated session key to generate local message authentication data; and a first comparison module 440 for comparing the local message authentication data with the request authentication data, and passing identity authentication and processing the service request when the local message authentication data and the request authentication data are consistent.

[0062] Based on the dynamic token authentication device 400 provided in this application, it is possible to realize that a single private key component leakage cannot generate a valid digital signature, thereby eliminating the risk of single point of failure of the key in the authentication scheme to a certain extent. The dual collaborative signature mechanism ensures that both the temporary public key and the session key are bound to the legitimate user identity, effectively blocking the man-in-the-middle attack path.

[0063] like Figure 5As shown, an embodiment of this application provides a dynamic token authentication device 500. The dynamic token authentication device 500 is applied to a first device and includes: a first memory 510 for storing a first private key component corresponding to the target user's identity and a computer program; and a first processor 520 for executing the computer program to implement the steps of any of the dynamic token authentication methods described in the above embodiments. Therefore, the dynamic token authentication device 500 possesses all the beneficial effects of the dynamic token authentication method.

[0064] like Figure 6 As shown, an embodiment of this application provides a dynamic token authentication device 600. The dynamic token authentication device 600 is applied to a second device and includes: a second memory 610 for storing second private key components corresponding to multiple users, a unified public key, and a computer program; and a second processor 620 for executing the computer program to implement the steps of the dynamic token authentication method as described in the above embodiment. Therefore, the dynamic token authentication device 600 possesses all the beneficial effects of the dynamic token authentication method.

[0065] Embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the dynamic token authentication methods described above. Therefore, the computer-readable storage medium possesses all the beneficial effects of the dynamic token authentication method.

[0066] like Figure 7As shown, in the user's initial registration and key generation process, the "client / browser" corresponds to the "first device," and the "server / Web service" corresponds to the "second device" in the aforementioned scheme. Furthermore, to achieve distributed trust, this scheme also introduces a "collaborative signature cryptographic machine" and "cloud storage" as auxiliary entities in its architecture. The specific execution process is as follows: First, the user initiates a registration request to the second device (i.e., the server / Web service) through the first device (i.e., the client / browser). After receiving the request, the second device interacts with the collaborative signature cryptographic machine to jointly "execute the collaborative signature key generation protocol." During the execution of this protocol, the "collaborative signature cryptographic machine" jointly calculates and "generates a unified public key, generates a first private key component (hereinafter referred to as private key share A), and generates a second private key component (hereinafter referred to as private key share B)," where "private key share A" corresponds to the "first private key component" in the aforementioned scheme, "private key share B" corresponds to the "second private key component" in the aforementioned scheme, and the "unified public key" corresponds to the "unified public key" in the aforementioned scheme. Subsequently, the collaborative signature cryptographic machine returns the unified public key, private key shares A, and B to the second device. The second device binds and stores the unified public key with the user's identity, and separately "returns private key share A" to the first device. On the first device side, in response to the user's registration action, the client guides the user to "set a master password and generate a random salt value," and locally "derives an encryption key through KDF." The specific algorithm for this step is the "PBKDF2 key derivation function based on SM3" in the aforementioned scheme. Next, the first device "encrypts private key share A using the derived key" in its local memory, converting it into a high-strength encrypted data block. Finally, the first device "synchronizes the random salt value and the encrypted private key share A to the cloud" for storage to establish a binding relationship with the user account. At the same time, the first device securely stores the encrypted first private key component and salt value locally, completing the key configuration loop for the initial registration.

[0067] like Figure 8As shown, the complete workflow of identity recovery for the first device under specific conditions in the multi-device identity recovery process is explained in detail. The specific execution process is as follows: When the first device (client / browser) triggers the identity recovery logic, in response to the identity recovery request for the target user's identity, the first device downloads the saved salt value and encrypted private key share A from the cloud via the network interface. The encrypted first private key component and the random salt value both correspond to the target user's identity. Subsequently, the first device prompts the user to enter a password and calls local secure computing power to recalculate the encryption key using the master password and the obtained salt value through KDF derivation. The specific algorithm here is also the "PBKDF2 key derivation function based on SM3" mentioned in the previous scheme. After successfully deriving the decryption key, the first device executes an explicit data erasure management mechanism locally: "using the calculated encryption key to decrypt the plaintext private key share A," and writes the decrypted first private key component into the first device's random access memory for subsequent session authentication processes. This ensures that the plaintext component is not written to long-term device storage, thus achieving secure identity recovery for multiple devices.

[0068] like Figure 9 As shown, this embodiment provides a detailed explanation of the complete interactive timing of the collaborative negotiation of a one-time session key between the first device and the second device in the dynamic session key negotiation process. Figure 9 In this context, "C" corresponds to the "first device" in the aforementioned scheme, and "S" corresponds to the "second device" in the aforementioned scheme. In the initial state before the process starts, client C "already holds private key share A" (i.e., the first private key component), and server S "already holds private key share B and the user's public key" (i.e., the second private key component and the unified public key). The specific timing sequence of collaborative negotiation and verification is as follows: Step 1: When client C detects a session establishment request between the first device and the second device, it generates a temporary SM2 key pair (c_sk, c_pk) locally, where c_sk is the first temporary private key and c_pk is the first temporary public key.

[0069] Step 2: Client C and server S jointly “execute collaborative signature application (1)”. The core mechanism is that “C and S use their respective private key shares to collaboratively sign c_pk”. Through distributed cryptographic operations, “client C finally obtains tss_signature_1”. tss_signature_1 corresponds to the first signature data in the aforementioned scheme (as identity assertion signature data).

[0070] Step 3: Client C sends an identity assertion (c_pk, tss_signature_1) to server S via a secure channel.

[0071] Step 4: After receiving the above data, server S verifies tss_signature_1 locally using the user's public key. Here, we enter a choice branch (alt): If the verification fails, we enter the "Verification Failed" branch, server S returns "Error: Identity Assertion Failed" to client C and terminates the process; if the verification succeeds, we enter the "Verification Successful" branch and continue execution.

[0072] Step 5: Upon successful verification, the server S generates its own temporary SM2 key pair (s_sk, s_pk) locally, where s_sk is the second temporary private key and s_pk is the second temporary public key.

[0073] Step 6: Server S executes the "Respond to Challenge: s_pk" action to client C, returning the second temporary public key to client C.

[0074] Step 7: After receiving s_pk, client C uses c_sk and s_pk locally to derive the session key using the SM2 key negotiation algorithm, thus determining the one-time session key for the current session.

[0075] Step 8: Client C constructs a binding message locally based on the first temporary public key and the second temporary public key: binding_message=SM3_HASH(c_pk||s_pk). The binding_message corresponds to the key binding data in the aforementioned scheme, and its concatenation and hashing algorithm corresponds to the aforementioned scheme.

[0076] Step 9: Client C and server S jointly “execute collaborative signature application (2)”, that is, “C and S collaboratively sign binding_message”. Through the second threshold collaborative calculation, “client C finally obtains tss_signature_2”, which corresponds to the second signature data in the aforementioned scheme (as session binding signature data).

[0077] Step 10: Client C sends session binding signature: tss_signature_2 to server S.

[0078] Step 11: After receiving the signature, the server S constructs a binding_message locally as the local key binding data.

[0079] Step 12: Server S verifies tss_signature_2 locally using the user's public key. Here, the second branch (alt) is entered: If verification fails, the server enters the "Verification Failed" branch, returns "Error: Session binding failed" to client C, and terminates the process; if verification succeeds, the server enters the "Verification Successful" branch and continues execution.

[0080] Step 13: Upon successful verification, the server S locally "derives the same sessionKey using s_sk and c_pk" to complete the synchronization of the two-end keys.

[0081] Step 14: Server S stores the synchronized session key as "sessionKey, activates the session", and sends a "session activation successful" message to client C. At this point, the communication session is officially activated, and both parties begin the protected stateless communication phase.

[0082] like Figure 10 The diagram illustrates the stateless authentication interaction process between client C (first device) and server S (second device). The initial state at the start of the process is "both parties already possess the same sessionKey". The specific authentication, transmission, and comparison processing sequence is as follows: Step 1: Client C obtains the current time parameter and request content data, and constructs the authentication message auth_message locally (e.g., http_method+"|"+uri+"|"+timestamp)). Here, http_method is the Hypertext Transfer Protocol request method, uri is the Uniform Resource Identifier, and timestamp is the current timestamp. This concatenation logic perfectly corresponds to the structured field concatenation of the aforementioned scheme.

[0083] Step 2: Client C "uses sessionKey to calculate authentication code mac", the specific calculation formula is "mac=SM3_HMAC(sessionKey,auth_message)", mac corresponds to the request authentication data in the above scheme, and adopts the hash message authentication code algorithm based on the national cryptographic SM3.

[0084] Step 3: Client C sends a business request to server S (carrying timestamp and MAC in the header), dynamically adding the current time parameter and the request authentication data to the request header of the Hypertext Transfer Protocol and sending them together.

[0085] Step 4: After receiving the business request, the server S extracts the timestamp and mac from the request header.

[0086] Step 5: Server S first performs an initial security screening of the time parameter, executing "time window verification & strict timestamp increment verification" locally. This step perfectly corresponds to the specific verification details of the aforementioned scheme. Here, we enter the selection branch (alt): If either of the two verifications fails, we enter the "time verification failed" branch, and server S directly returns "Error: request timed out or replay attack" to client C and terminates the process; if the time verification passes, we enter the "time verification passed" branch.

[0087] Step 6: When the time verification passes, the server S constructs the same auth_message based on the received request content locally and reproduces the message to be authenticated.

[0088] Step 7: Server S "looks up sessionKey from session storage" to dynamically obtain the activation session key corresponding to the target user.

[0089] Step 8: Server S calculates the local authentication code local_mac locally. The specific calculation formula is "local_mac=SM3_HMAC(sessionKey,auth_message)", which dynamically generates the local message authentication data on the server side.

[0090] Step 9: Server S performs the "compare mac with local_mac" operation locally. Here, the final core selection branch (alt) is entered: if the two are not equal, the server enters the "mac!=local_mac (authentication failed)" branch, returns "Error: Invalid authentication" to client C, and refuses business processing; if the two are completely equal, the server enters the "mac==local_mac (authentication successful)" branch.

[0091] Step 10: Upon successful authentication, server S executes "update timestamp and process business logic" locally. This means that the authentication is officially passed, the latest timestamp of the session stored locally is dynamically updated to the time parameter of the current request, and confidential business content is processed.

[0092] Step 11: After the server S completes its processing, it returns the "business processing result" to the client C via a secure channel, completing the closed loop of a single valid, dynamically self-signed network business request authentication. At the end of the current communication session, the client C (the first device) will also perform an explicit security erase, deleting the recovered decrypted first private key component from its random access memory to a certain extent, leaving no persistent trace.

[0093] In the claims, description, and accompanying drawings of this invention, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the invention. In the claims, description, and accompanying drawings of this invention, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A dynamic token authentication method, characterized in that, The dynamic token authentication method is applied to a first device, which stores a first private key component corresponding to the identity of the target user, and includes: Upon detecting a session establishment request between the first device and the second device, a first temporary key pair is generated, the first temporary key pair including a first temporary public key and a first temporary private key; Obtain the target user's identity identifier; Based on the first private key component, a first collaborative signature interaction is performed with the second device to obtain first signature data for the first temporary public key, and the first temporary public key, the first signature data, and the target user identity identifier are sent to the second device. Receive the second temporary public key returned by the second device, and determine the session key based on the first temporary private key and the second temporary public key; Construct key binding data based on the first temporary public key and the second temporary public key; Based on the first private key component, perform a second collaborative signature interaction with the second device for the key binding data to obtain second signature data, and send the second signature data to the second device to activate the communication session; Obtain the current time parameter and request content data, and based on the session key, perform cryptographic operations on the message to be authenticated containing the request content data and the current time parameter to generate request authentication data; A service request is sent to the second device, the service request carrying the current time parameter and the request authentication data.

2. The dynamic token authentication method according to claim 1, characterized in that, The first device stores a first private key component corresponding to the target user's identity, including: In response to an identity recovery request for the target user's identity, an encrypted first private key component and a random salt value are downloaded, wherein both the encrypted first private key component and the random salt value correspond to the target user's identity; The decryption key is derived by using the obtained password data and the random salt value. The encrypted first private key component is decrypted based on the decryption key, and the decrypted first private key component is written into the random access memory of the first device.

3. The dynamic token authentication method according to claim 1, characterized in that, The construction of key binding data based on the first temporary public key and the second temporary public key includes: The first temporary public key and the second temporary public key are concatenated byte by byte, and the concatenation result is subjected to a cryptographic hash operation to obtain the key binding data.

4. The dynamic token authentication method according to claim 1, characterized in that, The request content data in the message to be authenticated includes: the Hypertext Transfer Protocol Request Method and the Request Uniform Resource Identifier for the current business request; The message to be authenticated is determined by concatenating the Hypertext Transfer Protocol Request Method, the Uniform Resource Identifier, and the current time parameter in a preset order, with adjacent fields separated by a preset delimiter.

5. The dynamic token authentication method according to claim 2, characterized in that, The first and second collaborative signature interactions adopt the national cryptographic SM2 collaborative signature algorithm; The key derivation uses the PBKDF2 key derivation function based on SM3, and the cryptographic operations use the hash message authentication code algorithm based on SM3. The encryption and decryption of the first private key component are performed using the national standard SM4 symmetric encryption algorithm.

6. A dynamic token authentication method, characterized in that, Applied to a second device, which stores multiple users' respective second private key components and a unified public key, the dynamic token authentication method includes: Receive the first temporary public key, the first signature data, and the target user's identity identifier sent by the first device; The target user is identified based on the target user's identity identifier; Obtain the target unified public key corresponding to the identity of the target user from the stored unified public keys corresponding to each of the multiple users; Verify the first signature data based on the target unified public key; Upon successful verification, a second temporary key pair is generated, and the second temporary public key from the second temporary key pair is returned to the first device. Construct local key binding data based on the first temporary public key and the second temporary public key; Receive the second signature data sent by the first device, and verify whether the second signature data is a valid signature for the local key binding data based on the target unified public key; Upon successful verification, a session key is determined based on the second temporary private key and the first temporary public key in the second temporary key pair, and the communication session is activated. The activation includes associating and storing the session key with the target user's identity and initial timestamp. Receive a service request sent by the first device, wherein the service request carries a current time parameter and a request for authentication data; The current time parameter is validated for timeliness. If the validation passes, a local authentication message is constructed based on the content of the business request. Cryptographic operations are performed on the local message to be authenticated based on the activated session key to generate local message authentication data; The local message authentication data is compared with the request authentication data. If the local message authentication data matches the request authentication data, the identity authentication is passed and the business request is processed.

7. The dynamic token authentication method according to claim 6, characterized in that, The timeliness verification of the current time parameter includes: Verify whether the current time parameter is within a preset valid time window; and Verify whether the current time parameter is greater than the latest historical timestamp stored in the second device for the current communication session; When both checks pass, update the latest historical timestamp to the current time parameter.

8. A dynamic token authentication device, characterized in that, The dynamic token authentication device is applied to the first device, and the dynamic token authentication device includes: The first memory is used to store the first private key component corresponding to the target user's identity and the computer program; A first processor is configured to execute the computer program to implement the steps of the dynamic token authentication method as described in any one of claims 1 to 5.

9. A dynamic token authentication device, characterized in that, The dynamic token authentication device is applied to the second device, and the dynamic token authentication device includes: The second memory is used to store the second private key components, the unified public key, and the computer program corresponding to each user. A second processor is configured to execute the computer program to implement the steps of the dynamic token authentication method as described in claim 6 or 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the dynamic token authentication method as described in any one of claims 1 to 5, or the steps of the dynamic token authentication method as described in claim 6 or 7.

Images