Equipment authority information processing method, electronic equipment and computer readable storage medium

Abstract

The invention provides an equipment permission information processing method, electronic equipment and a computer readable storage medium, and relates to the technical field of network security and communication. The method comprises the steps that a client side detects whether communication connection between the client side and a server side is disconnected or not, if yes, a communication reconnection request is sent to the server side according to a back-off reconnection strategy, and the communication reconnection request comprises a first authorization information ciphertext and a client side machine code; the first authorization information ciphertext is obtained by encrypting an authorization token generated when the client side authorizes the server side for the first time, the server side receives the communication reconnection request, decrypts the first authorization information ciphertext based on a client side machine code to obtain a first authorization information plaintext, verifies the first authorization information plaintext, and sends the first authorization information plaintext to the client side; and after the verification is passed, the permission of the client is recovered. According to the method and the device, non-inductive, automatic and safe permission inheritance is realized, the manual authentication overhead of repeatedly inputting the control code in a frequent network disconnection scene is avoided, and the problem of low reconnection efficiency is effectively solved.

Description

Technical Field

[0001] This application relates to the fields of network security and communication technology, and more specifically, to a method for processing device access information, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In the field of network security and cryptographic services, clients typically interact with the server's cryptographic machine via a Socket connection to perform permission-sensitive operations such as private key signing and decryption. To ensure operational security, an authorization interface must be called before any operation can be performed, submitting a private key access control code for authentication. After successful authentication, the server maintains the permission state of the Socket connection in memory, granting the client the corresponding operational permissions.

[0003] However, when a link failure, network interruption, or server cryptographic machine hardware failure occurs, the Socket connection will be forcibly disconnected. Although the client can re-establish the connection after detecting the disconnection, the client cannot inherit the original permissions and needs to manually re-authenticate to restore permissions. This results in very low reconnection efficiency in environments with frequent network outages or high availability requirements. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of the prior art by providing a device permission information processing method, an electronic device, and a computer-readable storage medium, so as to solve the problem of very low reconnection efficiency in environments with frequent network outages or high availability requirements.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a method for processing device permission information, applied to a server, the method comprising: The system receives a communication reconnection request sent by the client. The communication reconnection request includes a first authorization information ciphertext and a client machine code. The first authorization information ciphertext is obtained by the client encrypting the authorization token generated by the server during the initial authorization. The first authorization information ciphertext is decrypted based on the client machine code to obtain the first authorization information plaintext; The first authorization information in plaintext is verified, and the client permissions are restored after the verification is successful.

[0006] As one possible implementation, the step of decrypting the first authorization information ciphertext based on the client machine code to obtain the first authorization information plaintext includes: The first authorized information ciphertext is decrypted based on the client machine code to obtain the first ciphertext; The first ciphertext is decrypted using the server's device key to obtain the first authorization information plaintext.

[0007] As one possible implementation, the method further includes: Receive the private key access control code and the client machine code sent by the client; The private key access control code is verified, and after successful verification, the authorization token is generated based on the client machine code, and the validity period of the authorization token is set. The authorization token is encrypted using the server's device key to obtain the second authorization information ciphertext; The second authorization information ciphertext is bound to the client machine code and stored in a preset database, and the second authorization information ciphertext is sent to the client.

[0008] As one possible implementation, the step of verifying the plaintext of the first authorization information and restoring client permissions after successful verification includes: Based on the client machine code, the second authorization information ciphertext is obtained from the preset database, and the validity period of the authorization token is also obtained. The encrypted second authorization information is decrypted based on the server's device key to obtain the plaintext second authorization information; Verify whether the first authorization information plaintext is consistent with the second authorization information plaintext. If they are consistent and the authorization token is within its validity period, then the verification is successful and the client permissions are restored.

[0009] As one possible implementation, after verifying the private key access control code and generating the authorization token based on the client machine code upon successful verification, the method further includes: The authorization token is signed based on the device certificate to obtain signature information; The signature information and the authorization token are combined to obtain a new authorization token, which is then sent to the client so that the client can verify the authorization token.

[0010] Secondly, embodiments of this application provide a device permission information processing method, applied to a client, the method comprising: Detect whether the communication connection between the client and the server is broken; If so, a communication reconnection request is sent to the server according to the backoff reconnection strategy. The communication reconnection request includes a first authorization information ciphertext and a client machine code. The first authorization information ciphertext is obtained by the client encrypting the authorization token generated by the server during the first authorization, so that the server can decrypt the first authorization information ciphertext based on the client machine code to obtain the first authorization information plaintext. The first authorization information plaintext is used to restore the client's permissions after successful verification.

[0011] As one possible implementation, the method further includes: Receive the second authorized information ciphertext sent by the server, wherein the second authorized information ciphertext is obtained by the server encrypting the authorization token based on the server's device key; The second authorization information ciphertext is encrypted based on the client machine code to generate the first authorization information ciphertext.

[0012] As one possible implementation, sending a communication reconnection request to the server according to the backoff reconnection strategy includes: When the communication connection between the client and the server is detected to be broken, an initial communication reconnection request is sent to the server. If the first communication reconnection fails, the waiting time corresponding to the current communication reconnection is determined according to the current number of reconnections, and the waiting time increases with the increase of the number of reconnections; Wait for the specified waiting time, then resend the communication reconnection request to the server.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the device permission information processing method as described in either the first or second aspect above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the device permission information processing method as described in either the first or second aspect above.

[0015] In the device permission information processing method, electronic device, and computer-readable storage medium provided in this application embodiment, during the initial authorization, the server generates a unique authorization token and encrypts it to obtain second authorization information ciphertext. The client uses its local client machine code to encrypt the second authorization information ciphertext a second time to obtain first authorization information ciphertext and caches it securely. When the communication connection between the client and the server is interrupted due to network interruption or cryptographic machine failure, the client does not need user intervention. It only needs to send a communication reconnection request carrying the first authorization information ciphertext and the client machine code to the server. The server uses the client machine code and the server device key to double decrypt the first authorization information ciphertext, restore the first authorization information plaintext, and compare and verify it with the original authorization information stored in the server's preset database. At the same time, it verifies the validity period of the authorization token and automatically restores the client's permissions after successful verification. Since the whole process realizes seamless, automatic, and secure permission inheritance, it avoids the manual authentication overhead of repeatedly entering control codes in scenarios with frequent network outages. Therefore, this application embodiment effectively solves the problem of low reconnection efficiency caused by manual re-authentication after the Socket connection is broken in the prior art, and significantly improves the reconnection efficiency and user experience in a high-availability environment. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a device permission information processing method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating an authorization verification method provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating another device permission information processing method provided in an embodiment of this application is shown; Figure 4 An interactive schematic diagram of a device permission information processing method provided in an embodiment of this application is shown; Figure 5 A flowchart illustrating an authorization token verification method provided in an embodiment of this application is shown; Figure 6 A flowchart illustrating an authorization token generation method provided in an embodiment of this application is shown; Figure 7 A flowchart illustrating a method for generating encrypted first authorization information according to an embodiment of this application is shown. Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0019] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0021] Before providing a detailed explanation of the device permission information processing method provided in the embodiments of this application, the relevant terms involved in this application will be explained as follows: Token: An authorization token is a short-term digital credential generated by the server's cryptographic machine, used to automatically restore private key access permissions after the client and server reconnect.

[0022] Server cryptographic machine: A hardware security module specifically designed to perform highly secure cryptographic operations and provide access control functionality.

[0023] Client SDK: A software development kit integrated into the user application, which encapsulates the communication logic with the server cryptographic machine.

[0024] Socket connection: A network communication channel based on the TCP / IP protocol, used to establish a reliable two-way data exchange between the client SDK and the server cryptographic machine.

[0025] Private key access control code: A dynamic or static authentication code used to authorize private key operations in a socket connection.

[0026] Device key: The unique encryption key of the server's cryptographic machine, used for the cryptographic protection of the token.

[0027] Client machine code: A unique hardware or software identifier for the client, used to bind the token to ensure security.

[0028] Token persistence: The server stores token-related information on a non-volatile medium to ensure that the token can be recovered and its validity verified after the server crashes and restarts.

[0029] Backoff reconnection strategy: An intelligent network reconnection strategy in which, when a connection is abnormally dropped, the client attempts to reconnect with an exponentially increasing delay.

[0030] To address the problems existing in the prior art, this application provides a method for processing device permission information. A Socket connection is established between the client and the server. During the initial authorization, the server generates an authorization token (Token) and encrypts it using a device key before returning it to the client. The client then encrypts the Token again and stores it securely. If the connection is lost, the client initiates a backoff mode to reconnect. Upon successful reconnection, the client automatically restores permissions using the Token. Thus, the user does not need to intervene in the reauthorization process to achieve the technical effect of automatically restoring permissions after reconnection.

[0031] In this embodiment, the server is, for example, a server cryptographic machine, and the client is, for example, a client SDK. The server cryptographic machine, as the server, provides encryption operations and access control, and has persistent storage capabilities. The client SDK, as the client, is integrated into the user device, such as a PC or mobile terminal, and is responsible for communication management. Based on this, the device access control information processing method provided in this embodiment is applied to high-security server cryptographic machine and client SDK interaction environments, with typical scenarios including digital certificate signing and encrypted data transmission. The following provides a detailed description of the device access control information processing method provided in this embodiment.

[0032] Figure 1 This illustration shows a flowchart of a device permission information processing method provided in an embodiment of this application, applied to the aforementioned server. The method includes: S101, Receive a communication reconnection request sent by the client.

[0033] Optionally, when the client detects a disconnection in the communication connection with the server, it sends a communication reconnection request to the server. This reconnection request includes encrypted first authorization information and the client's machine code. The encrypted first authorization information is obtained by the client encrypting the authorization token generated by the server during the initial authorization. It's worth noting that the authorization token is generated by the server during the initial authorization, and the server has already encrypted it once before sending it to the client. After receiving the encrypted authorization token, when the client detects a disconnection in the communication connection and sends a communication reconnection request, the encrypted first authorization information in that reconnection request is obtained by encrypting the encrypted authorization token again; that is, the encrypted first authorization information is double-encrypted.

[0034] S102. Decrypt the first authorization information ciphertext based on the client machine code to obtain the first authorization information plaintext.

[0035] Optionally, since the first authorization information ciphertext is obtained through double encryption, the server employs a double decryption mechanism to restore the first authorization information plaintext. Specifically, the server first uses the client machine code bound to the client as a key to perform a first-level decryption of the first authorization information ciphertext submitted by the client, obtaining intermediate ciphertext. Then, the server uses its private device key to perform a second-level decryption of the intermediate ciphertext, ultimately restoring the original first authorization information plaintext. In this embodiment, the decryption process of the first authorization information ciphertext strictly relies on the client's identity identifier and the server's private credentials, ensuring that only legitimate devices with valid authorization can complete the full decryption, thereby guaranteeing the authenticity, confidentiality, and unforgeability of the token.

[0036] S103. Verify the plaintext of the first authorization information and restore the client's permissions after successful verification.

[0037] Optionally, the server retrieves the encrypted second authorization information bound to the client's machine code and the validity period of the authorization token from a preset database based on the client's machine code provided by the client. Then, it decrypts the encrypted second authorization information using the server's private device key to obtain the plaintext second authorization information. Further, the server compares this plaintext second authorization information with the plaintext first authorization information obtained through double decryption and verifies whether the current time is within the validity period of the authorization token. This determines whether the verification passes, and if the verification passes, the client's permissions are automatically restored. This ensures secure and seamless permission renewal while maintaining the authenticity, integrity, and timeliness of the token.

[0038] Based on this, after receiving a communication reconnection request from the client, the server uses the client's machine code and the server's device key to double-decrypt the encrypted first authorization information, restore the plaintext of the first authorization information, and compare and verify it with the original authorization information stored in the server's preset database. At the same time, the validity period of the authorization token is verified, and the client's permissions are automatically restored after the verification is successful, thus realizing seamless, automatic and secure permission inheritance.

[0039] As one possible implementation, step S102 above decrypts the first authorized information ciphertext based on the client machine code to obtain the first authorized information plaintext, including: decrypting the first authorized information ciphertext based on the client machine code to obtain the first ciphertext, and decrypting the first ciphertext based on the server's device key to obtain the first authorized information plaintext.

[0040] Optionally, embodiments of this application provide a dual decryption mechanism, relying on the client's machine code as a client identity identifier and the server's device key as a server-side private credential. Specifically, the server first uses the client's machine code bound to the client to decrypt the received first authorization information ciphertext TokenB, obtaining an intermediate ciphertext, namely the first ciphertext TokenA'. Then, the server uses its own device key to decrypt the first ciphertext TokenA' a second time, finally restoring the original first authorization information plaintext Token'.

[0041] Based on this, the embodiments of this application employ a dual decryption mechanism. The first layer of decryption relies on the client's machine code, ensuring that only ciphertext from legitimate devices can be initially parsed, preventing unauthorized devices from forging or replaying tokens. The second layer of decryption relies on the server's private device key, guaranteeing that even if an attacker obtains the client's machine code and the first layer of ciphertext, they cannot bypass the server's final verification. This significantly enhances the confidentiality and anti-cracking capabilities of authorization information, effectively avoiding man-in-the-middle attacks and token theft.

[0042] Figure 2 A schematic flowchart of an authorization verification method provided in an embodiment of this application is shown. (Refer to...) Figure 2 As shown, step S103 verifies the plaintext of the first authorization information and restores the client's permissions after successful verification. Specifically, it includes the following steps: S201. Obtain the second authorization information ciphertext from the preset database based on the client machine code, and obtain the validity period of the authorization token.

[0043] Optionally, after generating the second encrypted authorization information TokenA, the server binds TokenA to the client's machine code and stores it in a preset database. Based on this, when verifying the first plaintext authorization information Token', the server can retrieve the second encrypted authorization information TokenA bound to the client's machine code from the preset database. Furthermore, the server sets the validity period of the authorization token when generating it and stores this period in the preset database as well; therefore, the validity period of the authorization token can be retrieved from the preset database.

[0044] S202. Decrypt the encrypted second authorization information based on the server's device key to obtain the plaintext second authorization information.

[0045] Optionally, the server uses a private device key to decrypt the encrypted second authorization information TokenA obtained from a preset database. The device key is kept by the server to ensure that the original authorization information cannot be forged or tampered with externally. Upon successful decryption, the plaintext second authorization information TokenA'' can be obtained.

[0046] S203. Verify whether the plaintext of the first authorization information is consistent with the plaintext of the second authorization information. If they are consistent and the authorization token is within the validity period, then the verification is successful and the client permissions are restored.

[0047] Optionally, the server compares the first authorization information plaintext Token' with the second authorization information plaintext TokenA'' byte-by-byte to verify their consistency. If the first authorization information plaintext Token' and the second authorization information plaintext TokenA'' are completely identical, it indicates that the authorization token held by the client has not been tampered with. Simultaneously, the server checks whether the authorization token is within its validity period, i.e., whether the current time is earlier than the expiration time of the authorization token. If the first authorization information plaintext Token' and the second authorization information plaintext TokenA'' are completely identical, and the authorization token is within its validity period, the verification is successful, and the client's permissions, such as private key operation permissions, are automatically restored.

[0048] Based on this, this embodiment of the application accurately retrieves the original authorization record from a preset database using the client's machine code as an index, and decrypts and restores the token plaintext using the server's device key. This plaintext is then rigorously compared with the token plaintext currently submitted by the client, ensuring the authenticity and integrity of the authorization token. Simultaneously, the validity period of the authorization token is verified to prevent the abuse of expired tokens. Thus, this embodiment of the application not only effectively resists attacks such as token forgery, replay, tampering, and cross-device impersonation, but also avoids repeated user authentication, achieving seamless, automated, and user-unnoticed permission restoration while ensuring security.

[0049] Figure 3 This illustration shows a flowchart of another device permission information processing method provided in an embodiment of this application, applied to the aforementioned client. The method includes: S301. Detect whether the communication connection between the client and the server is broken.

[0050] Optionally, the client detects whether the communication connection with the server is broken by periodically sending heartbeat packets and waiting for the server's response. Specifically, if no valid response is received from the server within a preset heartbeat timeout threshold, or if the Socket connection triggers a connection closure event due to network anomalies, server crashes, or other reasons, the client can determine that the current communication link has been broken. Thus, this embodiment of the application uses heartbeat detection to determine whether the communication connection between the client and the server is broken, ensuring that connection failures can be detected in a timely and reliable manner in scenarios such as network interruptions, server restarts, or intermediate link failures, providing accurate triggering conditions for subsequent backoff and reconnection.

[0051] S302. If so, a communication reconnection request is sent to the server according to the backoff reconnection policy.

[0052] Optionally, the communication reconnection request includes encrypted first authorization information and client machine code. The encrypted first authorization information is obtained by encrypting the authorization token generated by the server during the initial authorization by the client, so that the server can decrypt the encrypted first authorization information based on the client machine code to obtain plaintext first authorization information. Plaintext first authorization information is used to restore client permissions after successful verification.

[0053] Optionally, when the client detects that the communication connection with the server has been lost through heartbeat detection, it immediately initiates an initial reconnection request. If the initial reconnection fails, it enters the backoff reconnection process. The client calculates the waiting time based on the current cumulative number of reconnections and adopts a preset backoff strategy. The client sleeps during this waiting time and then tries to connect again. The above process is repeated until a connection is successfully established or the preset maximum number of retries is reached, thereby achieving efficient automated reconnection.

[0054] Based on this, after the client detects a communication connection with the server, the client does not need user intervention. It only needs to send a communication reconnection request to the server carrying the encrypted first authorization information and the client's machine code. The server decrypts and verifies the encrypted first authorization information, and automatically restores the client's permissions after the verification is successful. This avoids the manual authentication overhead of repeatedly entering control codes in scenarios with frequent network outages, thereby significantly improving reconnection efficiency and user experience.

[0055] As one possible implementation, if step S302 is as described above, then a communication reconnection request is sent to the server according to the backoff reconnection strategy, including: when a communication connection between the client and the server is detected to be broken, the client sends an initial communication reconnection request to the server; if the initial communication reconnection fails, the client determines the waiting time corresponding to the current communication reconnection based on the current number of reconnections, waits for the waiting time corresponding to the current communication reconnection, and then resends the communication reconnection request to the server. The waiting time increases with the number of reconnections.

[0056] Optionally, in this embodiment, when a client fails to establish a connection with the server, it does not immediately retry, but waits for a period of time before trying again. The time interval gradually increases with the number of retries to avoid exacerbating system load or network congestion due to frequent retries.

[0057] Optionally, when the client detects a disconnection in communication with the server, it immediately initiates an initial reconnection request. If the initial reconnection fails, it enters a backoff reconnection process. Specifically, the client calculates the waiting time before the next reconnection based on the number of reconnections that have already occurred, using a preset backoff strategy, such as an exponential backoff strategy or a linear backoff strategy. The exponential backoff strategy refers to a waiting time that increases exponentially, for example, 1 second, 2 seconds, 4 seconds, or 8 seconds, with a maximum delay limit set, such as 30 seconds. The linear backoff strategy refers to a waiting time that increases in a fixed increment, for example, 1 second, 2 seconds, or 3 seconds.

[0058] Optionally, to avoid the thundering herd effect caused by multiple clients retries simultaneously, a random factor such as jitter is introduced on the basis of the calculated waiting time to determine the client's final actual waiting time. The client can sleep during this waiting time and then send a communication reconnection request to the server again, repeating the above process until the connection is successful or the maximum number of retries is reached.

[0059] Based on this, the embodiments of this application effectively avoid the thundering herd effect caused by a large number of clients making synchronous retries during network or server anomalies by introducing a random factor and dynamically extending the reconnection interval, significantly reducing the instantaneous pressure on the server and network. At the same time, the adaptive increase in waiting time provides a buffer time for server recovery, which helps to improve the reconnection success rate.

[0060] Figure 4 This illustration shows an interactive diagram of a device permission information processing method provided in an embodiment of this application. (Refer to...) Figure 4 As shown, the method specifically includes the following steps: S401. The client detects whether the communication connection between the client and the server is broken.

[0061] Optionally, the client can periodically send heartbeat packets to the server and wait for a valid response within a preset timeout threshold. If no response is received within the timeout period, or if the underlying Socket connection is closed due to network abnormalities, server crashes, or other reasons, it is determined that the communication connection between the client and the server has been broken.

[0062] S402. If the communication connection between the client and the server is broken, the client sends a communication reconnection request to the server according to the backoff reconnection policy.

[0063] Optionally, after the client detects a disconnection during heartbeat detection, it immediately initiates a reconnection request. If the reconnection fails, it calculates the waiting time according to the number of reconnections already occurred and follows a preset backoff strategy. During this waiting time, it sleeps and tries to reconnect again, and repeats this process until the reconnection is successful or the maximum number of retries is reached.

[0064] S403. The server decrypts the encrypted first authorization information based on the client's machine code to obtain the plaintext first authorization information.

[0065] Optionally, the server restores the plaintext of the first authorization information through a dual decryption mechanism. Specifically, the server first uses the client machine code bound to the client as a key to perform the first layer of decryption on the ciphertext of the first authorization information to obtain the intermediate ciphertext. Then, the server uses its private device key to perform the second layer of decryption on the intermediate ciphertext, and finally obtains the original plaintext of the first authorization information.

[0066] S404. The server verifies the plaintext of the first authorization information and restores the client's permissions after successful verification.

[0067] Optionally, the server retrieves the corresponding encrypted second authorization information and the validity period of the authorization token from a preset database based on the client machine code provided by the client. It then decrypts the encrypted second authorization information using the server's private device key to obtain the plaintext second authorization information. The server compares the plaintext second authorization information with the plaintext first authorization information obtained through double decryption and verifies whether the current time is within the validity period of the authorization token. If the plaintext first authorization information matches the plaintext second authorization information and the authorization token is within the validity period, the verification is confirmed to be successful, and the client's permissions are automatically restored.

[0068] Based on this, according to the device permission information processing method of this application embodiment, during the initial authorization, the server generates a unique authorization token and encrypts it to obtain the second authorization information ciphertext. The client uses its local client machine code to encrypt the second authorization information ciphertext a second time to obtain the first authorization information ciphertext and caches it securely. When the communication connection between the client and the server is interrupted due to network interruption or cryptographic machine failure, the client does not need user intervention. It only needs to send a communication reconnection request carrying the first authorization information ciphertext and the client machine code to the server. The server uses the client machine code and the server device key to double decrypt the first authorization information ciphertext, restore the first authorization information plaintext, and compare and verify it with the original authorization information stored in the server's preset database. At the same time, it verifies the validity period of the authorization token and automatically restores the client's permissions after successful verification. Since the whole process realizes seamless, automatic, and secure permission inheritance, it avoids the manual authentication overhead of repeatedly entering control codes in scenarios with frequent network outages. Therefore, this application embodiment effectively solves the problem of low reconnection efficiency caused by manual re-authentication after the Socket connection is disconnected in the prior art, and significantly improves the reconnection efficiency and user experience in a high-availability environment.

[0069] Figure 5 A flowchart illustrating an authorization token verification method provided in an embodiment of this application is shown. (Refer to...) Figure 5 As shown, the method specifically includes the following steps: S501: The server signs the authorization token based on the device certificate to obtain the signature information.

[0070] Optionally, the server obtains the unique device certificate bound to the client, uses the authorization token as the data to be signed, and uses a secure signature algorithm in combination with the device certificate to digitally sign the authorization token, outputting unforgeable signature information, thereby ensuring the integrity and authenticity of the authorization token.

[0071] S502, The server combines the signature information and the authorization token to obtain a new authorization token.

[0072] Optionally, the server concatenates the authorization token and the generated signature information according to a predefined structure to form a new authorization token. The concatenation method is not specifically limited, as long as the authorization token content is retained along with the corresponding device-level signature for subsequent client verification.

[0073] S503, the server sends the new authorization token to the client.

[0074] Optionally, the new authorization token includes signature information and an authorization token. The server sends the combined new authorization token to the client through a secure communication channel, so that the client can verify the signature information to ensure that the authorization token was indeed generated by the trusted server, thus avoiding man-in-the-middle attacks.

[0075] S504. The client verifies the authorization token.

[0076] Optionally, after receiving a new authorization token, the client separates the authorization token and signature information from the new authorization token, re-signs the authorization token using the same signature algorithm to obtain new signature information, and compares this new signature information with the received signature information. If they match, it proves that the authorization token was indeed issued by the trusted server and that the content of the authorization token has not been tampered with. Conversely, if they do not match, the authorization token is considered invalid or forged by a man-in-the-middle attack, and the client should refuse to use the authorization token, thereby effectively defending against man-in-the-middle attacks and token forgery risks.

[0077] Based on this, the embodiments of this application digitally sign the authorization token, so that the generated new authorization token not only contains authorization information, but also carries an unforgeable device-level identity certificate. The client can verify that the authorization token indeed originates from a trusted server and has not been tampered with. In this way, attacks such as man-in-the-middle interception, replay, or forgery of the authorization token are effectively prevented, and the security of the authentication process is significantly improved.

[0078] Figure 6 A flowchart illustrating an authorization token generation method provided in an embodiment of this application is shown. (Refer to...) Figure 6 As shown, the method specifically includes the following steps: S601, The client sends a connection request to the server.

[0079] Optionally, after a user triggers the login or authentication process, the client actively initiates a connection request based on the Transmission Control Protocol (TCP) and starts a Socket connection through the specified server address and port number. In this embodiment, the client's connection request can establish a connection with the server through a TCP three-way handshake, thereby establishing a reliable bidirectional communication channel between the client and the server, laying the foundation for subsequent authentication and data interaction.

[0080] S602. The server responds to the connection request and returns a connection handle to the client.

[0081] Optionally, after the server detects a connection request from the client, it completes a TCP three-way handshake, successfully establishes a Socket connection, and assigns a unique connection handle to the connection. Furthermore, the server returns an acknowledgment to the client, indicating that the connection is ready for subsequent authentication interactions.

[0082] S603, The client sends the private key access control code and the client machine code to the server.

[0083] Optionally, after the connection is established, the client reads the private key access control code and the client machine code from local secure storage. The private key access control code is a unique and confidential string, and the client machine code is a unique identifier for the client machine, calculated using a hash algorithm by combining unique hardware information of the client's machine, such as the CPU serial number, hard drive serial number, and network card MAC address. The client sends the private key access control code and the client machine code to the server through the established socket connection for subsequent identity verification and token binding.

[0084] S604. The server verifies the private key access control code, and after successful verification, generates an authorization token based on the client machine code and sets the validity period of the authorization token.

[0085] Optionally, after receiving the private key access control code and the client machine code, the server first verifies the private key access control code. Specifically, the private key access control code is generated by the administrator on the server and distributed to the user. The user sends the private key access control code to the server on the client side for string matching verification. After successful verification, the server combines the client machine code, the server-side random number, the server-side time, and other server-side identification information to obtain structured plaintext data. Then, by performing a hash operation on the structured plaintext data, a unique and irreversible authorization token is generated.

[0086] Furthermore, the server sets an expiration date for the generated authorization token. Specifically, the server can set a lifecycle timer to limit the validity period of the authorization token, i.e., the expiration time, such as 1 day. After 1 day, the authorization token will no longer be usable and needs to be refreshed along with its expiration time. This ensures the security of the authorization token and prevents it from being used indefinitely. Additionally, after setting the validity period of the authorization token, the validity period is temporarily stored in a preset database.

[0087] Based on this, the embodiments of this application complete user legitimacy verification through private key access control codes. The authorization token generation process introduces client machine code, thereby ensuring that the generated authorization token is strongly associated with a specific device. Furthermore, in the process of generating the authorization token based on the client machine code, server-side random numbers, server-side time, other server-side identification information, and hash algorithms are combined to ensure that an unpredictable, irreversible, and unique authorization token is generated each time, effectively preventing replay attacks, forgery, and tampering. At the same time, a clear validity period is set for the generated authorization token, limiting the expiration time of the authorization token, thereby enhancing the security protection capabilities against unauthorized access, credential leakage, or man-in-the-middle attacks.

[0088] Figure 7 A flowchart illustrating a method for generating encrypted first authorization information according to an embodiment of this application is shown. (Refer to...) Figure 7 As shown, the method specifically includes the following steps: S701. The server encrypts the authorization token based on the server's device key to obtain the second authorization information ciphertext.

[0089] Optionally, after the initial successful authorization, the server uses its private device key to encrypt the generated authorization token Token, generating a tamper-proof second authorization information ciphertext TokenA. In this way, the server encrypts the authorization token Token based on its private device key, ensuring that only the server holding the corresponding key can decrypt the second authorization information ciphertext TokenA to obtain the second authorization information plaintext TokenA'', thereby guaranteeing the security and confidentiality of the authorization token Token during storage and transmission.

[0090] S702. The server binds the encrypted second authorization information with the client machine code and stores it in a preset database.

[0091] Optionally, the server associates the generated second authorization information ciphertext TokenA with its corresponding client machine code, and writes it along with the validity period of the authorization token TokenA into a persistent database. In this embodiment, binding the second authorization information ciphertext TokenA with the client machine code allows for quick retrieval and verification of the client's identity during subsequent reconnections, ensuring that each device can only use its own exclusive authorization token, thus achieving device-level access control.

[0092] S703, The server sends the encrypted second authorization information to the client.

[0093] Optionally, the server returns the second authorization information ciphertext TokenA as a successful authentication response data to the client through the established secure communication channel. This second authorization information ciphertext TokenA cannot be decrypted even if intercepted by a third party, providing a credential for the client's subsequent secure storage and reconnection authentication.

[0094] S704. The client encrypts the second authorization information ciphertext based on the client machine code to generate the first authorization information ciphertext.

[0095] Optionally, after receiving the second authorization information ciphertext TokenA, the client uses its local client machine code as a key to perform a second encryption on the second authorization information ciphertext TokenA using a secure encryption algorithm to generate the first authorization information ciphertext TokenB.

[0096] Optionally, after generating the first authorization information ciphertext TokenB, the client stores the first authorization information ciphertext TokenB in a secure memory area and binds it to the current Socket connection handle and lifecycle timer to prevent leakage or unauthorized access.

[0097] Based on this, in the process of generating the first authorization information ciphertext provided in this application embodiment, the server uses its own device key to encrypt the token to ensure its authority and anti-counterfeiting properties. The client then uses a unique machine code for secondary encryption to achieve the confidentiality and device exclusivity of locally stored information. Even if an attacker steals the first authorization information ciphertext from the client's memory, they cannot effectively decrypt it. In this way, risks such as token theft and cross-device reuse are effectively defended, and seamless reconnection is achieved while ensuring high security.

[0098] As one possible implementation, in a multi-server cryptographic machine cluster, this embodiment introduces a consensus algorithm to synchronize the token state database, ensuring that token information can be recovered from other nodes after any node fails. Specifically, in a multi-server cryptographic machine cluster, all server cryptographic machines synchronize all currently stored tokens, and each server cryptographic machine accepts and saves new tokens at any time. The consensus algorithm allows the tokens of all server cryptographic machines to maintain consistency. Especially in the case of data conflicts, the master node elected by the consensus algorithm can decide how to handle conflicting data. When the data of all nodes is consistent, a server cryptographic machine that has failed and restarted can synchronize the latest token data on any node without worrying about whether the data is up-to-date.

[0099] This application embodiment also provides an electronic device 800, which can be either a client or a server as described above. When the electronic device 800 is a client, it executes the steps of the device permission information processing method executed by the client. When the electronic device 800 is a server, it executes the steps of the device permission information processing method executed by the server. Figure 8 The diagram shown is a structural schematic of an electronic device 800 provided in an embodiment of this application, including: a processor 801 and a memory 802, and optionally, a bus 803. The memory 802 stores machine-readable instructions executable by the processor 801. When the electronic device 800 is running, the processor 801 and the memory 802 communicate via the bus 803. When the machine-readable instructions are executed by the processor 801, the steps of the device permission information processing method executed by the client or server described above are performed.

[0100] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the device permission information processing method described in any of the preceding claims.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0102] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0103] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for processing device access information, characterized in that, Applied to the server side, the method includes: The system receives a communication reconnection request sent by the client. The communication reconnection request includes a first authorization information ciphertext and a client machine code. The first authorization information ciphertext is obtained by the client encrypting the authorization token generated by the server during the initial authorization. The first authorization information ciphertext is decrypted based on the client machine code to obtain the first authorization information plaintext; The first authorization information in plaintext is verified, and the client permissions are restored after the verification is successful.

2. The method according to claim 1, characterized in that, The step of decrypting the first authorization information ciphertext based on the client machine code to obtain the first authorization information plaintext includes: The first authorized information ciphertext is decrypted based on the client machine code to obtain the first ciphertext; The first ciphertext is decrypted using the server's device key to obtain the first authorization information plaintext.

3. The method according to claim 1, characterized in that, The method further includes: Receive the private key access control code and the client machine code sent by the client; The private key access control code is verified, and after successful verification, the authorization token is generated based on the client machine code, and the validity period of the authorization token is set. The authorization token is encrypted using the server's device key to obtain the second authorization information ciphertext; The second authorization information ciphertext is bound to the client machine code and stored in a preset database, and the second authorization information ciphertext is sent to the client.

4. The method according to claim 3, characterized in that, The step of verifying the plaintext of the first authorization information and restoring client permissions after successful verification includes: Based on the client machine code, the second authorization information ciphertext is obtained from the preset database, and the validity period of the authorization token is also obtained. The encrypted second authorization information is decrypted based on the server's device key to obtain the plaintext second authorization information; Verify whether the first authorization information plaintext is consistent with the second authorization information plaintext. If they are consistent and the authorization token is within its validity period, then the verification is successful and the client permissions are restored.

5. The method according to claim 3, characterized in that, After verifying the private key access control code and generating the authorization token based on the client machine code upon successful verification, the process further includes: The authorization token is signed based on the device certificate to obtain signature information; The signature information and the authorization token are combined to obtain a new authorization token, which is then sent to the client so that the client can verify the authorization token.

6. A method for processing device access information, characterized in that, Applied to a client, the method includes: Detect whether the communication connection between the client and the server is broken; If so, a communication reconnection request is sent to the server according to the backoff reconnection strategy. The communication reconnection request includes a first authorization information ciphertext and a client machine code. The first authorization information ciphertext is obtained by the client encrypting the authorization token generated by the server during the first authorization, so that the server can decrypt the first authorization information ciphertext based on the client machine code to obtain the first authorization information plaintext. The first authorization information plaintext is used to restore the client's permissions after successful verification.

7. The method according to claim 6, characterized in that, The method further includes: Receive the second authorized information ciphertext sent by the server, wherein the second authorized information ciphertext is obtained by the server encrypting the authorization token based on the server's device key; The second authorization information ciphertext is encrypted based on the client machine code to generate the first authorization information ciphertext.

8. The method according to claim 6, characterized in that, Sending a communication reconnection request to the server according to the backoff reconnection strategy includes: When the communication connection between the client and the server is detected to be broken, an initial communication reconnection request is sent to the server. If the first communication reconnection fails, the waiting time corresponding to the current communication reconnection is determined according to the current number of reconnections, and the waiting time increases with the increase of the number of reconnections; Wait for the specified waiting time, then resend the communication reconnection request to the server.

9. An electronic device, characterized in that, include: The device includes a processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when the electronic device is in operation, are executed by the processor to perform the steps of the device access information processing method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the device permission information processing method as described in any one of claims 1 to 8.

Images