Data processing methods, devices, electronic equipment, and storage media based on encryption machines

Abstract

This invention provides a data processing method, apparatus, electronic device, and storage medium based on an encryption machine. The method includes: an idle service sub-thread receiving a notification sent by the main process, reading a memory area, and obtaining connection information of a target service session; the idle service sub-thread receiving data packets of service data sent by a client, determining the target interface based on the client's target request, obtaining multiple parameter data required by the target interface, performing algorithmic operations or key management on each parameter data, and obtaining the completed data; the algorithmic operations include at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification; assembling the completed data into a network communication data packet, and sending the network communication data packet to the client. This invention, while meeting the functional requirements of a hardware encryption machine such as high concurrency and high encryption / decryption performance, combines the characteristics of software design to achieve multiple advantages such as high customizability and scalability, low environmental requirements, and low cost.

Description

Technical Field

[0001] This invention relates to the field of encryption machine technology, and in particular to a data processing method, apparatus, electronic device and storage medium based on an encryption machine. Background Technology

[0002] The encryption machine is a domestically developed host encryption device that has been certified and approved for use by the national commercial cryptography authority. The encryption machine and the host communicate using the TCP / IP protocol, therefore, the encryption machine has no special requirements regarding the type of host or its operating system. It is mainly used to implement various cryptographic algorithms and provide data encryption / decryption, key management, and other services to the host.

[0003] The encryption machine in the relevant technology processes data on the hardware level, which would have certain limitations if used on the software level. Summary of the Invention

[0004] This invention provides a data processing method, apparatus, electronic device, and storage medium based on an encryption machine, which addresses the aforementioned deficiencies in the prior art by integrating the encryption machine with software and leveraging the characteristics of software design to achieve data processing.

[0005] This invention provides a data processing method based on an encryption machine, applied to a server. The server includes a main process and sub-threads. The method includes:

[0006] The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread.

[0007] The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks.

[0008] The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session;

[0009] The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the target request of the client, obtains multiple parameter data required by the target interface, performs algorithm operation or key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption or signature verification;

[0010] The completed data is assembled into a network communication data packet, and the network communication data packet is sent to the client.

[0011] According to a data processing method based on an encryption machine provided by the present invention, the idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the target request of the client, and obtains multiple parameter data required by the target interface, including:

[0012] The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is correct, and reads the first variable in the data packet that marks the length of subsequent service data;

[0013] The idle service sub-thread reads the second variable marking the request interface in the data packet, and calls the target interface based on the second variable to pass the service data to the target interface;

[0014] The target interface of the idle business sub-thread parses the business data to obtain multiple parameter data required by the target interface.

[0015] According to a data processing method based on an encryption machine provided by the present invention, the main process receives a target request sent by a client, triggers sub-thread monitoring based on the target request, and determines idle business sub-threads, including:

[0016] The server receives the target request sent by the client and establishes a Transport Layer Security (TLS) connection with the client based on the configuration information in the configuration file.

[0017] The server verifies the connection is valid and iterates through all the sub-thread information structures to determine the idle business sub-thread.

[0018] The idle service sub-thread is a sub-thread that is currently carrying fewer services than the set maximum single-thread capacity.

[0019] According to a data processing method based on an encryption machine provided by the present invention, after the idle service sub-thread receives a notification sent by the main process, reads the memory area, and obtains the connection information of the target service session, it further includes:

[0020] The main process returns to a waiting state to determine if there is a new target client connection.

[0021] The sub-thread returns to a waiting state to handle new business sessions or network communication events.

[0022] According to a data processing method based on an encryption machine provided by the present invention, after the idle service sub-thread receives the data packet of service data sent by the client, it further includes:

[0023] The idle service sub-thread triggers network communication event monitoring, calls the callback function corresponding to the client, and processes the data packet and the notification based on the callback function.

[0024] A data processing method based on an encryption machine according to the present invention further includes:

[0025] The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is incorrect, sends the check error information to the client, and closes the network connection.

[0026] According to a data processing method based on an encryption machine provided by the present invention, before the main process receives a target request sent by a client, triggers sub-thread monitoring based on the target request, and determines an idle business sub-thread, the method further includes:

[0027] The server-side business processing module is initialized to enable network communication verification with the client, multi-thread allocation, encryption / decryption operations, and key management.

[0028] After assembling the completed data into a network communication data packet and sending the data packet to the client, the process further includes:

[0029] Close the network connection with the client and exit the main process and all sub-threads.

[0030] A data processing method based on an encryption machine according to the present invention further includes:

[0031] Based on the SELinux security mechanism, the business data and key storage are protected.

[0032] This invention also provides a data processing method based on an encryption machine, applied to a client, comprising:

[0033] Send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0034] Receive network communication data packets sent by the idle service sub-thread.

[0035] According to a data processing method based on an encryption machine provided by the present invention, after receiving the network communication data packet sent by the idle service sub-thread, the method further includes:

[0036] The network communication data packets are verified, and those that meet the verification criteria are decoded to obtain the data structure required by the interface.

[0037] The data structure is subjected to secondary verification based on the interface. The network communication data that meets the secondary verification standard is processed based on the interface parameters to obtain the target data.

[0038] The target data is then returned to the user.

[0039] According to a data processing method based on an encryption machine provided by the present invention, before sending the target request to the main process of the server, the method further includes:

[0040] The client's encryption device is initialized to enable the encoding, data encoding / decoding modules, and network communication verification for the external standard interface.

[0041] After receiving the network communication data packet sent by the idle service sub-thread, the method further includes:

[0042] Disconnect from the TLS environment and close the network connection with the server.

[0043] The present invention also provides a data processing device based on an encryption machine, applied to a server, wherein the server includes a main process and sub-threads, and the device includes:

[0044] The first unit is used to enable the main process to receive the target request sent by the client, trigger sub-thread monitoring based on the target request, and determine the idle business sub-thread.

[0045] The second unit is used by the main process to read the business data of the idle business sub-thread and write the session information of the target business into the memory area of ​​the idle business sub-thread. The business data includes pipes, pointers to memory storing business information, and communication locks.

[0046] The third unit is used for the idle service sub-thread to receive the notification sent by the main process, read the memory area, and obtain the connection information of the target service session;

[0047] The fourth unit is used for the idle service sub-thread to receive data packets of service data sent by the client, determine the target interface based on the target request of the client, obtain multiple parameter data required by the target interface, perform algorithm operations or key management on each parameter data, and obtain the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification;

[0048] The fifth unit is used to assemble the completed data into a network communication data packet and send the network communication data packet to the client.

[0049] The present invention also provides a data processing device based on an encryption machine, applied to a client, comprising:

[0050] The sixth unit is used to send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0051] The seventh unit is used to receive network communication data packets sent by the idle service sub-thread.

[0052] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the data processing method based on the encryption machine as described above.

[0053] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data processing method based on the encryption machine as described above.

[0054] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the data processing method based on the encryption machine as described above.

[0055] The present invention provides a data processing method, apparatus, electronic device, and storage medium based on an encryption machine. The main process receives a target request from a client, triggers sub-thread monitoring based on the target request, and identifies an idle service sub-thread. The main process reads the service data from the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, a pointer to the memory storing service information, and a communication lock. The idle service sub-thread receives a notification from the main process, reads the memory area, and obtains the connection information of the target service session. The idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the client's target request, obtains multiple parameter data required by the target interface, performs algorithm calculations or key management on each parameter data, and obtains the completed data. The algorithm calculations include at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification. The completed data is assembled into a network communication data packet and sent to the client. Based on the high concurrency and high encryption / decryption performance requirements of a hardware encryption machine, the present invention, combined with the characteristics of software design, achieves multiple advantages such as high customizability and scalability, low environmental requirements, and low cost, thus avoiding the limitations of existing hardware encryption machines. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0057] Figure 1 This is one of the flowcharts illustrating the data processing method based on an encryption machine provided by the present invention;

[0058] Figure 2 This is a module architecture diagram of the software encryption machine method provided by the present invention;

[0059] Figure 3 This is the second flowchart of the data processing method based on an encryption machine provided by the present invention;

[0060] Figure 4 This is the third flowchart of the data processing method based on an encryption machine provided by the present invention;

[0061] Figure 5 This is the fourth flowchart of the data processing method based on an encryption machine provided by the present invention;

[0062] Figure 6 This is the fifth flowchart of the data processing method based on an encryption machine provided by the present invention;

[0063] Figure 7 This is the sixth flowchart of the data processing method based on an encryption machine provided by the present invention;

[0064] Figure 8 This is one of the structural schematic diagrams of the data processing device based on an encryption machine provided by the present invention;

[0065] Figure 9 This is the second schematic diagram of the data processing device based on an encryption machine provided by the present invention;

[0066] Figure 10 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0067] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0068] First, the technical terms used in this invention will be explained.

[0069] HSM (Hardware Security Module): A hardware encryption device, referring to an encryption device that implements encryption mechanisms through chips / circuits, etc.

[0070] SDF (Software Development Framework): A software development framework refers to a software component specification designed for software development to implement an industry standard or accomplish a specific basic task. It also refers to a software product that provides the basic functions required by a specification when implementing a software component specification.

[0071] TLS (Transport Layer Security) is a security protocol, and its predecessor, Secure Sockets Layer (SSL), designed to provide security and data integrity for internet communications. SSL comprises a Record Layer and a Transport Layer. The Record Layer protocol determines the encapsulation format of transport layer data. The Transport Layer Security protocol uses X.509 authentication, followed by asymmetric encryption to authenticate the communicating parties, and then exchanges a symmetric key as a session key. This session key is used to encrypt the data exchanged between the two parties, ensuring the confidentiality and reliability of communication between the two applications and preventing eavesdropping by attackers.

[0072] SELinux: SELinux (Security-Enhanced Linux) is the National Security Agency's (NSA) implementation of mandatory access control and is considered one of the most outstanding new security subsystems in Linux history. Developed with the help of the Linux community, the NSA provides an access control system that restricts processes to accessing only the files necessary for their task. SELinux is a domain-type model-based mandatory access control (MAC) security system. Written and designed by the NSA as a kernel module, it is also patched with SELinux for certain security-related applications and includes a corresponding security policy. SELinux offers superior access control compared to traditional UNIX permissions.

[0073] Libevent: Libevent is a lightweight, open-source, high-performance event notification library written in C. Its key features include: event-driven performance; lightweight design focused on networking, unlike the bloated and bulky ACE library; concise and readable source code; cross-platform compatibility, supporting Windows, Linux, *BSD, and Mac OS; support for various I / O multiplexing technologies such as epoll, poll, dev / poll, select, and kqueue; support for I / O, timers, and signals; and event priority registration.

[0074] Reference Figure 1 The data processing method based on an encryption machine provided by this invention is applied to a server, which includes a main process and sub-threads. The method includes:

[0075] Step 110: The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread;

[0076] Step 120: The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks.

[0077] Step 130: The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session;

[0078] Step 140: The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the target request of the client, obtains multiple parameter data required by the target interface, performs algorithm operation or key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification;

[0079] Step 150: Assemble the completed data into a network communication data packet and send the network communication data packet to the client.

[0080] The steps described above are explained in detail below.

[0081] First, it should be noted that the server and client establish a connection through a network communication interface. When the client creates a connection with the server, the server will receive a connection creation request from the network communication interface. Since the network communication interface is added to the libevent events during server initialization, it will trigger the libevent event listener and call the pre-defined callback function to process the new connection.

[0082] In step 110 above, the main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread.

[0083] It's important to note that the server's main process can iterate through the child thread information structure based on the target request sent by the client to obtain and find currently idle child threads. It's crucial to understand that an idle child thread refers to a thread that is currently handling fewer business sessions than the set maximum single-threaded capacity. For example, if a single thread is set to handle two business sessions, then it is considered idle when it is handling only one. The server's main process will find the thread handling the fewest business sessions and, relatively speaking, the most idle thread, and allocate the connection to it.

[0084] In step 120 above, after selecting an idle business sub-thread, the server main process will obtain the pipe, the pointer to the memory storing business information, and the communication lock from its information structure, and fill the information of the new business session into the memory area.

[0085] In step 130 above, after the new business session information is filled in, the server main process will send a notification to the business sub-thread through a pipe.

[0086] It should be noted that during the information filling and notification sending process, communication locks are used to ensure the exclusive use of relevant resources and the synchronization safety of multiple threads.

[0087] In step 140 above, the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread returns a verification error message to the client and closes the network connection.

[0088] If the sequence code verification passes, the child thread will read the variable in the data packet that marks the length of subsequent business data, and proceed with the next step of data reception based on that variable.

[0089] After the data is received, the child thread will read the variable in the data packet that marks the requested interface, call the corresponding interface based on the variable, and pass the received data to the target interface.

[0090] The target interface parses the transmitted business data, extracts and verifies the various parameters required by the interface. If verification passes, it calls the corresponding underlying interface implementation to perform the actual business processing. If verification fails, it returns the corresponding error information to the client. If the business request involves symmetric / asymmetric encryption / decryption algorithms, signature verification, or similar algorithms, the algorithm implementation module will be called for processing. If the request involves key management or requires a key in the encryption / decryption algorithm, the key management module's interface will be called to request the key.

[0091] In step 150 above, the network communication module packages the data, assembles network communication data packets according to pre-defined settings, and then sends them to the client. The client receives, parses, and returns the data to the user. The business sub-thread then returns to a waiting state until the next pipeline notification or network communication event.

[0092] It should be added that, referring to Figure 2 In this embodiment, the encryption machine includes a client 210 and a server 220. The client 210 includes an encryption machine external standard interface implementation module 211, a data encoding / decoding module 212, and a network communication verification module 213. The server 220 includes a business processing module 221 and a key management module 222. The business processing module 221 includes four parts: a network communication verification module 201, a multi-thread allocation / session management module 202 (session management module), a sub-thread business processing module 203 (sub-thread business processing module), and an algorithm implementation module 204. The key management module 222 includes an interface module 223 (hereinafter referred to as the communication interface module) for communicating with the business processing module, a key encryption / decryption module 224, and a key storage module 225.

[0093] The client component is a program installed on the user's host computer, provided as a library file, and exposes a standard encryption machine SDF interface for users to call and use.

[0094] The encryption machine's external standard interface implementation module is mainly responsible for the encoding implementation of relevant standard interfaces, including parameter verification and initial processing, runtime environment initialization, receiving parsed data returned by the data encoding and decoding module, performing relevant finishing processing, and returning the data to the user.

[0095] The data encoding and decoding module is mainly responsible for encoding, encapsulating, and packaging data according to a predefined structure, and calling the network communication verification module to interact with the server; as well as parsing and unpacking the data returned from the server, generating the corresponding data structure, and returning the relevant structure to the encryption machine's external standard interface implementation module.

[0096] The network communication verification module is mainly responsible for network communication with the server. TLS secure communication processing, data packet sending and receiving verification logic, and anti-replay verification logic are also implemented in this module.

[0097] The main body of the software encryption machine is a binary program installed on a server, running as a service program, and providing services to clients on the host as a server.

[0098] The server-side business processing module is the most important functional implementation part of the encryption machine server. It is directly responsible for listening to the network interface, accepting client requests and allocating threads (business allocation), as well as performing specific business processing in sub-threads.

[0099] The key management module is primarily responsible for managing the keys stored within the encryption machine. Because the keys need to be stored in a secure and private environment, it is designed to be completely independent, interacting with the business processing module only through predefined pipe interfaces to avoid potential vulnerabilities and data leaks. Simultaneously, the entire encryption machine server implementation employs SELinux security mechanisms for isolation and protection. Each sub-thread in the business processing module uses a different SELinux tag. Threads under different tags can only access the memory they control and cannot bypass these restrictions to access the memory of other threads, or access the resources of other processes or the system, ensuring the independence of each thread and effectively preventing resource leaks. Furthermore, the key management module also uses a separate SELinux tag, independent of the business processing module. Besides interacting through interfaces, it completely prevents access from other processes, ensuring key security.

[0100] The specific component implementations of the business processing module and the key management module are as follows:

[0101] The network verification communication module is mainly responsible for monitoring connections from clients and calling the session management module for allocation after receiving a connection; it is also responsible for communication and interaction processing with clients during business execution. TLS secure communication processing, data packet sending and receiving verification logic, and anti-replay verification logic are also implemented in this module.

[0102] The session management module is mainly responsible for checking whether each business sub-thread is idle when a new request is received (meaning that the maximum number of sessions that can be processed by a single thread has not been reached, which can be set according to the actual server performance), and then assigning the new connection session to the corresponding idle business thread for processing. The initialization of relevant business environment variables is also performed in this module (including the initialization of the TLS environment; the specific communication processing is handled by the network communication verification module).

[0103] The sub-thread business processing module is the core function implementation of the software encryption machine. It is mainly responsible for decoding the business request received from the client, calling the corresponding interface for processing, and then re-encoding and packaging the processed data before returning it to the client through the network communication verification module.

[0104] The algorithm implementation module is responsible for the underlying algorithm implementation of various interfaces in the software encryption machine. This module supports a variety of different implementations, such as openssl, libgcrypt, algorithm implementations included in the system kernel, and custom algorithm implementations. The most suitable module can be selected based on the needs or actual performance.

[0105] It should be noted that the communication interface module is the core module of the key management function. It implements the main interface for communication and interaction with the business processing module, and also includes anti-debugging and anti-cracking mechanisms to ensure key security and confidentiality by checking the integrity of the environment in real time.

[0106] The key encryption / decryption module is mainly responsible for encrypting and decrypting the key during the storage and retrieval process to ensure the security of the key.

[0107] The key storage module is mainly responsible for providing high-concurrency and high-stability storage management functions. Since the key data itself is not large and there is no need for data storage, high-concurrency small data access performance is the main consideration.

[0108] The data processing method based on an encryption machine provided by this invention involves the main process receiving a target request sent by a client, triggering sub-thread monitoring based on the target request, and identifying idle service sub-threads. The main process reads the service data from the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks. The idle service sub-thread receives a notification sent by the main process, reads the memory area, and obtains the connection information of the target service session. The idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the client's target request, obtains multiple parameter data required by the target interface, performs algorithm calculations or key management on each parameter data, and obtains the completed data. The algorithm calculations include at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification. The completed data is assembled into a network communication data packet and sent to the client. This invention, while meeting the high concurrency and high encryption / decryption performance requirements of a hardware encryption machine, combines the characteristics of software design to achieve highly customizable scalability, low environmental requirements, and low cost, thus avoiding the limitations of existing hardware encryption machines.

[0109] In some embodiments, the idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the client's target request, and obtains multiple parameter data required by the target interface, including:

[0110] The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is correct, and reads the first variable in the data packet that marks the length of subsequent service data;

[0111] The idle service sub-thread reads the second variable marking the request interface in the data packet, and calls the target interface based on the second variable to pass the service data to the target interface;

[0112] The target interface of the idle business sub-thread parses the business data to obtain multiple parameter data required by the target interface.

[0113] It is understood that this embodiment describes the specific process of data parsing for the target interface.

[0114] First, the idle service sub-thread reads the first data packet of the service data and confirms that the checksum of the first data packet is correct. It then reads the first variable in the data packet that marks the length of subsequent service data. Otherwise, if the checksum of the first data packet is determined to be incorrect or invalid, the sub-thread will return a checksum error message to the client and close the network connection. Next, the idle service sub-thread reads the second variable in the data packet that marks the requested interface, and calls the target interface based on the second variable to pass the service data to the target interface.

[0115] It should be noted that the target interface is selected from the interface module for communication between the business processing module on the server side based on the second variable.

[0116] Finally, the idle business sub-thread parses the business data at the target interface to obtain the multiple parameter data required by the target interface. This parameter data can be used for data processing by multiple business processing modules.

[0117] Specifically, the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread returns a verification error message to the client and closes the network connection.

[0118] If the sequence code verification passes, the child thread will read the variable in the data packet that marks the length of subsequent business data, and proceed with the next step of data reception based on that variable.

[0119] After the data is received, the child thread will read the variable in the data packet that marks the requested interface, call the corresponding interface based on the variable, and pass the received data to the target interface.

[0120] The target interface parses the transmitted business data, extracts and verifies the various parameters required by the interface. If verification passes, it calls the corresponding underlying interface implementation to perform the actual business processing. If verification fails, it returns the corresponding error information to the client. If the business request involves symmetric / asymmetric encryption / decryption algorithms, signature verification, or similar algorithms, the algorithm implementation module will be called for processing. If the request involves key management or requires a key in the encryption / decryption algorithm, the key management module's interface will be called to request the key.

[0121] In some embodiments, the main process receives a target request sent by the client, triggers sub-thread monitoring based on the target request, and determines idle service sub-threads, including:

[0122] The server receives the target request sent by the client and establishes a Transport Layer Security (TLS) connection with the client based on the configuration information in the configuration file.

[0123] The server verifies the connection is valid and iterates through all the sub-thread information structures to determine the idle business sub-thread.

[0124] The idle service sub-thread is a sub-thread that is currently carrying fewer services than the set maximum single-thread capacity.

[0125] It should be noted that, in this embodiment, before selecting an idle service sub-thread, the server-side main process needs to establish a TLS secure connection with the client according to the configuration in the configuration file.

[0126] After a connection is established, the server will perform a preliminary check on the connection's validity, such as checking the IP whitelist. If the client's IP is not in the whitelist, the server will return an error message and close the connection. Then it will return to listening and waiting for new connections.

[0127] In some embodiments, after the idle service sub-thread receives the notification sent by the main process, reads the memory region, and obtains the connection information of the target service session, it further includes:

[0128] The main process returns to a waiting state to determine if there is a new target client connection.

[0129] The sub-thread returns to a waiting state to handle new business sessions or network communication events.

[0130] Understandably, once the notification is sent, the relevant work of the business allocation / session management module is completed, and the server main process returns to the waiting state to await new connections.

[0131] Furthermore, after the processing flow for a new business session in the business sub-thread is completed, the sub-thread returns to the waiting state to prepare for processing new business sessions / network communication events.

[0132] In some embodiments, after the idle service sub-thread receives the data packet of service data sent by the client, it further includes:

[0133] The idle service sub-thread triggers network communication event monitoring, calls the callback function corresponding to the client, and processes the data packet and the notification based on the callback function.

[0134] Understandably, when the server-side business sub-thread receives a notification from the main process in its pipeline, it will trigger the pre-defined libevent listener and call the corresponding callback function for processing.

[0135] The child thread reads the pipe and the corresponding memory area storing business information, obtains the connection information of the new business session (the connection, including the TLS environment, is already established in the main process), and places the communication handle of the connection into the libevent event listener.

[0136] In some embodiments, it also includes:

[0137] The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is incorrect, sends the check error information to the client, and closes the network connection.

[0138] It should be noted that the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread will return a verification error message to the client and close the network connection.

[0139] In some embodiments, before the main process receives a target request sent by the client, triggers sub-thread monitoring based on the target request, and determines an idle service sub-thread, the process further includes:

[0140] The server-side business processing module is initialized to enable network communication verification with the client, multi-thread allocation, encryption / decryption operations, and key management.

[0141] After assembling the completed data into a network communication data packet and sending the data packet to the client, the process further includes:

[0142] Close the network connection with the client and exit the main process and all sub-threads.

[0143] Understandably, before the main thread receives requests and selects idle business sub-threads, the server-side business processing module needs to be initialized to enable functions such as network communication verification with the client, multi-sub-thread allocation, encryption and decryption operations, and key management.

[0144] Furthermore, after the idle service sub-thread finishes, the network connection with the client can be closed promptly, and the current network communication connection and network interface listening can be shut down. This means unregistering each libevent event listener, including network and pipe communication events. Then, the main process / sub-thread will release the allocated memory to avoid memory leaks and data leaks. Finally, the main process / sub-thread exits normally.

[0145] It should be added that, referring to Figure 3 The server-side initialization process may include the following steps:

[0146] Step 301: The software encryption machine server-side business processing module program starts. When the program starts, the SELinux system will assign a SELinux label to the server-side business module process according to the pre-set settings, namely system_u:system_r:softhsm_t:s0:c1.cN mentioned in the aforementioned SELinux security mechanism section.

[0147] Step 302: After the server program starts, it will attempt to read the configuration file and verify the configuration information to initialize the runtime environment. This includes information such as the network interface being listened to, the port, whether TLS is enabled, the number of threads, the number of services that a single thread can handle, and log-related items.

[0148] Step 303: If the configuration reading fails, step 301 will be executed; if the configuration reading and verification are successful, step 304 will be executed.

[0149] Step 304: The server process allocates memory based on the configured number of threads. The memory size is equal to the size of a single thread's data structure multiplied by the number of threads. The data structure stores thread information; the server process relies on these structures to obtain information such as the working status of the business threads. The structure mainly stores the business thread ID, communication pipe variables (used to notify business threads of new business assignments), pipe communication libevent event variables (used to listen to the pipe), network communication libevent event variables (used to listen for new data transmission and reception events of the currently processed business), the number of currently processed business transactions, a pointer to the memory area used to process business data, and a read-write lock to ensure communication security.

[0150] Step 305: After establishing the memory space to store thread information, the server begins creating the working environment for the business threads. This step primarily involves creating pipes based on the number of threads. These pipes will be used by the server process to notify the business threads that new tasks have been assigned. After the pipes are created, they need to be saved to the thread information data structure, and the pipes need to be added to the thread's libevent listener events to ensure that the business threads can receive pipe events correctly.

[0151] Step 306: The sub-thread environment portion, handled by the server process, is completed. The sub-thread is then started to further refine the environment; related sub-thread processing is handled in step 311. When a sub-thread starts, it inherits the SELinux label from the main process by default, which does not achieve secure isolation. Therefore, the server process needs to modify the SELinux label of the sub-thread to ensure that each thread's label is different from the others, while still allowing access from the main process.

[0152] Step 307: After the server process creates the business thread, it begins to create the network communication environment, that is, it binds to and listens to the local interface according to the configuration project.

[0153] Step 308: After the network interface is bound, it is added to the libevent event of the server process. The main process listens to the interface in this way to achieve high concurrency.

[0154] Step 309: After environment initialization is complete, the normal encryption machine business process begins, interacting with the business thread to complete standard encryption machine functions. The software encryption machine server, as a service program, will remain in this step until an unexpected error occurs or the user manually closes it.

[0155] Step 310: If the configuration file reading fails, the server program will report an error, indicating the reason for the failure, and then execute step 318 to exit.

[0156] Step 311: This step is the environment initialization process for the business sub-thread after startup. After the sub-thread starts, it needs to further improve its own runtime environment. The sub-thread first reads its own thread information data structure, obtains the pipe variables and libevent events for pipe communication, and listens for them to ensure normal communication with the main process.

[0157] Step 312: The child thread allocates memory space according to the number of services that a single thread can handle, as set in the configuration file. This memory space will be used to store information for each service and the data to be processed (and the processed data) within that service. After memory allocation is complete, the memory pointer of this memory block needs to be saved into the thread information structure so that the main process can use it to populate service information when it receives a new request.

[0158] Step 313: After the child thread completes environment initialization, it needs to synchronize its current working state to the thread information structure, such as the number of currently processed tasks (which is 0 upon initialization), so that the main process can check and select to allocate new tasks. After synchronization, the child thread enters a waiting state, waiting for new tasks to be allocated and processed.

[0159] Step 314: When a new service is assigned, the child thread begins interacting with the main process to receive and process the encryption machine's services normally. As a service program, the software encryption machine server will keep the child thread in this step until an unexpected error occurs or it is manually closed by the user.

[0160] Step 315: This step will be executed when an error occurs or a message from the user indicating that the server has been closed is received. First, the main process / child thread will close the current network communication connection and network interface listening.

[0161] Step 316: Then unregister the respective libevent event listeners, including network and pipe communication events.

[0162] Step 317: Finally, the main process / child thread will release the allocated memory to avoid memory leaks and data leaks.

[0163] Step 318: The main process / sub-thread exits normally.

[0164] In some embodiments, it also includes:

[0165] Based on the SELinux security mechanism, the business data and key storage are protected.

[0166] It should be noted that, outside of the standard business process, the software encryption machine solution uses the SELinux security mechanism on the server side to ensure the security of data and key storage.

[0167] SELinux implements a type-based access control mechanism to maintain system security. Simply put, an access request includes a subject (the executor of the request), an object (the target of the request), and the request itself (read, write, or other). These three elements are tagged and restricted by a set of rules. For example, if "A can read B," then A cannot read C, nor can A write to B, because this is prohibited by the rules; A is only allowed to read B. Based on this type-based access control rule, there is also a security level access control rule. Simply put, higher-level accesses can access lower-level accesses, and lower-level accesses cannot access higher-level accesses. Accesses within the same security category (this category is different from the SELinux subject / object type; it is numbered) are allowed, while accesses outside the security category are not allowed. SELinux tags are in the format "user:role:subject / object tag:security level:security category," for example: system_u:system_r:sshd_t:s0:c1.

[0168] The software encryption machine achieves this by configuring the SELinux subject / object types, security levels, and security categories for the server's main thread and business sub-threads. This allows the main thread to access sub-threads (for normal session management operations), but prevents sub-threads from accessing each other, thus isolating the thread environments and preventing data leakage. Simultaneously, the key management module is configured with completely independent SELinux subject / object types, security levels, and security categories. This ensures that business processing modules cannot access the key management module's process environment at all, and can only access it through reserved interfaces. This guarantees that the key management module operates in a completely independent environment, preventing key leakage.

[0169] The SELinux label design for the software encryption machine is as follows:

[0170] The main thread of the business processing module is: system_u:system_r:softhsm_t:s0:c1.c5 (or larger, depending on the number of threads). Here, system_u and system_r are user / role labels in SELinux, which are not used in this scheme. softhsm_t is the subject / object label of the software encryption machine's business processing module, s0 is the security level, and c1.c5 represents the security categories from c1 to c5. "." indicates consecutive security levels, and "," indicates separation.

[0171] The business processing module's sub-threads are categorized as follows: system_u:system_r:softhsm_t:s0:c1 (or c2 / c3... / c5...). The biggest difference between sub-threads and main threads lies in their security type. Each sub-thread has only one security category (e.g., c1), while the main thread has security categories for all threads (c1 to c5 to cN, where N is the number of threads). Therefore, the main thread has access rights to the sub-threads to ensure normal session management operations. However, sub-threads cannot access each other due to their different security categories.

[0172] The key management module process is named `system_u:system_r:softhsmkeymanage_t:s0`. The subject / object label `softhsmkeymanage_t` is completely different from the label of the business processing module thread. This label is also a custom label, different from other process labels in the system. Therefore, under the SELinux rules framework, no process has access to the key management module process, thus ensuring key security. The program itself reserves relevant key management interfaces, which can be configured to be accessible by the business processing module, ensuring the normal execution of key management functions. Since the key management module contains only one process / thread, isolation using security categories is not required.

[0173] Reference Figure 4 The present invention also provides a data processing method based on an encryption machine, applied to a client, comprising:

[0174] Step 410: Send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0175] Step 420: Receive the network communication data packets sent by the idle service sub-thread.

[0176] In step 410 above, a target request is sent to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0177] It's important to note that when the client sends a target request to the server's main process, the server's main process can iterate through the child thread information structure based on the client's request to find currently idle child threads. It's crucial to understand that an idle child thread is one that is currently handling fewer business sessions than the maximum allowed per thread. For example, if a single thread is set to handle two business sessions, it's considered idle if it's only handling one. The server's main process will then find the thread handling the fewest business sessions and, relatively speaking, the least idle thread, and allocate the connection to it.

[0178] In step 420 above, the network communication module packages the data, assembles network communication data packets according to pre-defined settings, and then sends them to the client. The client receives, parses, and returns the data to the user. The business sub-thread then returns to a waiting state until the next pipe notification or network communication event.

[0179] In some embodiments, after receiving the network communication data packet sent by the idle service sub-thread, the method further includes:

[0180] The network communication data packets are verified, and those that meet the verification criteria are decoded to obtain the data structure required by the interface.

[0181] The data structure is subjected to secondary verification based on the interface. The network communication data that meets the secondary verification standard is processed based on the interface parameters to obtain the target data.

[0182] The target data is then returned to the user.

[0183] It should be noted that in this embodiment, the server-side communication module returns the processed data to the client. This communication process is consistent with the communication process when the client requests an interface from the server, and also includes two parts: a preliminary data packet and a complete interface data packet. The preliminary data packet contains a regenerated sequence code (for identity verification and to prevent replay), a data size flag variable, and an interface flag variable (used to mark the requested interface to avoid the data being mistakenly identified as a return from another interface).

[0184] If an error occurs during server-side processing, the data size flag variable and the interface flag variable will change to error codes accordingly.

[0185] The client-side network communication verification interface validates the data returned by the server to ensure communication security. After verification, the data is returned to the data encoding / decoding module. The data encoding / decoding module decodes the server-side data, generates the data structure required by the interface, and returns it to the interface implementation module. The interface implementation module further validates the data content. After confirming the data is correct, it processes it according to the parameter requirements of the standard SDF interface and returns it to the user.

[0186] In some embodiments, before sending the target request to the server's main process, the method further includes:

[0187] The client's encryption device is initialized to enable the encoding, data encoding / decoding modules, and network communication verification for the external standard interface.

[0188] After receiving the network communication data packet sent by the idle service sub-thread, the method further includes:

[0189] Disconnect from the TLS environment and close the network connection with the server.

[0190] Understandably, the client needs to be initialized before sending a request to the server. This initialization of the client's encryption mechanism is necessary to enable encoding, data encoding / decoding modules, and network communication verification for the external standard interface.

[0191] Furthermore, after the idle service sub-thread ends, the TLS environment can be deregistered and the network connection with the server can be closed.

[0192] It should be added that, referring to Figure 5 The client initialization and logout process may include the following steps:

[0193] Step 501: The client library is loaded and executed by the user program, preparing for the environment initialization of the software encryption machine client.

[0194] Step 502: Since the software encryption machine client is provided as a .so library file, the server's IP address and other information cannot be hard-coded into the code. Therefore, a configuration file is needed to store variable configuration information such as the server's IP address, port, and TLS communication-related items. After the client library is loaded and started, it needs to immediately attempt to access and read the configuration file, and check whether the read was successful and whether the read information is correct and valid.

[0195] Step 503: If the configuration item can be read and verified successfully, then step 504 will be executed. If an error occurs, such as the configuration file not existing, insufficient permissions to read, or a problem with the configuration item, then step 509 will be executed.

[0196] Step 504: Once the configuration is successfully read, the client will obtain the server's IP address and port information and connect to the server.

[0197] Step 505: Based on the configuration options, the client can choose to establish TLS secure communication with the server. It is important to note that both the client and server must be configured to either enable or disable TLS; otherwise, the connection will fail.

[0198] Step 506: After successfully establishing a connection with the server, the client will request a memory area to store the data passed from the interface and prepare for communication with the server. Then, the user can use the various interfaces of the encryption machine normally.

[0199] Step 507: User's normal encryption machine function interface.

[0200] Step 508: After the user finishes using the service, they call the interface to close the encryption device. Upon receiving the request, the client will first close the network connection with the server and deregister the TLS secure communication environment.

[0201] Step 509: If the configuration file reading fails, the client will return an error message to the user.

[0202] Step 510: After logging out of the environment, the client will also release the memory allocated in the previous steps to avoid memory leaks.

[0203] Step 511: After completing the preliminary steps, the client exits normally, and the encryption machine is no longer in use.

[0204] Reference Figure 6 , Figure 6 This is an execution relationship diagram of the software encryption machine scheme of the present invention, including the following steps:

[0205] Step 1: The user calls the standard encryption machine SDF interface. The encryption machine's external interface implementation module accepts the call request and verifies the passed parameters and data within the interface. After successful verification, initial data processing is performed, and a data structure for this interface is generated. This structure contains all the data variables required to complete the interface's functionality.

[0206] Step 2: Pass the data structure to the data encoding / decoding module. The data encoding / decoding module allocates the corresponding memory space according to the data size and fills and packages the data into this memory according to the predefined encoding format.

[0207] Step 3: Once the data is packaged and filled in, the network communication verification module is invoked to send the data to the server. Upon receiving the send request, the network communication module first obtains the connection handle established with the server and uses this handle to communicate with the server. The network connection is established during client / server initialization, and TLS secure communication is also established along with the network connection, generating a connection handle for subsequent communication.

[0208] Step 4: When communicating with the server, the network communication module first sends a data packet to the server. This packet contains a sequence code, variables indicating the size of subsequent data, and variables indicating the requested interface. The server relies on these variables to generate and maintain the network communication and business processing environment, and performs security operations such as replay protection and client validity verification. Then, the packaged data is read from memory and sent to the server. A loop and offset mechanism are used during the sending process to ensure that all data is sent correctly, preventing issues like data freezing due to sending failures.

[0209] Step 5: When the server receives a new client request, it calls the multi-threaded allocation / session management module to allocate the new session to a business sub-thread. The server supports multi-host / multi-client functionality by creating multiple sub-threads and handling multiple business processes within them. These sub-threads are created when the server starts and remain running continuously.

[0210] Step 6: Upon receiving a new client request, the multi-threaded allocation / session management module iterates through the structure storing sub-thread running information, checks the current working status of each business sub-thread, finds an idle sub-thread, and forwards the request to that thread for processing. The structure storing sub-thread running information is established during the initial server runtime and corresponds one-to-one with each sub-thread. It stores the sub-thread ID, the number of currently processed business (clients), a memory space pointer for receiving and storing business information, and lock variables to ensure safe multi-threaded communication, etc.

[0211] Step 7: After a client request is assigned to a business thread, the business thread begins to call the corresponding interface implementation based on the received request type and interacts directly with the network communication verification module to obtain the data required by that interface (that is, the data encoded and packaged into memory on the client). Since the data content and structure required by each interface are different, the data decoding work on the server side is implemented internally by each interface.

[0212] Step 8: After data parsing, the business thread, based on the specific interface requested by the client and the specific functional requirements within that interface, calls the corresponding algorithm implementation module or communicates with the key management module, passing the necessary parameter data to the relevant modules. The algorithm implementation module is the main module for implementing interface functions such as symmetric encryption / decryption, asymmetric encryption / decryption, and signature verification. This module supports multiple implementations and can be defined and referenced as needed, such as OpenSSL, libgcrypt, and system kernel algorithm modules. The key management module is mainly responsible for implementing key management-related interface functions.

[0213] Step 9 / Step 10: If the client request is an interface of the key management class, or an interface that requires the use of internal keys, then after the communication interface module of the key management module receives the message requesting key operation, it will call the lower-level key encryption / decryption module and key storage module to read, write, encrypt, decrypt, and perform other further processing on the key.

[0214] Step 11: After the key encryption / decryption module has decrypted the key, it returns the result to the communication interface module.

[0215] Step 12: The communication interface module returns the key data to the business thread, or the algorithm implementation module returns the completed data to the business thread.

[0216] Step 13: The business thread packages the processed data and passes it to the network communication module, ready to return it to the client.

[0217] Step 14: The server-side communication module returns the processed data to the client. This communication process is consistent with the client's request for an interface from the server, and also includes two parts: a preliminary data packet and a complete interface data packet. The preliminary data packet contains a regenerated sequence code (for identity verification and replay prevention), a data size flag variable, and an interface flag variable (used to mark the requested interface to prevent data from being mistakenly identified as a return from another interface). If an error occurs during server-side processing, the data size flag variable and the interface flag variable will change to the corresponding error code.

[0218] Step 15: The client network communication verification interface verifies the data returned by the server to ensure communication security. After confirming that there are no errors, the data is returned to the data encoding / decoding module.

[0219] Step 16: The data encoding and decoding module decodes the data returned by the server, generates the data structure required by the interface, and returns it to the interface implementation module.

[0220] Step 17: The interface implementation module further validates the data content. After confirming that the data is correct, it processes it according to the parameter requirements of the standard SDF interface and returns it to the user.

[0221] Reference Figure 7 , Figure 7 This is a complete flowchart of the data processing method based on an encryption machine according to the present invention, including the following steps:

[0222] Step 701: When the client establishes a connection with the server, the server will receive a connection creation request from the network communication interface. Since the network communication interface is added to the libevent event during server initialization, it will trigger the libevent event listener and call the pre-defined callback function to process the new connection.

[0223] Step 702: Upon receiving a new connection request, the server's main process will establish a TLS secure connection with the client according to the configuration in the configuration file.

[0224] Step 703: After establishing a connection, the server will perform a preliminary check on the connection's validity, such as checking the IP whitelist. If the client's IP is not in the whitelist, the server will return an error message and close the connection. Then it will return to the listening and waiting state for new connections.

[0225] Step 704: After the initial connection verification passes, the server's main process begins to traverse the child thread information structure to obtain and search for currently idle child threads. It's important to note that an idle child thread refers to a thread that is currently handling fewer business sessions than the set maximum single-threaded capacity. For example, if a single thread is set to handle two business sessions, then it is considered idle if it is only handling one. The server's main process will find the thread handling the fewest business sessions and, relatively speaking, the most idle thread, and assign the connection to it.

[0226] Step 705: After selecting the business sub-thread, the server main process will obtain the pipe, the pointer to the memory storing business information, and the communication lock from its information structure, and fill the information of the new business session into the memory.

[0227] Step 706: After the new business session information is filled in, the server-side main process will send a notification to the business sub-thread via a pipe. During the information filling and notification sending process, a communication lock is used to ensure the exclusive use of relevant resources and the synchronization safety of multiple threads.

[0228] Step 707: After the notification is sent, the service allocation / session management work is completed, and the server main process returns to the waiting state to wait for new connections.

[0229] Step 708: When the server-side business sub-thread receives a notification from the main process in its pipeline, it will trigger the pre-defined libevent listener and call the corresponding callback function for processing.

[0230] Step 709: The child thread reads the pipe and the corresponding memory area storing business information, obtains the connection information of the new business session (the connection, including the TLS environment, is already established in the main process), and places the communication handle of the connection into the libevent event listener.

[0231] Step 710: At this point, the processing flow for the new business session in the business sub-thread has ended, and the sub-thread returns to the waiting state to prepare for processing new business sessions / network communication events.

[0232] Step 711: Generally, after a client establishes a connection, it will call relevant business interfaces, send business data to the server, and wait for processing and a response. Therefore, when the server receives data from the client, it will trigger the libevent network communication event listener set in step 709 and call the corresponding callback function to process the data and request.

[0233] Step 712: The child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread returns a verification error message to the client and closes the network connection.

[0234] Step 713: If the sequence code verification passes, the child thread will read the variable in the data packet that marks the length of subsequent business data, and proceed with the next step of data reception based on the variable.

[0235] Step 714: After the data reception is complete, the child thread will read the variable in the data packet that marks the requested interface, call the corresponding interface based on the variable, and pass the data received in step 713 to the interface.

[0236] Step 715: The interface parses the transmitted business data, extracts and verifies the various parameter data required by the interface. If the verification passes, it calls the corresponding underlying interface implementation to perform the actual business processing. If the verification fails, it returns the corresponding error information to the client. If the business request involves symmetric / asymmetric encryption / decryption algorithms, signature verification, or similar algorithms, the algorithm implementation module will be called for processing. If the request involves key management or requires a key in the encryption / decryption algorithm, the key management module's interface will be called to request the key.

[0237] Step 716: Once the interface has finished processing, it will return the processed data and call the network communication module to prepare to return data to the client.

[0238] Step 717: The network communication module packages the data, assembles network communication data packets according to pre-defined settings, and sends them to the client. The client receives, parses, and returns the data to the user. Then, the business sub-thread returns to a waiting state until the next pipeline notification or network communication event.

[0239] The data processing apparatus based on an encryption machine provided by the present invention is described below. The data processing apparatus based on an encryption machine described below and the data processing method based on an encryption machine described above can be referred to in correspondence.

[0240] Reference Figure 8The data processing device based on an encryption machine provided by this invention is applied to a server, wherein the server includes a main process and sub-threads, and the device includes...

[0241] The first unit 810 is used to enable the main process to receive the target request sent by the client, trigger sub-thread monitoring based on the target request, and determine the idle business sub-thread.

[0242] The second unit 820 is used by the main process to read the service data of the idle service sub-thread and write the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes a pipe, a pointer to the memory storing service information, and a communication lock.

[0243] The third unit 830 is used for the idle service sub-thread to receive the notification sent by the main process, read the memory area, and obtain the connection information of the target service session;

[0244] The fourth unit 840 is used for the idle service sub-thread to receive data packets of service data sent by the client, determine the target interface based on the target request of the client, obtain multiple parameter data required by the target interface, perform algorithm operations or key management on each parameter data, and obtain the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification;

[0245] The fifth unit 850 is used to assemble the completed data into a network communication data packet and send the network communication data packet to the client.

[0246] First, it should be noted that the server and client establish a connection through a network communication interface. When the client creates a connection with the server, the server will receive a connection creation request from the network communication interface. Since the network communication interface is added to the libevent events during server initialization, it will trigger the libevent event listener and call the pre-defined callback function to process the new connection.

[0247] In the first unit 810 mentioned above, the main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread.

[0248] It's important to note that the server's main process can iterate through the child thread information structure based on the target request sent by the client to obtain and find currently idle child threads. It's crucial to understand that an idle child thread refers to a thread that is currently handling fewer business sessions than the set maximum single-threaded capacity. For example, if a single thread is set to handle two business sessions, then it is considered idle when it is handling only one. The server's main process will find the thread handling the fewest business sessions and, relatively speaking, the most idle thread, and allocate the connection to it.

[0249] In the second unit 820, after selecting an idle business sub-thread, the server main process will obtain the pipe, the pointer to the memory storing business information, and the communication lock from its information structure, and fill the information of the new business session into the memory area.

[0250] In the third unit 830 above, after the new business session information is filled in, the server main process will send a notification to the business sub-thread through a pipe.

[0251] It should be noted that during the information filling and notification sending process, communication locks are used to ensure the exclusive use of relevant resources and the synchronization safety of multiple threads.

[0252] In Unit 4, 840, the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread returns a verification error message to the client and closes the network connection.

[0253] If the sequence code verification passes, the child thread will read the variable in the data packet that marks the length of subsequent business data, and proceed with the next step of data reception based on that variable.

[0254] After the data is received, the child thread will read the variable in the data packet that marks the requested interface, call the corresponding interface based on the variable, and pass the received data to the target interface.

[0255] The target interface parses the transmitted business data, extracts and verifies the various parameters required by the interface. If verification passes, it calls the corresponding underlying interface implementation to perform the actual business processing. If verification fails, it returns the corresponding error information to the client. If the business request involves symmetric / asymmetric encryption / decryption algorithms, signature verification, or similar algorithms, the algorithm implementation module will be called for processing. If the request involves key management or requires a key in the encryption / decryption algorithm, the key management module's interface will be called to request the key.

[0256] In the fourth unit 850 mentioned above, the network communication module packages the data, assembles network communication data packets according to pre-defined settings, and then sends them to the client. The client receives, parses, and returns the data to the user. The business sub-thread then returns to a waiting state until the next pipe notification or network communication event.

[0257] The data processing device based on an encryption machine provided by this invention receives a target request sent by a client through a main process, triggers sub-thread monitoring based on the target request, and determines an idle service sub-thread. The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks. The idle service sub-thread receives a notification sent by the main process, reads the memory area, and obtains the connection information of the target service session. The idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the client's target request, obtains multiple parameter data required by the target interface, performs algorithm calculations or key management on each parameter data, and obtains the completed data. The algorithm calculations include at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification. The completed data is assembled into a network communication data packet and sent to the client. This invention, based on the high concurrency and high encryption / decryption performance requirements of a hardware encryption machine, combines the characteristics of software design to achieve a high degree of customizability and scalability, low environmental requirements, and low cost, thus avoiding the limitations of existing hardware encryption machines.

[0258] It is understood that this embodiment describes the specific process of data parsing for the target interface.

[0259] First, the idle service sub-thread reads the first data packet of the service data and confirms that the checksum of the first data packet is correct. It then reads the first variable in the data packet that marks the length of subsequent service data. Otherwise, if the checksum of the first data packet is determined to be incorrect or invalid, the sub-thread will return a checksum error message to the client and close the network connection. Next, the idle service sub-thread reads the second variable in the data packet that marks the requested interface, and calls the target interface based on the second variable to pass the service data to the target interface.

[0260] It should be noted that the target interface is selected from the interface module for communication between the business processing module on the server side based on the second variable.

[0261] Finally, the idle business sub-thread parses the business data at the target interface to obtain the multiple parameter data required by the target interface. This parameter data can be used for data processing by multiple business processing modules.

[0262] Specifically, the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread returns a verification error message to the client and closes the network connection.

[0263] If the sequence code verification passes, the child thread will read the variable in the data packet that marks the length of subsequent business data, and proceed with the next step of data reception based on that variable.

[0264] After the data is received, the child thread will read the variable in the data packet that marks the requested interface, call the corresponding interface based on the variable, and pass the received data to the target interface.

[0265] The target interface parses the transmitted business data, extracts and verifies the various parameters required by the interface. If verification passes, it calls the corresponding underlying interface implementation to perform the actual business processing. If verification fails, it returns the corresponding error information to the client. If the business request involves symmetric / asymmetric encryption / decryption algorithms, signature verification, or similar algorithms, the algorithm implementation module will be called for processing. If the request involves key management or requires a key in the encryption / decryption algorithm, the key management module's interface will be called to request the key.

[0266] In some embodiments, the main process receives a target request sent by the client, triggers sub-thread monitoring based on the target request, and determines idle service sub-threads, including...

[0267] The server receives the target request sent by the client and establishes a Transport Layer Security (TLS) connection with the client based on the configuration information in the configuration file.

[0268] The server verifies the connection is valid and iterates through all the sub-thread information structures to determine the idle business sub-thread.

[0269] The idle service sub-thread is a sub-thread that is currently carrying fewer services than the set maximum single-thread capacity.

[0270] It should be noted that, in this embodiment, before selecting an idle service sub-thread, the server-side main process needs to establish a TLS secure connection with the client according to the configuration in the configuration file.

[0271] After a connection is established, the server will perform a preliminary check on the connection's validity, such as checking the IP whitelist. If the client's IP is not in the whitelist, the server will return an error message and close the connection. Then it will return to listening and waiting for new connections.

[0272] In some embodiments, after the idle service sub-thread receives the notification sent by the main process, reads the memory region, and obtains the connection information of the target service session, it further includes...

[0273] The main process returns to a waiting state to determine if there is a new target client connection.

[0274] The sub-thread returns to a waiting state to handle new business sessions or network communication events.

[0275] Understandably, once the notification is sent, the relevant work of the business allocation / session management module is completed, and the server main process returns to the waiting state to await new connections.

[0276] Furthermore, after the processing flow for a new business session in the business sub-thread is completed, the sub-thread returns to the waiting state to prepare for processing new business sessions / network communication events.

[0277] In some embodiments, after the idle service sub-thread receives the data packet of service data sent by the client, it further includes...

[0278] The idle service sub-thread triggers network communication event monitoring, calls the callback function corresponding to the client, and processes the data packet and the notification based on the callback function.

[0279] Understandably, when the server-side business sub-thread receives a notification from the main process in its pipeline, it will trigger the pre-defined libevent listener and call the corresponding callback function for processing.

[0280] The child thread reads the pipe and the corresponding memory area storing business information, obtains the connection information of the new business session (the connection, including the TLS environment, is already established in the main process), and places the communication handle of the connection into the libevent event listener.

[0281] In some embodiments, it also includes,

[0282] The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is incorrect, sends the check error information to the client, and closes the network connection.

[0283] It should be noted that the child thread first verifies the first data packet sent by the client, checking the validity of the data packet and the client using the sequence code variable. If the sequence code is invalid, the child thread will return a verification error message to the client and close the network connection.

[0284] In some embodiments, before the main process receives a target request sent by the client, triggers sub-thread monitoring based on the target request, and determines an idle service sub-thread, it further includes...

[0285] The server-side business processing module is initialized to enable network communication verification with the client, multi-thread allocation, encryption / decryption operations, and key management.

[0286] After assembling the completed data into a network communication data packet and sending the data packet to the client, the process further includes...

[0287] Close the network connection with the client and exit the main process and all sub-threads.

[0288] Understandably, before the main thread receives requests and selects idle business sub-threads, the server-side business processing module needs to be initialized to enable functions such as network communication verification with the client, multi-sub-thread allocation, encryption and decryption operations, and key management.

[0289] Furthermore, after the idle service sub-thread finishes, the network connection with the client can be closed promptly, and the current network communication connection and network interface listening can be shut down. This means unregistering each libevent event listener, including network and pipe communication events. Then, the main process / sub-thread will release the allocated memory to avoid memory leaks and data leaks. Finally, the main process / sub-thread exits normally.

[0290] In some embodiments, it also includes,

[0291] Based on the SELinux security mechanism, the business data and key storage are protected.

[0292] Reference Figure 9 The data processing device based on an encryption machine provided by this invention is applied to a client and includes:

[0293] Unit 6, 910, is used to send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0294] Unit 7, 920, is used to receive network communication data packets sent by the idle service sub-thread.

[0295] In the sixth unit 910 above, a target request is sent to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads.

[0296] It's important to note that when the client sends a target request to the server's main process, the server's main process can iterate through the child thread information structure based on the client's request to find currently idle child threads. It's crucial to understand that an idle child thread is one that is currently handling fewer business sessions than the maximum allowed per thread. For example, if a single thread is set to handle two business sessions, it's considered idle if it's only handling one. The server's main process will then find the thread handling the fewest business sessions and, relatively speaking, the least idle thread, and allocate the connection to it.

[0297] In Unit 7 (920) mentioned above, the network communication module packages the data, assembles network communication data packets according to pre-defined settings, and then sends them to the client. The client receives, parses, and returns the data to the user. The business sub-thread then returns to a waiting state until the next pipe notification or network communication event.

[0298] It should be noted that in this embodiment, the server-side communication module returns the processed data to the client. This communication process is consistent with the communication process when the client requests an interface from the server, and also includes two parts: a preliminary data packet and a complete interface data packet. The preliminary data packet contains a regenerated sequence code (for identity verification and to prevent replay), a data size flag variable, and an interface flag variable (used to mark the requested interface to avoid the data being mistakenly identified as a return from another interface).

[0299] If an error occurs during server-side processing, the data size flag variable and the interface flag variable will change to error codes accordingly.

[0300] The client-side network communication verification interface validates the data returned by the server to ensure communication security. After verification, the data is returned to the data encoding / decoding module. The data encoding / decoding module decodes the server-side data, generates the data structure required by the interface, and returns it to the interface implementation module. The interface implementation module further validates the data content. After confirming the data is correct, it processes it according to the parameter requirements of the standard SDF interface and returns it to the user.

[0301] In some embodiments, before sending the target request to the main process of the server, the method further includes initializing the encryption machine of the client to implement the encoding, data encoding and decoding module of the external standard interface and network communication verification.

[0302] After receiving the network communication data packet sent by the idle service sub-thread, the process also includes deregistering the TLS environment and closing the network connection with the server.

[0303] Understandably, the client needs to be initialized before sending a request to the server. This initialization of the client's encryption mechanism is necessary to enable encoding, data encoding / decoding modules, and network communication verification for the external standard interface.

[0304] Furthermore, after the idle service sub-thread ends, the TLS environment can be deregistered and the network connection with the server can be closed.

[0305] Figure 10 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 10 As shown, the electronic device may include a processor 1010, a communications interface 1020, a memory 1030, and a communication bus 1040. The processor 1010, communications interface 1020, and memory 1030 communicate with each other via the communication bus 1040. The processor 1010 can call logical instructions in the memory 1030 to execute a data processing method based on an encryption machine. This method includes the main process receiving a target request sent by a client, triggering sub-thread monitoring based on the target request, and determining idle service sub-threads.

[0306] The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks.

[0307] The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session;

[0308] The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the target request of the client, obtains multiple parameter data required by the target interface, performs algorithm operation or key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption or signature verification;

[0309] The completed data is assembled into a network communication data packet, and the network communication data packet is sent to the client.

[0310] Furthermore, the logical instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0311] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the data processing method based on the encryption machine provided by the above methods, the method including...

[0312] The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread.

[0313] The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks.

[0314] The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session;

[0315] The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the target request of the client, obtains multiple parameter data required by the target interface, performs algorithm operation or key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption or signature verification;

[0316] The completed data is assembled into a network communication data packet, and the network communication data packet is sent to the client.

[0317] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the data processing method based on the encryption machine provided by the above methods, the method comprising:

[0318] The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread.

[0319] The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks.

[0320] The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session;

[0321] The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the target request of the client, obtains multiple parameter data required by the target interface, performs algorithm operation or key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption or signature verification;

[0322] The completed data is assembled into a network communication data packet, and the network communication data packet is sent to the client.

[0323] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0324] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0325] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data processing method based on an encryption machine, characterized in that, Applied to a server-side application, wherein the server-side includes a main process and child threads, the method includes: The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread, including: the server receives the target request sent by the client, and establishes a Transport Layer Security (TLS) connection with the client based on the configuration information in the configuration file; The main process reads the service data of the idle service sub-thread and writes the session information of the target service into the memory area of ​​the idle service sub-thread. The service data includes pipes, pointers to memory storing service information, and communication locks. The idle service sub-thread receives the notification sent by the main process, reads the memory area, and obtains the connection information of the target service session; The idle service sub-thread receives data packets of service data sent by the client, determines the target interface based on the client's target request, obtains multiple parameter data required by the target interface, performs algorithm operations or performs key management on each parameter data, and obtains the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification; the service data and key storage are protected by the SELinux security mechanism; The completed data is assembled into a network communication data packet, and the network communication data packet is sent to the client.

2. The data processing method based on an encryption machine according to claim 1, characterized in that, The idle service sub-thread receives the data packet of service data sent by the client, determines the target interface based on the client's target request, and obtains multiple parameter data required by the target interface, including: The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is correct, and reads the first variable in the data packet that marks the length of subsequent service data; The idle service sub-thread reads the second variable marking the request interface in the data packet, and calls the target interface based on the second variable to pass the service data to the target interface; The target interface of the idle business sub-thread parses the business data to obtain multiple parameter data required by the target interface.

3. The data processing method based on an encryption machine according to claim 1, characterized in that, The main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines idle business sub-threads, including: The server verifies the connection is valid and iterates through all the sub-thread information structures to determine the idle business sub-thread. The idle service sub-thread is a sub-thread that is currently carrying fewer services than the set maximum single-thread capacity.

4. The data processing method based on an encryption machine according to claim 1, characterized in that, After receiving the notification sent by the main process, reading the memory region, and obtaining the connection information of the target service session, the idle service sub-thread further includes: The main process returns to a waiting state to determine if there is a new target client connection. The sub-thread returns to a waiting state to handle new business sessions or network communication events.

5. The data processing method based on an encryption machine according to claim 4, characterized in that... After the idle service sub-thread receives the data packet of service data sent by the client, it also includes: The idle service sub-thread triggers network communication event monitoring, calls the callback function corresponding to the client, and processes the data packet and the notification based on the callback function.

6. The data processing method based on an encryption machine according to claim 2, characterized in that, Also includes: The idle service sub-thread reads the first data packet of the service data, determines that the check sequence code of the first data packet is incorrect, sends the check error information to the client, and closes the network connection.

7. The data processing method based on an encryption machine according to claim 1, characterized in that, Before the main process receives the target request sent by the client, triggers sub-thread monitoring based on the target request, and determines the idle business sub-thread, the process further includes: The server-side business processing module is initialized to enable network communication verification with the client, multi-thread allocation, encryption / decryption operations, and key management. After assembling the completed data into a network communication data packet and sending the data packet to the client, the process further includes: Close the network connection with the client and exit the main process and all sub-threads.

8. A data processing method based on an encryption machine, characterized in that, Applied to the client side, including: Send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads. Receive network communication data packets sent by the idle service sub-thread.

9. The data processing method based on an encryption machine according to claim 8, characterized in that, After receiving the network communication data packet sent by the idle service sub-thread, the method further includes: The network communication data packets are verified, and those that meet the verification criteria are decoded to obtain the data structure required by the interface. The data structure is subjected to secondary verification based on the interface. The network communication data that meets the secondary verification standard is processed based on the interface parameters to obtain the target data. The target data is then returned to the user.

10. The data processing method based on an encryption machine according to claim 8, characterized in that, Before sending the target request to the server's main process, the process also includes: The client's encryption device is initialized to enable the encoding, data encoding / decoding modules, and network communication verification for the external standard interface. After receiving the network communication data packet sent by the idle service sub-thread, the method further includes: Disconnect from the TLS environment and close the network connection with the server.

11. A data processing device based on an encryption machine, characterized in that, Applied to a server, the server includes a main process and child threads, and the device includes: The first unit is used to enable the main process to receive the target request sent by the client, trigger sub-thread monitoring based on the target request, and determine the idle business sub-thread, including: the server receiving the target request sent by the client, and establishing a Transport Layer Security (TLS) connection with the client based on the configuration information in the configuration file; The second unit is used by the main process to read the business data of the idle business sub-thread and write the session information of the target business into the memory area of ​​the idle business sub-thread. The business data includes pipes, pointers to memory storing business information, and communication locks. The third unit is used for the idle service sub-thread to receive the notification sent by the main process, read the memory area, and obtain the connection information of the target service session; The fourth unit is used for the idle service sub-thread to receive data packets of service data sent by the client, determine the target interface based on the client's target request, obtain multiple parameter data required by the target interface, perform algorithm operations or key management on each parameter data, and obtain the completed data; the algorithm operation includes at least one of symmetric encryption / decryption, asymmetric encryption / decryption, or signature verification; based on the SELinux security mechanism, the service data and key storage are protected for security. The fifth unit is used to assemble the completed data into a network communication data packet and send the network communication data packet to the client.

12. A data processing device based on an encryption machine, characterized in that, Applied to the client side, including: The sixth unit is used to send a target request to the main process of the server. The target request is used to trigger the monitoring of the sub-threads of the main process to determine the idle business sub-threads. The seventh unit is used to receive network communication data packets sent by the idle service sub-thread.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the data processing method based on the encryption machine as described in any one of claims 1 to 7, or the data processing method based on the encryption machine as described in any one of claims 8 to 10.

14. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data processing method based on the encryption machine as described in any one of claims 1 to 7, or implements the data processing method based on the encryption machine as described in any one of claims 8 to 10.

Images