State detection method and device based on front-end and back-end cooperative authentication, medium and equipment

Abstract

The invention discloses a state detection method and device based on front and back end cooperative authentication, a medium and equipment. According to the method and the device, the verification request which is submitted by the front end and comprises the UKEY serial number, the current local timestamp, the historical back-end timestamp and the signature value is received, so that high-safety monitoring and management of the UKEY connection state are realized. Firstly, a verification request is subjected to signature verification, the continuity of a current local timestamp and the consistency of a historical timestamp are verified, and the integrity and legality of the verification request are ensured. And if the verification is passed, resetting a loop counter associated with the current session, generating a new timestamp, returning the new timestamp to the front end, updating a timestamp record of the front end, and maintaining the validity of the session. If the verification fails or the verification request is not received, the circular counter is accumulated until the preset threshold value is reached, and a service blocking mechanism is triggered to terminate the current session, so that illegal operation and abuse of the UKEY are effectively prevented. The problem that the connection state of the UKEY cannot be accurately detected and verified in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of status detection based on front-end and back-end collaborative authentication, and in particular to a status detection method, device, medium and equipment based on front-end and back-end collaborative authentication. Background Art

[0002] With the rapid development of information technology, network security issues are receiving increasing attention. In many application scenarios, such as internal enterprise systems and financial transaction systems, identity authentication and authorization management are key to ensuring system security. This is especially true in scenarios involving sensitive operations, such as key management and remote login, where ensuring the authenticity of user identities and the legitimacy of operations is crucial.

[0003] Currently, most systems use a B / S (browser / server)-based authentication method, using usernames and passwords for login verification. However, this traditional authentication method presents numerous security risks, such as passwords being easily cracked and user identities being stolen. To improve security, many systems have introduced multi-factor authentication (MFA), such as SMS verification codes and biometrics. Furthermore, UKEY, a common hardware security device, is also widely used in identity authentication.

[0004] UKEY usually contains a security chip that can store the user's private key and supports asymmetric encryption algorithms (such as RSA, SM2, etc.). When logging into the system, the user needs to insert the UKEY and enter the password. The system confirms the user's identity by verifying the signature in the UKEY. However, the existing UKEY authentication system has a problem of UKEY multi-terminal abuse. The existing system cannot effectively prevent the UKEY from being unplugged and then logged in again on other terminals. The simultaneous use of multiple terminals has hidden dangers such as chaotic management and difficulty in tracing. The existing system has the following problems in detecting the UKEY insertion and connection status:

[0005] Front-end detection is unreliable: Front-end web pages are easily tampered with. Attackers can bypass detection and forge detection results by modifying the front-end code.

[0006] Inaccurate back-end management: The back-end manages the usage of UKEY based on the user's login status or IP address. It cannot accurately distinguish whether the UKEY has been unplugged and used on other terminals. This can easily lead to misjudgment and affect the normal use of users who reasonably change terminals.

[0007] These deficiencies result in the inability of existing technologies to accurately detect and verify the connection status of UKEY. Summary of the Invention

[0008] The present invention provides a state detection method, device, medium and equipment based on front-end and back-end collaborative authentication to solve the problem in the prior art that the connection state of UKEY cannot be accurately detected and verified.

[0009] In a first aspect, the present application provides a status detection method based on front-end and back-end collaborative authentication, comprising:

[0010] Receive the verification request submitted by the front-end, which includes the UKEY serial number, current local timestamp, historical back-end timestamp and signature value;

[0011] Verify the signature of the verification request and check the continuity of the current local timestamp and the consistency of historical timestamps;

[0012] If the verification passes, reset the preset loop counter associated with the current session and generate a new timestamp and return it to the front end;

[0013] If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session.

[0014] This application ensures the integrity and legitimacy of the verification request by receiving a verification request submitted by the front end containing the UKEY serial number, current local timestamp, historical backend timestamp and signature value, and verifies and checks the signature of this information. Specifically, the verification process uses the characteristics of the UKEY hardware signature to prevent the possibility of forged requests; and the consistency check of the continuity of the current local timestamp and the historical backend timestamp effectively prevents replay attacks and misjudgments caused by tampering of the front-end web page. If the verification passes, the cycle counter associated with the current session is reset, and a new timestamp is generated and returned to the front end. This process not only updates the front-end timestamp record, but also ensures the system's continuous monitoring of the UKEY connection status by resetting the cycle counter. If the verification fails or no verification request is received, the cycle counter will continue to accumulate until the preset threshold is reached, triggering the service blocking mechanism to terminate the current session, thereby effectively preventing UKEY from being illegally used across terminals. This mechanism not only improves the security of the system, but also is compatible with scenarios where legitimate users reasonably change terminals. By setting reasonable counter thresholds and time windows, it ensures that users can use UKEY normally on different terminals while preventing the possibility of illegal abuse. Therefore, the present invention effectively solves the problem in the prior art that the connection status of UKEY cannot be accurately detected and verified, realizes accurate judgment of the presence status of UKEY, and meets the security and reliability requirements of business management.

[0015] As a preferred embodiment, the verification request is signed and the continuity of the current local timestamp and the consistency of the historical timestamp are verified, specifically:

[0016] Extract the UKEY serial number, current local timestamp, historical backend timestamp and signature value from the verification request;

[0017] After querying the corresponding UKEY public key based on the extracted UKEY serial number, the extracted signature value is verified using the UKEY public key;

[0018] If the signature verification passes, calculate the difference between the current local timestamp and the last recorded local timestamp, and determine whether the difference is within the preset time interval;

[0019] If the difference is within a preset time interval, it is determined whether the extracted historical backend timestamp is consistent with the backend timestamp last sent to the frontend.

[0020] In this preferred embodiment, the present application first extracts key information from the verification request, including the UKEY serial number, the current local timestamp, the historical backend timestamp and the signature value. This process ensures that all necessary information is included in the subsequent verification link. Then, the corresponding public key is queried using the UKEY serial number, and the signature value is verified using the public key. This step utilizes the characteristics of asymmetric encryption technology to ensure the integrity and non-forgeability of the verification request, because only requests signed with the correct private key can pass the public key verification. After the verification is passed, the difference between the current local timestamp and the last recorded local timestamp is further calculated, and it is determined whether the difference is within the preset time interval. This operation effectively prevents replay attacks, because any request that exceeds a reasonable time range will be identified as illegal. Finally, by comparing the extracted historical backend timestamp with the backend timestamp last sent to the front end, the consistency of the front and back end timestamps is ensured, thereby verifying the continuous connection status of UKEY. The entire process is closely linked, which not only improves the security of the system, but also ensures the correct use of UKEY and accurate monitoring of the connection status, effectively preventing misjudgments caused by illegal cross-terminal use and tampering of front-end web pages, and meeting the security and reliability requirements of business management.

[0021] As a preferred embodiment, if the verification passes, the loop counter associated with the current session is reset, and a new timestamp is generated and returned to the front end, specifically:

[0022] If the verification passes, the value of the loop counter is reset to zero, and a new backend timestamp is generated based on the server time;

[0023] The new backend timestamp is sent to the frontend to update the historical backend timestamp record of the frontend.

[0024] In this preferred embodiment, the present application achieves continuous monitoring and updating of the UKEY connection status by resetting the loop counter associated with the current session after the verification request is verified and generating a new backend timestamp and returning it to the front end. Specifically, when the verification is passed, the value of the loop counter is reset to zero. This operation ensures that the system's monitoring of the UKEY connection status will not be misjudged due to the accumulation of the counter, thereby avoiding the interruption of the session of the legitimate user due to the overflow of the counter. At the same time, a new backend timestamp is generated based on the server time and sent to the front end to update the historical backend timestamp record of the front end. This process not only ensures the consistency of the front and back end timestamps, but also provides an accurate time reference for the next verification request. Through this mechanism, the system can continuously and accurately monitor the connection status of UKEY, effectively prevent UKEY from being illegally unplugged and abused on other terminals, and is compatible with scenarios where legitimate users change different terminals to use UKEY, thereby improving the security of the system and user experience.

[0025] As a preferred embodiment, if the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically:

[0026] If the verification fails or the verification request is not received, the value of the cycle counter is incremented at a preset period;

[0027] If the value of the loop counter reaches a preset threshold, canceling the current session token and blocking the network connection associated with the session;

[0028] Send a session termination notification to the front end and reject all subsequent business requests.

[0029] In this preferred embodiment, the present application effectively prevents the illegal use and abuse of UKEY by incrementing the value of a loop counter at a preset period when a verification request fails or no verification request is received. When the counter value reaches a preset threshold, a service blocking mechanism is triggered to terminate the current session. Specifically, when verification fails or no verification request is received, the system increments the value of the loop counter at a preset period. This process ensures that the system can continuously monitor the connection status of UKEY, avoiding misjudgments caused by occasional verification failures or network delays. Once the loop counter value reaches the preset threshold, the system will cancel the current session token and block the network connection associated with the session. This measure effectively prevents the possibility of UKEY being illegally unplugged and misused on other terminals. At the same time, the system sends a session termination notification to the front end and rejects all subsequent service requests. This not only promptly notifies the user that the session has been terminated, but also further enhances the security of the system and prevents the continuation of illegal operations. Through this mechanism, the present invention ensures accurate monitoring of the UKEY connection status while effectively preventing misjudgments caused by illegal cross-terminal use and tampering of the front-end web page, significantly improving the security and reliability of the system.

[0030] As a preferred embodiment, before receiving the verification request submitted by the front end, specifically:

[0031] The front-end verification request is based on the user successfully logging in, starting a scheduled task so that the front-end obtains the current local timestamp and reads the historical back-end timestamp last received from the back-end;

[0032] Combine the UKEY serial number, the current local timestamp and the historical backend timestamp into the data to be signed;

[0033] Sign the data to be signed using the UKEY private key to generate a signature value;

[0034] The UKEY serial number, current local timestamp, historical backend timestamp and signature value are encapsulated.

[0035] In this preferred embodiment, the present application generates a verification request containing the UKEY serial number, current local timestamp, historical backend timestamp and signature value by starting the front-end timer task after the user successfully logs in, thereby ensuring the continuous monitoring and verification of the UKEY connection status. Specifically, the front-end starts the timer task after the user successfully logs in, obtains the current local timestamp and reads the historical back-end timestamp received last from the back-end. This step ensures the continuity and consistency of the timestamp. Then, the UKEY serial number, current local timestamp and historical back-end timestamp are combined into data to be signed, and signed by the UKEY private key to generate a signature value. This process utilizes the characteristics of the UKEY hardware signature to ensure the integrity and non-forgeability of the verification request. Finally, this information is encapsulated into a verification request and submitted to the back-end, providing an accurate data basis for the back-end verification. Through this mechanism, the present invention not only improves the security of the system, but also ensures the correct use of UKEY and accurate monitoring of the connection status, effectively prevents illegal cross-terminal use and misjudgment caused by tampering of the front-end web page, and significantly improves the security and reliability of the system.

[0036] In a second aspect, the present application provides a status detection device based on front-end and back-end collaborative authentication. The status detection device based on front-end and back-end collaborative authentication includes a receiving module, a signature verification module, and a verification module;

[0037] The receiving module is used to receive a verification request submitted by the front end, wherein the verification request includes a UKEY serial number, a current local timestamp, a historical backend timestamp, and a signature value;

[0038] The signature verification module is used to verify the signature of the verification request and verify the continuity of the current local timestamp and the consistency of historical timestamps;

[0039] The verification module resets the preset cycle counter associated with the current session if the verification passes, and generates a new timestamp and returns it to the front end;

[0040] If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session.

[0041] The present application realizes high-security monitoring and management of the UKEY connection status by providing a status detection device based on front-end and back-end collaborative authentication. The device includes a receiving module, a signature verification module and a verification module. Each module works together to ensure the integrity and legitimacy of the verification request. The receiving module receives the verification request submitted by the front end, which contains the UKEY serial number, the current local timestamp, the historical back-end timestamp and the signature value. This information provides the necessary data basis for subsequent verification. The signature verification module verifies the verification request and verifies the continuity of the current local timestamp and the consistency of the historical timestamp. This process utilizes the characteristics of the UKEY hardware signature to prevent forged requests and replay attacks, and ensures the authenticity and validity of the verification request. After the verification is passed, the verification module resets the loop counter, generates a new timestamp and returns it to the front end, updates the timestamp record of the front end, and thus maintains the legitimacy of the session. If the verification fails or the verification request is not received, the loop counter accumulates until it reaches the preset threshold, triggering the service blocking mechanism to terminate the current session, effectively preventing illegal cross-terminal use and misjudgment caused by tampering of the front-end web page. This collaborative authentication mechanism not only improves the security of the system, but also ensures the correct use of UKEY and accurate monitoring of the connection status, significantly improving the security and reliability of the system. At the same time, it is compatible with scenarios where legitimate users change terminals, optimizing the user experience.

[0042] As a preferred embodiment, the signature verification module includes an extraction unit, a signature verification unit and a judgment unit;

[0043] The extraction unit is used to extract the UKEY serial number, the current local timestamp, the historical backend timestamp and the signature value from the verification request;

[0044] The signature verification unit is configured to query the corresponding UKEY public key according to the extracted UKEY serial number and verify the extracted signature value using the UKEY public key;

[0045] The judgment unit is configured to calculate the difference between the current local timestamp and the last recorded local timestamp if the signature verification passes, and determine whether the difference is within a preset time interval;

[0046] If the difference is within a preset time interval, it is determined whether the extracted historical backend timestamp is consistent with the backend timestamp last sent to the frontend.

[0047] In this preferred embodiment, by refining the functionality of the signature verification module, the verification process for authentication requests is further enhanced, thereby improving the security and reliability of the system. Specifically, the extraction unit accurately extracts the UKEY serial number, current local timestamp, historical backend timestamp, and signature value from the authentication request, ensuring that all key information is included in the subsequent authentication process. The signature verification unit uses the UKEY serial number to query the corresponding public key and uses this public key to verify the signature value. This process utilizes asymmetric encryption technology to ensure the integrity and unforgeability of the authentication request, as only requests signed with the correct private key can pass public key signature verification. After the signature verification passes, the judgment unit calculates the difference between the current local timestamp and the last recorded local timestamp and determines whether the difference is within a preset time interval. This operation effectively prevents replay attacks, as any request outside a reasonable time range will be identified as illegal. Furthermore, the judgment unit compares the extracted historical backend timestamp with the last backend timestamp sent to the frontend, ensuring the consistency of the frontend and backend timestamps, thereby verifying the continued connection status of the UKEY. Through this multi-step verification mechanism, the present invention not only improves the security of the system, but also ensures the correct use of UKEY and accurate monitoring of the connection status, effectively preventing misjudgments caused by illegal cross-terminal use and tampering of front-end web pages, and significantly improving the security and reliability of the system.

[0048] As a preferred embodiment, if the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically:

[0049] If the verification fails or the verification request is not received, the value of the cycle counter is incremented at a preset period;

[0050] If the value of the loop counter reaches a preset threshold, canceling the current session token and blocking the network connection associated with the session;

[0051] Send a session termination notification to the front end and reject all subsequent business requests.

[0052] In this preferred embodiment, the present application effectively prevents the illegal use and abuse of UKEY by incrementing the value of a loop counter at a preset period when a verification request fails or no verification request is received. When the counter value reaches a preset threshold, a service blocking mechanism is triggered to terminate the current session. Specifically, when verification fails or no verification request is received, the system increments the value of the loop counter at a preset period. This process ensures that the system can continuously monitor the connection status of UKEY, avoiding misjudgments caused by occasional verification failures or network delays. Once the loop counter value reaches the preset threshold, the system will cancel the current session token and block the network connection associated with the session. This measure effectively prevents the possibility of UKEY being illegally unplugged and misused on other terminals. At the same time, the system sends a session termination notification to the front end and rejects all subsequent service requests. This not only promptly notifies the user that the session has been terminated, but also further enhances the security of the system and prevents the continuation of illegal operations. Through this mechanism, the present invention ensures accurate monitoring of the UKEY connection status while effectively preventing misjudgments caused by illegal cross-terminal use and tampering of the front-end web page, significantly improving the security and reliability of the system.

[0053] In a third aspect, the present application provides a computer-readable storage medium, the computer-readable storage medium including a stored computer program. When the computer program is executed, the computer-readable storage medium controls the device containing the computer-readable storage medium to execute the method for status detection based on front-end and back-end collaborative authentication described above. This method has the same beneficial effects as the method for status detection based on front-end and back-end collaborative authentication provided in the first aspect of the present application.

[0054] In a fourth aspect, the present application provides a terminal device comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements any one of the status detection methods based on front-end and back-end collaborative authentication as described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 : A flow chart of an embodiment of a status detection method based on front-end and back-end collaborative authentication provided by this application;

[0056] Figure 2 : A flow chart of an embodiment of a status detection device based on front-end and back-end collaborative authentication provided by this application. DETAILED DESCRIPTION

[0057] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0058] Example 1

[0059] Please refer to Figure 1 In order to solve the problem that the existing technology cannot accurately detect and verify the connection status of UKEY, an embodiment of the present invention provides a status detection method based on front-end and back-end collaborative authentication.

[0060] In this embodiment, the process of the status detection method based on front-end and back-end collaborative authentication in this application is described in detail through steps S01-S04.

[0061] This application uses UKEY management, user authentication and dynamic verification engine to complete UKEY status detection.

[0062] UKEY management: used to initialize UKEY to generate public and private key pairs, and manage UKEY serial numbers and public keys;

[0063] More specifically, the initialization of UKEY to generate a public-private key pair is that the background system generates UK EY for the manufacturer, calls the UKEY built-in SM2 algorithm to generate a public-private key pair, the private key is stored in the UKEY security chip, and the public key is uploaded to the server database; the UKEY serial number (such as SN: XXXXXXXX) is bound one-to-one with the manufacturer's user account (such as user@vendor) to form a UKEY-account mapping table.

[0064] User authentication: Bind the UKEY serial number to the user account and use asymmetric encryption technology to complete identity authentication;

[0065] Dynamic Verification Engine: Contains a front-end timing task trigger unit and a back-end cycle counter control unit to implement real-time status monitoring of the UKEY physical connection.

[0066] S01: Receive the verification request submitted by the front end, which includes the UKEY serial number, current local timestamp, historical backend timestamp and signature value.

[0067] Specifically, after a user successfully logs in, the front-end webpage sets a time interval and starts a scheduled task. In the scheduled task, the front-end repeatedly completes the following actions: the front-end obtains the UKEY serial number, the terminal timestamp, adds the timestamp returned by the back-end's last response, signs with the local UKEY, and sends all the information and signature to the back-end;

[0068] More specifically, the front-end starts a scheduled task (the default interval is 10 seconds) after the user successfully logs in, and calls the UKEY interface to obtain the current UKEY serial number (for example, SN: XXXXXXXX);

[0069] Collect the local terminal timestamp (such as TS_local = 20240520143000) and the historical backend timestamp last received from the backend (such as TS_server_prev = 20240520142950);

[0070] Combine the UKEY serial number, TS_local, and TS_server_prev into the data to be signed, and use the UKEY private key to generate a signature value (e.g., Sig_V=XXXXX) based on the SM2 algorithm;

[0071] The verification request is encapsulated as V_Req = {SN, TS_local, TS_server_prev, Sig_V} through the HTTPS protocol and submitted to the back-end verification interface.

[0072] More specifically, the user login process is described as follows:

[0073] The user accesses the web page, inserts the UKEY, enters the user account (such as user@vendor) and password; the front-end calls the UKEY interface to read the serial number, uses SM3 to calculate the hash value of the password, and reads the terminal serial number (for example, using the command wmic biosget serialnumber), generates a timestamp (such as TS = 20240520143000), uses the UKEY private key to perform SM2 signature on (UKEY serial number + terminal serial number + timestamp + user account + password hash value), and submits (UKEY serial number + terminal serial number + timestamp + user account + password hash value + signature value) to the backend; the backend queries the SM2 public key through the UKEY serial number, verifies the validity of the signature, compares the timestamp with the server time deviation (threshold ≤ 30 seconds), searches and compares the password hash value according to the user account, and returns the front-end login session token (Token) and the back-end server timestamp (TS_server_prev) after all three pass. The backend records the login terminal information, network connection information and login status, starts a loop counter (Counter), counts once every 1 second by default, and determines whether the count is greater than or equal to the threshold (for example, 300). If it is greater than or equal to, the request sent by the terminal using this Token will be rejected.

[0074] This application implements high-security monitoring and management of the UKEY connection status by receiving verification requests submitted by the front end. Specifically, the front end starts a scheduled task (the default interval is 10 seconds) after the user successfully logs in, calls the UKEY interface to obtain the current UKEY serial number, and collects the local terminal timestamp and the historical backend timestamp last received from the back end. The front end combines this information into data to be signed, uses the UKEY private key to generate a signature value based on the SM2 algorithm, and encapsulates the verification request as V_Req = {SN, TS_local, TS_server_prev, Sig_V} through the HTTPS protocol and submits it to the back-end verification interface. This process not only ensures the integrity and non-forgeability of the verification request, but also prevents replay attacks and misjudgments caused by tampering of the front-end web page through timestamp verification. In addition, the user login process is described in detail, further enhancing the security and reliability of the system. The user accesses the web page, inserts the UKEY, and enters the user account and password. The front end calls the UKEY interface to read the serial number, calculates the hash value of the password using SM3, reads the terminal serial number, generates a timestamp, and uses the UKEY private key to perform SM2 signature on this information. The backend queries the SM2 public key through the UKEY serial number, verifies the validity of the signature, compares the timestamp with the server time deviation (threshold ≤ 30 seconds), and searches and compares the password hash value according to the user account. After all three are passed, the backend returns the front-end login session token (Token) and the back-end server timestamp (TS_server_prev), and starts a loop counter (Counter), which counts once every 1 second by default. When the value of the counter is greater than or equal to the threshold (for example, 300), requests from terminals using this Token will be rejected. This mechanism effectively prevents illegal cross-terminal use, while being compatible with scenarios where legitimate users change terminals, significantly improving the security and reliability of the system.

[0075] S02: Verify the signature of the verification request and check the continuity of the current local timestamp and the consistency of the historical timestamps.

[0076] Specifically, the steps of the signature verification operation are as follows:

[0077] The backend extracts the UKEY serial number from V_Req and queries the database to obtain the corresponding SM2 public key;

[0078] Use the public key to verify the signature value Sig_V. If the verification fails, the counter will be directly triggered.

[0079] Local timestamp continuity check:

[0080] Calculate the difference between the current TS_local and the last recorded TS_local. If the difference exceeds the preset range (e.g., 10 seconds ± Δ, Δ = 5 seconds), it is determined to be a timestamp anomaly.

[0081] Historical backend timestamp consistency check:

[0082] Compare the TS_server_prev in this V_Req with the timestamp of the last time it was returned to the front-end from the back-end storage. If they are inconsistent, it is determined to be an illegal request.

[0083] This application significantly improves the security and reliability of the system by verifying the signature and timestamp of the verification request. Specifically, the backend extracts the UKEY serial number from the verification request and queries the corresponding SM2 public key, and uses the public key to verify the signature value. If the signature verification fails, the counter accumulation is directly triggered. This step effectively prevents the passage of forged requests. Next, the backend performs a continuity check on the local timestamp, calculates the difference between the current TS_local and the last recorded TS_local, and if the difference exceeds the preset interval (for example, 10 seconds ± 5 seconds), it is determined to be a timestamp anomaly. This step effectively prevents replay attacks. Finally, the backend performs a consistency check on the historical backend timestamp, compares the TS_server_prev in this request with the timestamp last returned to the front end stored in the backend, and if they are inconsistent, it is determined to be an illegal request. This step effectively prevents the front end from tampering with or forging historical timestamps. Through these rigorous verification steps, the system can accurately identify legitimate requests and illegal requests, ensure that the connection status of UKEY is accurately monitored, effectively prevent UKEY from being illegally used across terminals, and is compatible with scenarios where legitimate users change terminals, significantly improving the security and reliability of the system.

[0084] S03: If the verification passes, reset the preset cycle counter associated with the current session, and generate a new timestamp and return it to the front end.

[0085] As a preferred embodiment, if the verification passes, the preset cycle counter associated with the current session is reset, and a new timestamp is generated and returned to the front end, specifically:

[0086] If all checks pass, the loop counter associated with the current session (initial value is 0, threshold N = 300) is reset to zero;

[0087] Generate a new backend timestamp TS_server_new (for example, 20240520143010) and return it to the frontend to update the historical timestamp record on the frontend.

[0088] The frontend carries TS_server_new as the new historical backend timestamp in the next cycle verification request.

[0089] This application achieves continuous monitoring and updating of the UKEY connection status by resetting the cycle counter associated with the current session after the verification request is verified and generating a new timestamp and returning it to the front end. Specifically, when all verifications are passed, the back end resets the cycle counter associated with the current session to zero. This operation ensures that the system's monitoring of the UKEY connection status will not be misjudged due to the accumulation of the counter, thereby avoiding the interruption of the session of legitimate users due to counter overflow. At the same time, the back end generates a new back end timestamp TS_server_new based on the server time and sends it to the front end to update the historical back end timestamp record of the front end. The front end carries the new historical back end timestamp TS_server_new in the verification request of the next cycle. This process not only ensures the consistency of the front and back end timestamps, but also provides an accurate time reference for the next verification request. Through this mechanism, the system can continuously and accurately monitor the connection status of UKEY, effectively prevent UKEY from being illegally unplugged and abused on other terminals, and is compatible with scenarios where legitimate users change different terminals to use UKEY, thereby improving the security of the system and user experience.

[0090] S04: If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session.

[0091] As a preferred embodiment, if the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically:

[0092] 1. Counter accumulation rules:

[0093] If the signature verification fails, the timestamp verification is abnormal, or the verification request is not received within a timeout period, the backend will increment the loop counter at 1-second intervals.

[0094] 2. Blocking mechanism triggering:

[0095] When the counter cumulative value reaches the threshold value N=300 (i.e., no verification within 5 minutes), the backend forcibly cancels the current session token and blocks the relevant network connection;

[0096] Return a session termination notification to the front end (such as an HTTP 403 status code and the prompt message "Session Expired") and reject all subsequent business requests.

[0097] As a preferred embodiment, the present application also includes three protection measures to protect state detection:

[0098] 1. Front-end tampering protection: If an attacker tampers with the front-end code to disable scheduled tasks, the back-end will trigger a blocking mechanism because it has not received a verification request for 300 consecutive seconds;

[0099] That is, if an attacker tampers with the front-end code to disable the scheduled task, the back-end will trigger Counter≥N because it has not received verification requests for N consecutive times. The system will automatically log out the session and invalidate the Token.

[0100] 2. Replay attack protection: TS_local and TS_server_prev in each verification request are dynamic values. The backend intercepts repeated requests through timestamp continuity detection.

[0101] That is, TS_local and TS_server_prev are dynamic values in each verification request, and attackers cannot reuse old signature data. The backend blocks replay behavior through timestamp continuity detection.

[0102] 3. Forged signature protection: The front-end cannot obtain the UKEY private key, the forged signature cannot pass the back-end signature verification, and the counter accumulates and triggers a block;

[0103] That is, the front-end cannot simulate the physical security chip function of UKEY, and the forged signature cannot pass the back-end SM2 verification due to the lack of a legitimate private key, triggering the counter accumulation mechanism.

[0104] This application effectively prevents illegal operations and abuse by accumulating a loop counter until it reaches a preset threshold when the verification request fails or no verification request is received, triggering a service blocking mechanism to terminate the current session. Specifically, the backend increments the loop counter at intervals of 1 second when the signature verification fails, the timestamp verification is abnormal, or the verification request is not received due to timeout. When the cumulative value of the counter reaches the threshold value N=300 (i.e., it fails to pass the verification within 5 minutes), the backend forcibly cancels the current session token (Token), blocks the relevant network connection, and returns a session termination notification to the front end (such as HTTP 403 status code and the prompt message "Session has expired"), rejecting all subsequent service requests. This mechanism ensures that the system can detect and block illegal operations in a timely manner, preventing UKEY from being illegally used across terminals. In addition, this application also includes three protection measures: front-end tampering protection, replay attack protection, and forged signature protection. Front-end tamper protection triggers a blocking mechanism by failing to receive consecutive verification requests, preventing attackers from tampering with the front-end code and disabling scheduled tasks. Replay attack protection intercepts repeated requests through timestamp continuity detection, preventing attackers from reusing old signature data. Forged signature protection ensures the validity of signatures through back-end signature verification, preventing illegal signatures from passing verification. These protective measures further enhance system security, ensure the correct use of UKEY and accurate monitoring of connection status, and significantly improve system security and reliability.

[0105] Example 2

[0106] Please refer to Figure 2 , which is a status detection device based on front-end and back-end collaborative authentication provided in an embodiment of the present application.

[0107] In this embodiment, the status detection device based on front-end and back-end collaborative authentication includes a receiving module 10 , a signature verification module 20 and a verification module 30 .

[0108] This application uses UKEY management, user authentication and dynamic verification engine to complete UKEY status detection.

[0109] UKEY management: used to initialize UKEY to generate public and private key pairs, and manage UKEY serial numbers and public keys;

[0110] More specifically, the initialization of UKEY to generate a public-private key pair is that the background system generates UK EY for the manufacturer, calls the UKEY built-in SM2 algorithm to generate a public-private key pair, the private key is stored in the UKEY security chip, and the public key is uploaded to the server database; the UKEY serial number (such as SN: XXXXXXXX) is bound one-to-one with the manufacturer's user account (such as user@vendor) to form a UKEY-account mapping table.

[0111] User authentication: Bind the UKEY serial number to the user account and use asymmetric encryption technology to complete identity authentication;

[0112] Dynamic Verification Engine: Contains a front-end timing task trigger unit and a back-end cycle counter control unit to implement real-time status monitoring of the UKEY physical connection.

[0113] The receiving module 10 is used to receive the verification request submitted by the front end, and the verification request includes the UKEY serial number, the current local timestamp, the historical backend timestamp and the signature value.

[0114] Specifically, after a user successfully logs in, the front-end webpage sets a time interval and starts a scheduled task. In the scheduled task, the front-end repeatedly completes the following actions: the front-end obtains the UKEY serial number, the terminal timestamp, adds the timestamp returned by the back-end's last response, signs with the local UKEY, and sends all the information and signature to the back-end;

[0115] More specifically, the front-end starts a scheduled task (the default interval is 10 seconds) after the user successfully logs in, and calls the UKEY interface to obtain the current UKEY serial number (for example, SN: XXXXXXXX);

[0116] Collect the local terminal timestamp (such as TS_local = 20240520143000) and the historical backend timestamp last received from the backend (such as TS_server_prev = 20240520142950);

[0117] Combine the UKEY serial number, TS_local, and TS_server_prev into the data to be signed, and use the UKEY private key to generate a signature value (e.g., Sig_V=XXXXX) based on the SM2 algorithm;

[0118] The verification request is encapsulated as V_Req = {SN, TS_local, TS_server_prev, Sig_V} through the HTTPS protocol and submitted to the back-end verification interface.

[0119] More specifically, the user login process is described as follows:

[0120] The user accesses the web page, inserts the UKEY, enters the user account (such as user@vendor) and password; the front-end calls the UKEY interface to read the serial number, uses SM3 to calculate the hash value of the password, and reads the terminal serial number (for example, using the command wmic biosget serialnumber), generates a timestamp (such as TS = 20240520143000), uses the UKEY private key to perform SM2 signature on (UKEY serial number + terminal serial number + timestamp + user account + password hash value), and submits (UKEY serial number + terminal serial number + timestamp + user account + password hash value + signature value) to the backend; the backend queries the SM2 public key through the UKEY serial number, verifies the validity of the signature, compares the timestamp with the server time deviation (threshold ≤ 30 seconds), searches and compares the password hash value according to the user account, and returns the front-end login session token (Token) and the back-end server timestamp (TS_server_prev) after all three pass. The backend records the login terminal information, network connection information and login status, starts a loop counter (Counter), counts once every 1 second by default, and determines whether the count is greater than or equal to the threshold (for example, 300). If it is greater than or equal to, the request sent by the terminal using this Token will be rejected.

[0121] This application implements high-security monitoring and management of the UKEY connection status by receiving verification requests submitted by the front end. Specifically, the front end starts a scheduled task (the default interval is 10 seconds) after the user successfully logs in, calls the UKEY interface to obtain the current UKEY serial number, and collects the local terminal timestamp and the historical backend timestamp last received from the back end. The front end combines this information into data to be signed, uses the UKEY private key to generate a signature value based on the SM2 algorithm, and encapsulates the verification request as V_Req = {SN, TS_local, TS_server_prev, Sig_V} through the HTTPS protocol and submits it to the back-end verification interface. This process not only ensures the integrity and non-forgeability of the verification request, but also prevents replay attacks and misjudgments caused by tampering of the front-end web page through timestamp verification. In addition, the user login process is described in detail, further enhancing the security and reliability of the system. The user accesses the web page, inserts the UKEY, and enters the user account and password. The front end calls the UKEY interface to read the serial number, calculates the hash value of the password using SM3, reads the terminal serial number, generates a timestamp, and uses the UKEY private key to perform SM2 signature on this information. The backend queries the SM2 public key through the UKEY serial number, verifies the validity of the signature, compares the timestamp with the server time deviation (threshold ≤ 30 seconds), and searches and compares the password hash value according to the user account. After all three are passed, the backend returns the front-end login session token (Token) and the back-end server timestamp (TS_server_prev), and starts a loop counter (Counter), which counts once every 1 second by default. When the value of the counter is greater than or equal to the threshold (for example, 300), requests from terminals using this Token will be rejected. This mechanism effectively prevents illegal cross-terminal use, while being compatible with scenarios where legitimate users change terminals, significantly improving the security and reliability of the system.

[0122] The signature verification module 20 is used to verify the signature of the verification request and check the continuity of the current local timestamp and the consistency of historical timestamps.

[0123] Specifically, the steps of the signature verification operation are as follows:

[0124] The backend extracts the UKEY serial number from V_Req and queries the database to obtain the corresponding SM2 public key;

[0125] Use the public key to verify the signature value Sig_V. If the verification fails, the counter will be directly triggered.

[0126] Local timestamp continuity check:

[0127] Calculate the difference between the current TS_local and the last recorded TS_local. If the difference exceeds the preset range (e.g., 10 seconds ± Δ, Δ = 5 seconds), it is determined to be a timestamp anomaly.

[0128] Historical backend timestamp consistency check:

[0129] Compare the TS_server_prev in this V_Req with the timestamp of the last time it was returned to the front-end from the back-end storage. If they are inconsistent, it is determined to be an illegal request.

[0130] This application significantly improves the security and reliability of the system by verifying the signature and timestamp of the verification request. Specifically, the backend extracts the UKEY serial number from the verification request and queries the corresponding SM2 public key, and uses the public key to verify the signature value. If the signature verification fails, the counter accumulation is directly triggered. This step effectively prevents the passage of forged requests. Next, the backend performs a continuity check on the local timestamp, calculates the difference between the current TS_local and the last recorded TS_local, and if the difference exceeds the preset interval (for example, 10 seconds ± 5 seconds), it is determined to be a timestamp anomaly. This step effectively prevents replay attacks. Finally, the backend performs a consistency check on the historical backend timestamp, compares the TS_server_prev in this request with the timestamp last returned to the front end stored in the backend, and if they are inconsistent, it is determined to be an illegal request. This step effectively prevents the front end from tampering with or forging historical timestamps. Through these rigorous verification steps, the system can accurately identify legitimate requests and illegal requests, ensure that the connection status of UKEY is accurately monitored, effectively prevent UKEY from being illegally used across terminals, and is compatible with scenarios where legitimate users change terminals, significantly improving the security and reliability of the system.

[0131] The verification module 30 is used to reset a preset cycle counter associated with the current session if the verification passes, and generate a new timestamp and return it to the front end.

[0132] As a preferred embodiment, if the verification passes, the preset cycle counter associated with the current session is reset, and a new timestamp is generated and returned to the front end, specifically:

[0133] If all checks pass, the loop counter associated with the current session (initial value is 0, threshold N = 300) is reset to zero;

[0134] Generate a new backend timestamp TS_server_new (for example, 20240520143010) and return it to the frontend to update the historical timestamp record on the frontend.

[0135] The frontend carries TS_server_new as the new historical backend timestamp in the next cycle verification request.

[0136] This application achieves continuous monitoring and updating of the UKEY connection status by resetting the cycle counter associated with the current session after the verification request is verified and generating a new timestamp and returning it to the front end. Specifically, when all verifications are passed, the back end resets the cycle counter associated with the current session to zero. This operation ensures that the system's monitoring of the UKEY connection status will not be misjudged due to the accumulation of the counter, thereby avoiding the interruption of the session of legitimate users due to counter overflow. At the same time, the back end generates a new back end timestamp TS_server_new based on the server time and sends it to the front end to update the historical back end timestamp record of the front end. The front end carries the new historical back end timestamp TS_server_new in the verification request of the next cycle. This process not only ensures the consistency of the front and back end timestamps, but also provides an accurate time reference for the next verification request. Through this mechanism, the system can continuously and accurately monitor the connection status of UKEY, effectively prevent UKEY from being illegally unplugged and abused on other terminals, and is compatible with scenarios where legitimate users change different terminals to use UKEY, thereby improving the security of the system and user experience.

[0137] The verification module 30 is further configured to: if the verification fails or no verification request is received, accumulate the cycle counter until a preset threshold is reached, and trigger a service blocking mechanism to terminate the current session.

[0138] As a preferred embodiment, if the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically:

[0139] 1. Counter accumulation rules:

[0140] If the signature verification fails, the timestamp verification is abnormal, or the verification request is not received within a timeout period, the backend will increment the loop counter at 1-second intervals.

[0141] 2. Blocking mechanism triggering:

[0142] When the counter cumulative value reaches the threshold value N=300 (i.e., no verification within 5 minutes), the backend forcibly cancels the current session token and blocks the relevant network connection;

[0143] Return a session termination notification to the front end (such as an HTTP 403 status code and the prompt message "Session Expired") and reject all subsequent business requests.

[0144] As a preferred embodiment, the present application also includes three protection measures to protect state detection:

[0145] 1. Front-end tampering protection: If an attacker tampers with the front-end code to disable scheduled tasks, the back-end will trigger a blocking mechanism because it has not received a verification request for 300 consecutive seconds;

[0146] That is, if an attacker tampers with the front-end code to disable the scheduled task, the back-end will trigger Counter≥N because it has not received verification requests for N consecutive times. The system will automatically log out the session and invalidate the Token.

[0147] 2. Replay attack protection: TS_local and TS_server_prev in each verification request are dynamic values. The backend intercepts repeated requests through timestamp continuity detection.

[0148] That is, TS_local and TS_server_prev are dynamic values in each verification request, and attackers cannot reuse old signature data. The backend blocks replay behavior through timestamp continuity detection.

[0149] 3. Forged signature protection: The front-end cannot obtain the UKEY private key, the forged signature cannot pass the back-end signature verification, and the counter accumulates and triggers a block;

[0150] That is, the front-end cannot simulate the physical security chip function of UKEY, and the forged signature cannot pass the back-end SM2 verification due to the lack of a legitimate private key, triggering the counter accumulation mechanism.

[0151] This application effectively prevents illegal operations and abuse by accumulating a loop counter until a preset threshold is reached when the verification request fails or no verification request is received, triggering a service blocking mechanism to terminate the current session. Specifically, the backend increments the loop counter at intervals of 1 second when the signature verification fails, the timestamp verification is abnormal, or the verification request is not received due to timeout. When the cumulative value of the counter reaches the threshold value N=300 (i.e., it fails to pass the verification within 5 minutes), the backend forcibly cancels the current session token (Token), blocks the relevant network connection, and returns a session termination notification to the front end (such as an HTTP 403 status code and the prompt message "Session has expired"), rejecting all subsequent service requests. This mechanism ensures that the system can detect and block illegal operations in a timely manner, preventing UKEY from being illegally used across terminals. In addition, the present invention also includes three protection measures: front-end tampering protection, replay attack protection, and forged signature protection. Front-end tamper protection triggers a blocking mechanism by failing to receive consecutive verification requests, preventing attackers from tampering with the front-end code and disabling scheduled tasks. Replay attack protection intercepts repeated requests through timestamp continuity detection, preventing attackers from reusing old signature data. Forged signature protection ensures the validity of signatures through back-end signature verification, preventing illegal signatures from passing verification. These protective measures further enhance system security, ensure the correct use of UKEY and accurate monitoring of connection status, and significantly improve system security and reliability.

[0152] Example 3:

[0153] An embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the state detection method based on front-end and back-end collaborative authentication;

[0154] Wherein, the state detection method based on front-end and back-end collaborative authentication, if implemented in the form of a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Wherein, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device that can carry the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0155] Example 4

[0156] The present application provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements any one of the status detection methods based on front-end and back-end collaborative authentication as described in Example 1.

[0157] The specific embodiments described above further illustrate the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that 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 for those skilled in the art.

Claims

1. A state detection method based on front-end and back-end collaborative authentication, characterized in that: include: Receive the verification request submitted by the front-end, which includes the UKEY serial number, current local timestamp, historical back-end timestamp and signature value; Verify the signature of the verification request and check the continuity of the current local timestamp and the consistency of historical timestamps; If the verification passes, reset the preset loop counter associated with the current session and generate a new timestamp and return it to the front end; If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session.

2. The state detection method based on front-end and back-end collaborative authentication according to claim 1 is characterized in that: The verification request is signed and the continuity of the current local timestamp and the consistency of the historical timestamp are verified, specifically: Extract the UKEY serial number, current local timestamp, historical backend timestamp and signature value from the verification request; After querying the corresponding UKEY public key based on the extracted UKEY serial number, the extracted signature value is verified using the UKEY public key; If the signature verification passes, calculate the difference between the current local timestamp and the last recorded local timestamp, and determine whether the difference is within the preset time interval; If the difference is within a preset time interval, it is determined whether the extracted historical backend timestamp is consistent with the backend timestamp last sent to the frontend.

3. The state detection method based on front-end and back-end collaborative authentication according to claim 1 is characterized in that: If the verification passes, the loop counter associated with the current session is reset, and a new timestamp is generated and returned to the front end, specifically: If the verification passes, the value of the loop counter is reset to zero, and a new backend timestamp is generated based on the server time; The new backend timestamp is sent to the frontend to update the historical backend timestamp record of the frontend.

4. The state detection method based on front-end and back-end collaborative authentication according to claim 1 is characterized in that: If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically: If the verification fails or the verification request is not received, the value of the cycle counter is incremented at a preset period; If the value of the loop counter reaches a preset threshold, canceling the current session token and blocking the network connection associated with the session; Send a session termination notification to the front end and reject all subsequent business requests.

5. The state detection method based on front-end and back-end collaborative authentication according to claim 1 is characterized in that: Before receiving the verification request submitted by the front end, specifically: The front-end verification request is based on the user successfully logging in, starting a scheduled task so that the front-end obtains the current local timestamp and reads the historical back-end timestamp last received from the back-end; Combine the UKEY serial number, the current local timestamp and the historical backend timestamp into the data to be signed; Sign the data to be signed using the UKEY private key to generate a signature value; The UKEY serial number, current local timestamp, historical backend timestamp and signature value are encapsulated.

6. A status detection device based on front-end and back-end collaborative authentication, characterized in that: Includes receiving module, signature verification module and verification module; The receiving module is used to receive a verification request submitted by the front end, wherein the verification request includes a UKEY serial number, a current local timestamp, a historical backend timestamp, and a signature value; The signature verification module is used to verify the signature of the verification request and verify the continuity of the current local timestamp and the consistency of historical timestamps; The verification module resets the preset cycle counter associated with the current session if the verification passes, and generates a new timestamp and returns it to the front end; If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session.

7. The state detection device based on front-end and back-end collaborative authentication according to claim 6 is characterized in that: The signature verification module includes an extraction unit, a signature verification unit and a judgment unit; The extraction unit is used to extract the UKEY serial number, the current local timestamp, the historical backend timestamp and the signature value from the verification request; The signature verification unit is configured to query the corresponding UKEY public key according to the extracted UKEY serial number and verify the extracted signature value using the UKEY public key; The judgment unit is configured to calculate the difference between the current local timestamp and the last recorded local timestamp if the signature verification passes, and determine whether the difference is within a preset time interval; If the difference is within a preset time interval, it is determined whether the extracted historical backend timestamp is consistent with the backend timestamp last sent to the frontend.

8. The state detection device based on front-end and back-end collaborative authentication according to claim 6 is characterized in that: If the verification fails or the verification request is not received, the cycle counter is accumulated until a preset threshold is reached, triggering a service blocking mechanism to terminate the current session, specifically: If the verification fails or the verification request is not received, the value of the cycle counter is incremented at a preset period; If the value of the loop counter reaches a preset threshold, canceling the current session token and blocking the network connection associated with the session; Send a session termination notification to the front end and reject all subsequent business requests.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the status detection method based on front-end and back-end collaborative authentication according to any one of claims 1 to 5.

10. A terminal device, characterized in that: It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the status detection method based on front-end and back-end collaborative authentication as described in any one of claims 1 to 5.

Images