Secure USB chip-level hardware encryption system and secure communication and file encryption method

Abstract

The application discloses a secure USB chip-level hardware encryption system and a secure communication and file encryption method. The system comprises a USB chip-level hardware encryption module, which generates a user certificate, combines a true random number generator with an SM2 algorithm to ensure the uniqueness of a key pair, and securely stores a private key in the hardware. The system is composed of an application program, a driver program, an operating system, a storage module and a communication module. The application program is responsible for UI interaction, multitask management and device authentication operations, and integrates user demand and system resources; the driver program supports file management and cursor calculation; the operating system guarantees the software running environment; the storage module saves user data; and the communication module serves as a bridge for information exchange, promotes the communication between the user terminal software and the USB encryption module, and ensures the security and efficiency of data transmission. Through the implementation of the system of the application, the user experience is improved and the data protection level is strengthened.

Description

Technical Field

[0002] This invention relates to hardware encryption systems, and more specifically to secure USB chip-level hardware encryption systems and secure communication and file encryption methods. Background Technology

[0004] Currently, document encryption software is mainly divided into two categories: pure software and hardware / software hybrid. Each type has its own characteristics, but also faces its own challenges.

[0005] Pure software encryption schemes primarily rely on keys and specific algorithms to encrypt documents. A key characteristic of these schemes is that key generation, storage, and encryption / decryption operations are all performed within the operating system's memory. While this approach meets certain security requirements, the direct processing of keys and sensitive data in computer memory makes them vulnerable to malware or hacker attacks, leading to potential security vulnerabilities. In contrast to pure software schemes, hardware-software hybrid encryption schemes combine hardware and software to implement encryption and decryption operations. Typically, this type of solution is deployed in a network version, where encryption keys, sensitive data, algorithms, and other critical information are stored on a dedicated encryption card within an encryption server, and all encryption / decryption operations are performed on this encryption card. Although this method improves data security, some issues remain in practical applications. For example, when an encrypted document is sent to another product, an additional encryption key is required for decryption. This not only increases operational complexity but also makes it difficult to ensure that the entire transmission process remains fully encrypted, thus impacting the user's seamless reading experience.

[0006] In conclusion, existing document encryption technologies, whether purely software-based or a combination of hardware and software, have certain limitations. In particular, they struggle to achieve an ideal balance between ensuring data security and user convenience.

[0007] Therefore, it is necessary to design a new system that can support effective decryption under specified conditions while ensuring high security, and enable unimpeded reading of ciphertext, thereby improving user experience and strengthening data protection. This system should fully leverage the advantages of hardware encryption while simplifying key management and data exchange processes to ensure data security throughout its entire lifecycle. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art and provide a secure USB chip-level hardware encryption system and a secure communication and file encryption method.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: a secure USB chip-level hardware encryption system, comprising: user terminal software, a USB chip-level hardware encryption module, and a communication module;

[0011] The USB chip-level hardware encryption module is used to generate user certificates. It is specified that the user certificate is generated by combining the true random number generator built into the chip with the SM2 key pair generation algorithm. A USB module contains only one valid public-private key pair, and the private key is restricted to the internal hardware.

[0012] Each of the aforementioned user terminal software includes an application program, a driver program, an operating system, a storage module, and a communication module;

[0013] The application is responsible for the UI interaction functions of user behavior and tasks, monitors the priority and mutual exclusion relationship of multiple tasks, and executes corresponding actions. The execution actions of the application include device authentication, certificate management, task navigation, and information display of the USB chip-level encryption module, and are connected in series with the USB chip-level hardware encryption module, system files or messages, and user needs.

[0014] The driver program is used to perceive user behavior in file operations, and also manages the file system, splits file content into segments, and calculates cursor offsets.

[0015] The operating system is used to support the normal operation of user terminal applications;

[0016] The storage module is used to store user information or related files;

[0017] The communication module serves as a bridge for message transmission between the kernel and the user.

[0018] The communication module is used for communication between the user terminal software and the USB chip-level hardware encryption module.

[0019] The further technical solution is as follows: The USB chip-level hardware encryption module includes the national cryptographic algorithms SM1, SM2, SM3, and SM4, a true random function generator, and related containers. SM1 and SM4 are used for symmetric encryption and decryption, SM3 is used for hash verification, SM2 is used for asymmetric encryption and decryption, and the random number generator is used to generate random numbers that meet the specified requirements. It also performs SM4 encryption on the data content of the encrypted file when the user starts encryption, and SM2 public key encryption on the encryption key and exports it to the chip. When the user starts decryption, the content to be decrypted is first decrypted using the SM2 private key to restore the encryption key. The restored encryption key is not exported from the chip and is used for internal verification of the USB chip. After the decryption verification is passed, the decryption state is started, the incoming content is decrypted using the decryption key using SM4, and the result is exported from the USB chip. The storage module stores the user's necessary files or corresponding communication encryption certificates.

[0020] The further technical solution is as follows: the USB chip-level hardware encryption module performs symmetric and asymmetric hybrid encryption on the data content of the encrypted file according to the internal process and state control of the USB chip, so as to obtain a combination of encrypted content and verification information with mutual verification function.

[0021] The present invention also provides a secure communication and file encryption method for the above-mentioned secure USB chip-level hardware encryption system, comprising:

[0022] The system generates and initializes a USB chip-level hardware module containing a unique SM2 public-private key pair. The first client generates an encrypted SM2 certificate and shares it with the second client over the network. The second client imports the SM2 certificate for interactive use.

[0023] The second client receives encrypted information and key decryption information, and securely processes the key decryption information through a USB chip-level hardware module to ensure that the key decryption information is sealed within the hardware.

[0024] Encryption keys are generated and managed on a USB chip-level hardware module. The first client receives encrypted information while ensuring the security of public and private keys to support encryption and decryption operations.

[0025] The first client uses a USB chip-level hardware module to generate and export an SM2 certificate. After verification, the second client imports the verified certificate into the application, selects the certificate to encrypt files or folders, and saves the encrypted files to a specified location.

[0026] Insert the USB chip-level hardware module and prepare the decryption environment. Verify the validity of the encryption key and decrypt the file using the SM2 private key. After decryption, replace the original encrypted file or retain the original encrypted file if decryption fails.

[0027] The further technical solution is as follows: The production and initialization of a USB chip-level hardware module containing a unique SM2 public / private key pair; the first client generates an encrypted SM2 certificate and shares it with the second client over the network; the second client imports the SM2 certificate for interactive use, including:

[0028] The USB chip-level hardware module is manufactured and initialized, and a unique random key pair is generated through the USB chip-level hardware module.

[0029] The first client generates an SM2 certificate through the application software, encrypts and exports it, and saves it in the storage module or other easily accessible location;

[0030] Distribute SM2 certificates using any network or LAN tool;

[0031] The second client receives the SM2 certificate and imports it into the software to complete the interaction.

[0032] Its further technical solution is as follows: The second client receives encrypted information and key decryption information, and securely processes the key decryption information through a USB chip-level hardware module to ensure that the key decryption information is sealed within the hardware, including:

[0033] When the second client receives encrypted content, it obtains the decryption key information associated with the encrypted content, wherein the decryption key information includes the encryption public key information and the encryption key information of the second client.

[0034] The key decryption information is transmitted as a whole to the USB chip-level hardware module, and the key decryption information is decrypted. The decryption result is then stored in the USB chip-level hardware module and is not transmitted out of the USB chip-level hardware module throughout the entire lifecycle of the key.

[0035] The further technical solution is as follows: The encryption key is generated and managed on the USB chip-level hardware module; the first client receives the encrypted information; and the security of the public and private keys is ensured to support encryption and decryption operations, including:

[0036] Generate chip-level encryption keys and encrypted encryption keys through a USB chip-level hardware module;

[0037] The encryption key derived from the encrypted encryption key, as well as the encrypted content and information encrypted to the chip-level hardware;

[0038] The first client receives the encryption key, encrypted content, and encrypted information from the above, and uses the decryption key to decrypt the encrypted content to generate decrypted content. The decryption key, the encrypted content, and the encrypted information correspond to the first client's encryption key, encrypted encryption key, session information, or session content, respectively, and are encrypted by a USB chip-level hardware module. The encryption key is derived from the encryption by the USB chip-level hardware module, and the session key is used to encrypt the session content data.

[0039] The further technical solution is as follows: The first client uses a USB chip-level hardware module to generate and export an SM2 certificate. After verification, the second client imports the verified certificate into the application, selects the certificate to encrypt files or folders, and saves the encrypted files to a specified location, including:

[0040] The USB chip-level hardware module distributes and creates SM2 certificates to ensure the uniqueness of key pairs. The key pair exports the public key outside the chip through the application's interface to form an encryption certificate, while the private key is permanently stored inside the chip.

[0041] The first client distributes the exported SM2 certificate to the corresponding second client through communication software or other tools;

[0042] The second client receives the encryption certificate, determines its validity, and imports it into the application. The application then displays the first client's SM2 certificate or a list of SM2 certificates.

[0043] When the second client triggers encrypted communication, the application starts the certificate selection interface, selects the corresponding user certificate through radio buttons, and transmits the public key information in the corresponding user certificate to the USB chip-level hardware module to realize the chip task mode conversion.

[0044] After switching to encrypted transmission mode, the application guides the second client to select the file that needs to be communicated in encrypted form;

[0045] After receiving the files or folders specified by the user, the second client categorizes the files and manages them through a list.

[0046] The file is segmented and encrypted using a USB chip-level hardware module with SM4 symmetric encryption. The encryption key is generated by a true random number and encrypted with an SM2 certificate before being stored in the chip. After encryption, the file is saved to a specified location. If the integrity check fails, the temporary file is deleted.

[0047] The further technical solution is as follows: the file is segmented and encrypted using a USB chip-level hardware module with SM4 symmetric encryption. The encryption key is generated by a true random number and encrypted with an SM2 certificate before being stored in the chip. After encryption, the file is saved to a designated location. If the integrity check fails, a temporary file is deleted, including:

[0048] The application processes the first file, dividing it into several parts according to the rules of the file system;

[0049] Several data sets are sequentially transmitted to the USB chip-level hardware module in a concatenated manner. The module will generate a set of SM4 encryption keys corresponding to the first client user, generated by a true random function generator, according to the chip task mode. The SM4 encryption key will be encrypted using SM2 according to the public key in the first client certificate to obtain an encrypted encryption key. The encrypted encryption key will be imported into the chip and will not leave the chip, but will remain in the chip. The chip's state will be set to the pre-encryption ready state, and the application software will be set to the waiting return state.

[0050] The application software of the second client writes the encrypted encryption key information transmitted from the USB chip-level hardware module to a specified location in the intermediate temporary file.

[0051] The application sends the segmented file content to the USB chip-level hardware module in a queue. The USB chip-level hardware module performs SM4 symmetric encryption on the encrypted content according to a pre-set process. The entire process and encryption key are all locked inside the chip, and the outside world cannot obtain its important encryption key, encryption process, or memory information during encryption.

[0052] The USB chip-level hardware module transmits the encrypted content to the application, which then stores the encrypted content in a suitable location in a temporary file.

[0053] After the application saves one copy, it continues to transmit the next encrypted message until the entire file is processed. The application then checks the integrity of the encryption and, based on the result, places the encrypted communication file in a specified location or deletes a temporary file.

[0054] Its further technical solution is as follows: inserting the USB chip-level hardware module and preparing the decryption environment, verifying the legality of the encryption key and decrypting the file using the SM2 private key, replacing the original encrypted file after decryption or retaining the original encrypted file in case of failure, including:

[0055] The first client inserts the USB chip-level hardware module and initializes it through the application, entering a decryption waiting state.

[0056] The first client user navigates through the UI interface, selects the file to be decrypted, and the application enters the decryption process.

[0057] The application selects the file or folder from the first client and organizes the task file list;

[0058] The first client obtains the file information that needs to be decrypted, and performs private key verification and legality verification processes using the encrypted key brought in by A093;

[0059] After the first client verification is completed, the encrypted encryption key is decrypted into plaintext using the SM2 private key. The plaintext encryption key is strictly controlled to prevent it from being transmitted out of the USB chip-level hardware module. It is fixed in the USB chip-level hardware module, and the USB chip-level hardware module is set to the state of pending encryption.

[0060] The first client application splits the file that needs to be decrypted into several parts and sends them to the USB chip-level hardware module for decryption processing in sequence.

[0061] The USB chip-level hardware module transmits the decrypted file content to the first client application, which then stores the decrypted content in a temporary file.

[0062] After the first client application saves a copy, it continues the process of decrypting the next piece of content until the entire file is executed.

[0063] After the first client completes decryption, the application checks the integrity of the decryption. Based on the check result, it deletes the encrypted communication file and modifies the plaintext file to the corresponding file name to replace the encrypted file. Alternatively, it deletes the temporary file and retains the original encrypted file.

[0064] The advantages of this invention compared to existing technologies are as follows: By integrating user terminal software, a USB chip-level hardware encryption module, and a communication module, this invention utilizes a unique public-private key pair generated and restricted internally by the hardware, along with a true random number generator, to ensure high security while supporting effective decryption under specified conditions. The user terminal software includes an application program, driver, operating system, storage module, and communication module, achieving comprehensive coverage from UI interaction to file operations, supporting functions such as device authentication and certificate management, and simplifying key management and data exchange processes. The application program is responsible for connecting the hardware encryption module with system or user requirements, while the driver program manages the splitting and calculation of the file system. The operating system ensures the normal operation of the application, the storage module stores user data, and the communication module acts as a bridge for message transmission between the kernel and the user, ensuring smooth and secure information transmission. The entire system fully leverages the advantages of hardware encryption, ensuring data security throughout its entire lifecycle while enabling unimpeded reading of ciphertext under specified conditions, greatly improving the user experience and strengthening data protection. Thus, even if there are security vulnerabilities in the external environment, sensitive data can only be accessed and decrypted in specific trusted environments, effectively protecting data security and privacy.

[0065] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0067] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0068] Figure 1 A schematic block diagram of a secure USB chip-level hardware encryption system provided in an embodiment of the present invention;

[0069] Figure 2 A flowchart illustrating the secure communication and file encryption method of the secure USB chip-level hardware encryption system provided in this embodiment of the invention;

[0070] Figure 3 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0072] The technical solutions of the embodiments of the present 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 the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0073] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0074] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0075] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0076] Please see Figure 1 , Figure 1 This is a schematic block diagram of a secure USB chip-level hardware encryption system 100 provided in an embodiment of the present invention. This secure USB chip-level hardware encryption system integrates user terminal software and a USB chip-level hardware encryption module, utilizing Chinese national cryptographic algorithms (SM1, SM2, SM3, SM4) to achieve secure encryption and decryption of files. The system uses a true random number generator to generate keys and employs the SM2 algorithm to ensure key security during transmission and storage, while ensuring the private key is permanently sealed within the hardware and not leaked. During encryption, the file is segmented and encrypted using SM4 symmetric encryption via the USB module, while the encryption key is encrypted with an SM2 certificate and stored, ensuring that temporary files can be securely deleted even if integrity checks fail, preventing data leakage. During decryption, the SM2 private key is verified to confirm key legitimacy, and the decryption process is completed within the USB module, ensuring that the key and decryption process are transparent and secure to the outside world. The entire system design aims to simplify key management, enhance the security of data exchange, improve user experience, and ensure a high level of protection for data throughout its entire lifecycle from generation to destruction. This method fully utilizes the advantages of hardware encryption's immutability and high security, achieving the goal of unimpeded reading and effective decryption of ciphertext.

[0077] In this embodiment, the application includes: the operating system and the driver.

[0078] Operating system: refers to Windows, domestic operating systems (Kylin, UOS)

[0079] USB chip-level hardware module: The medium is a hardware USB flash drive that can be inserted into a USB port. Before using the USB chip-level hardware module, the user will perform necessary initialization at the factory. This mainly involves generating a unique SM2 key pair and other related password initializations, which will then be fixed in the USB chip-level hardware module.

[0080] User public key: The public key certificate in the certificate of the USB chip-level hardware module, which the application obtains through the USB chip-level hardware module interface.

[0081] User private key: A unique private key within the USB chip-level hardware module. It is prohibited from being transmitted out of the USB chip-level hardware module and its contents cannot be obtained or read by any means.

[0082] Encryption Certificate: The public key of SM2 in the USB chip-level hardware module is transmitted out of the USB chip-level hardware module after being encrypted by an internal mechanism. The application can read the encrypted public key information of its contents.

[0083] SM2 algorithm: Asymmetric encryption or decryption using Chinese national cryptographic algorithms.

[0084] SM1 and SM4 algorithms: These algorithms utilize national cryptographic algorithms to achieve symmetric encryption or decryption.

[0085] SM3 algorithm: Hash verification is achieved using Chinese cryptographic algorithms.

[0086] Driver: A predictive judgment based on user operation files, assisting the application in predicting user behavior.

[0087] Please see Figure 1 A secure USB chip-level hardware encryption system 100 includes: user terminal software 101, USB chip-level hardware encryption module 102, and communication module 103.

[0088] The USB chip-level hardware encryption module 102 is used to generate user certificates. It is specified that the user certificate is generated by combining the true random number generator and the SM2 key pair generation algorithm in the chip. A USB module contains only one valid public-private key pair, and the private key is restricted to the hardware.

[0089] Each of the user terminal software 101 includes an application program, a driver program, an operating system, a storage module, and a communication module 103;

[0090] The application is responsible for the UI interaction functions of user behavior and tasks, monitors the priority and mutual exclusion relationship of multiple tasks, and executes corresponding actions. The execution actions of the application include device authentication, certificate management, task navigation, and information display of the USB chip-level encryption module, and are connected in series with the USB chip-level hardware encryption module 102, system files or messages, and user needs.

[0091] The driver program is used to perceive user behavior in file operations, and also manages the file system, splits file content into segments, and calculates cursor offsets.

[0092] The operating system is used to support the normal operation of user terminal applications;

[0093] The storage module is used to store user information or related files;

[0094] The communication module 103 serves as a bridge for message transmission between the kernel and the user.

[0095] The communication module 103 is used for communication between the user terminal software 101 and the USB chip-level hardware encryption module 102.

[0096] The USB chip-level hardware encryption module 102 includes Chinese cryptographic algorithms SM1, SM2, SM3, and SM4, a true random function generator, and related containers. SM1 and SM4 are used for symmetric encryption and decryption, SM3 is used for hash verification, and SM2 is used for asymmetric encryption and decryption. The random number generator is used to generate random numbers that meet the specified requirements, and also performs SM4 encryption on the data content of the encrypted file when the user initiates encryption, as well as SM2 public key encryption on the encryption key and exporting it to the chip. When the user initiates decryption, the content to be decrypted is first restored using the SM2 private key, and the restored encryption key is not exported from the chip. It is used for internal verification of the USB chip. After the decryption verification is passed, the decryption state is initiated, the incoming content is decrypted using the decryption key using SM4, and the result is exported from the USB chip. The storage module stores the user's necessary files or corresponding communication encryption certificates.

[0097] The USB chip-level hardware encryption module 102 performs symmetric and asymmetric hybrid encryption on the data content of the encrypted file according to the internal process and state control of the USB chip, resulting in a combination of encrypted content and verification information with mutual verification function.

[0098] In this embodiment, the secure USB chip-level hardware encryption system 100 is a highly integrated and secure solution designed to ensure data security during transmission and storage. The system comprises three main components: user terminal software 101, a USB chip-level hardware encryption module 102, and a communication module 103.

[0099] User terminal software 101: This part consists of application programs, drivers, operating system, storage module, and communication module 103. It is responsible for providing the user interface (UI) for interacting with and managing task priorities and mutual exclusion relationships, and implementing functions such as device authentication, certificate management, and information display. In addition, it supports file system management, handles file content splitting and offset calculation, ensures the normal operation of applications, and supports message passing between the kernel and the user terminal.

[0100] USB chip-level hardware encryption module 102: This is the core of the system. It creates unique public-private key pairs using a built-in true random number generator and the SM2 key pair generation algorithm. The private key is strictly confined within the hardware, ensuring its non-derivative and uniqueness. This module supports Chinese national cryptographic algorithms (such as SM1, SM2, SM3, and SM4), providing symmetric encryption / decryption, asymmetric encryption / decryption, and hash verification capabilities. Specifically, for encryption operations, SM4 is used to encrypt the data content, and the encryption key is encrypted using the SM2 public key. During decryption, the encryption key is first restored using the SM2 private key, and then this key is used for SM4 decryption.

[0101] Communication module 103: As a bridge connecting the user terminal software 101 and the USB chip-level hardware encryption module 102, the communication module 103 ensures smooth information exchange between the two and is a key link in realizing the collaborative work of the entire system.

[0102] The encryption process is summarized as follows:

[0103] Obtaining and importing encryption public key certificates: First, the system needs to obtain the encryption public key certificates of all participating terminals and import them into a business card management list. This step ensures that the appropriate public key certificate can be correctly selected during subsequent communications.

[0104] Select a public key certificate and verify its legitimacy: Select the target terminal's public key certificate from the business card management list and verify its legitimacy. Only after the certificate is confirmed to be legitimate will it be imported into the USB drive for encrypted communication.

[0105] Encrypt the file and send the ciphertext: A one-time pad seed key is generated using the hardware encryption module within the USB drive, and this key, combined with the selected public key certificate, is used to encrypt the file. The encrypted ciphertext is then sent to the designated receiving terminal.

[0106] Decrypting the ciphertext: The recipient uses the private key stored on the USB drive to decrypt the received ciphertext and recover the original file content. The entire decryption process is also completed within the USB chip-level hardware module of the USB drive, ensuring the security of the key and the encrypted content.

[0107] This design fully leverages the advantages of hardware encryption, simplifies key management, and enhances data protection throughout its entire lifecycle. Even if the encrypted data is intercepted, unauthorized third parties will find it difficult to access or decrypt it. This approach not only improves the user experience but also provides robust protection for data security.

[0108] In this embodiment, only file encryption and decryption are performed within the USB drive; all other operations are performed on the terminal. The product supports seamless encrypted communication, meaning user A can send encrypted files to user B as needed, and the files are transmitted and entered in an encrypted state. User B can then read the encrypted files on their own computer without any issues. Furthermore, the encrypted files can only be decrypted on the computer where the certificate was generated, with the USB drive connected to the system via USB. A one-time key is used; each time an encrypted file for encrypted communication is generated, the key is generated by a random function generator within the USB chip-level hardware module of the USB drive. Matching and transmission are performed by the recipient sending an SM2 encrypted public key certificate, which is imported once and used multiple times. The generation and verification of the SM2 encrypted public key certificate are all done using random numbers generated by the security chip's random function generator, ensuring the uniqueness of each USB drive's public and private keys. The USB drive's private key remains within the USB chip-level hardware module from generation to the end of its lifecycle. The entire decryption process of the encrypted key is performed within the USB chip-level hardware module of the USB drive; the entire process does not leave the USB chip-level hardware module. The decryption session key is obtained from the generated encryption key through the internal processing mechanism of the USB flash drive. The plaintext key never leaves the USB flash drive's chip-level hardware module. The entire decryption process is completed within the USB flash drive's chip-level hardware module; the entire decryption process does not leave the USB flash drive's chip-level hardware module. All encryption keys, encryption / decryption operations, and management are completed within the security chip. The plaintext key never leaves the USB flash drive hardware, ensuring product security, reliability, and compliance.

[0109] In this embodiment, the public key certificate is generated via a USB flash drive connected to the terminal. Upon initial firmware flashing and power-on, a communication SM2 key pair is generated, and the public key information is encrypted to create an encrypted certificate. During the initial secure installation on the terminal, the USB flash drive is bound to the encryption software and further bound to the host hardware. At this point, the encrypted public key certificate for encrypted communication can be exported. The content of the encrypted public key certificate includes not only user-defined information but also the user's personal information such as name and organization. Each USB flash drive's private key is a set of passwords generated by the security chip's random function generator, ensuring that the private key never leaves the hardware encryption chip throughout its lifecycle. The published encrypted public key can only be used for encryption functions. The encrypted communication process will only continue after the encrypted public key certificate is successfully sent; otherwise, the process ends.

[0110] Select the terminal that needs to conduct encrypted communication from the business card management list, and determine the corresponding public key certificate.

[0111] Determine if the encrypted public key certificate is valid. If the public key certificate is valid, select it and import its public key into the USB drive. The encrypted communication process will only begin after the public key certificate is valid and the import is successful. The process involves the recipient sending their public key certificate for matching and transmission; the public key certificate is imported once and used multiple times.

[0112] Configure public key information for easy management, such as a person, organization, department, nickname, etc., and import public key certificates. These certificates are used by those communicating with you in encrypted form to encrypt files. The public and private keys used to generate and compare certificates are random numbers generated by the security chip's random function generator and calculated using the chip's built-in SM2 national cryptographic algorithm, ensuring the uniqueness of the public and private keys for each USB drive.

[0113] When a user selects to initiate encrypted communication, a one-time key is generated by a random generator within the USB chip-level hardware module of the USB flash drive. The USB chip-level hardware module encrypts the file using the session key. The encryption key remains within the USB chip-level hardware module throughout the entire process and is invalidated after use. The encryption key is generated by asymmetric encryption using the SM2 public key, and this encrypted key is then exported to the USB flash drive. The encrypted key is generated by importing the public key encryption key, exported to the USB flash drive, and then used by the encryption key in the chip to encrypt the file to be sent, resulting in ciphertext.

[0114] After encryption is complete, the ciphertext must be checked to determine if encryption was successful. Only successfully encrypted ciphertext will be sent to the terminal. The USB flash drive's private key remains within the USB chip-level hardware module from generation to the end of its lifecycle. The entire decryption process of the encrypted key takes place within the USB chip-level hardware module of the flash drive; the entire process does not leave the USB chip-level hardware module.

[0115] After the encrypted message is sent to the terminal requiring encrypted communication, the recipient decrypts it using the relevant key stored on the USB drive. The decryption session key is obtained from the generated seed key through the USB drive's internal computation mechanism; the plaintext key remains within the USB chip-level hardware module throughout the entire process. The decryption of the file content is entirely completed within the USB chip-level hardware module of the USB drive, without ever leaving the module. All key operations, encryption / decryption calculations, and management are performed within the security chip; the plaintext key never leaves the hardware, ensuring the product's security, reliability, and compliance.

[0116] Specifically, the ciphertext is sent to the terminal requiring encrypted communication. The receiving terminal determines whether the ciphertext is a file generated by encrypted communication. If it is confirmed to be a file generated by encrypted communication, the public key information, encryption key, and encrypted communication flag are read from the USB flash drive of the terminal requiring encrypted communication. The public key certificate used in the ciphertext is checked to see if it belongs to the terminal. If so, the encrypted key is decrypted using the private key inside the USB flash drive. The decrypted key is then set inside the USB flash drive chip (without leaving the USB chip-level hardware module) and used to decrypt the ciphertext. The terminal requiring encrypted communication reads the public key information and file communication flag of the encrypted file using a Ukey and compares it with its own data. The Ukey contains the terminal's communication information and the private key corresponding to the public key. The plaintext encryption key does not leave the security chip inside the USB flash drive, and the encryption key cannot be obtained externally to decrypt the encrypted file. Encrypted communication is supported, but it can only be conducted between specific individuals. That is, ciphertext sent to a specific recipient can only be decrypted when the recipient's designated computer and designated U-shield are connected. Even if someone obtains the ciphertext, they cannot open it. The aforementioned encrypted communication method uses a public key certificate generated by the terminal to match and transmit ciphertext. It employs a one-time pad encryption method to encrypt the file to be sent. The encrypted content is executed on the USB drive. Only the terminal performing the encrypted communication can decrypt the ciphertext, and the decryption is also executed on the USB drive. This ensures high security, as decryption is only possible under specified conditions. As long as the certificate is from the local machine, the ciphertext can be read without difficulty.

[0117] The aforementioned secure USB chip-level hardware encryption system 100 integrates user terminal software 101, a USB chip-level hardware encryption module 102, and a communication module 103. Utilizing a unique public-private key pair generated and restricted internally by the hardware, along with a true random number generator, it ensures high security while supporting effective decryption under specified conditions. The user terminal software 101 includes an application program, driver, operating system, storage module, and communication module 103, providing comprehensive coverage from UI interaction to file operations. It supports device authentication, certificate management, and other functions, simplifying key management and data exchange processes. The application program connects the hardware encryption module with the system or user requirements, while the driver program manages the splitting and calculation of the file system. The operating system ensures the normal operation of the application, the storage module stores user data, and the communication module 103 acts as a bridge between the kernel and the user end, ensuring smooth and secure information transmission. The entire system fully leverages the advantages of hardware encryption, ensuring data security throughout its entire lifecycle while enabling unimpeded reading of ciphertext under specified conditions, greatly improving the user experience and strengthening data protection. In this way, even if there are security risks in the external environment, it can be ensured that sensitive data can only be accessed and decrypted in a specific trusted environment, thereby effectively protecting the security and privacy of the data.

[0118] Figure 2 This is a flowchart illustrating a secure communication and file encryption method of a secure USB chip-level hardware encryption system 100 provided in an embodiment of the present invention. For details, please refer to [link to relevant documentation]. Figure 2 The secure communication and file encryption method of the secure USB chip-level hardware encryption system 100 includes steps S110 to S150.

[0119] S110: Produce and initialize a USB chip-level hardware module containing a unique SM2 public-private key pair. The first client generates an encrypted SM2 certificate and shares it with the second client over the network. The second client imports the SM2 certificate for interactive use.

[0120] In one embodiment, step S110 described above may include steps S111 to S114.

[0121] S111. Produce and initialize the USB chip-level hardware module, and generate a unique random key pair through the USB chip-level hardware module.

[0122] In this step, a USB chip-level hardware encryption module 102 will be manufactured. This module contains a true random number generator (TRNG) and an algorithm (such as SM2) for generating key pairs. This module ensures that each generated key pair is unique and that the private key is securely stored internally in the hardware and will not be leaked to the external environment.

[0123] S112. The first client generates an SM2 certificate through the application software, encrypts and exports it, and saves it in the storage module or other easily accessible location.

[0124] The first client uses its application to generate an SM2 certificate based on the aforementioned key pair. This certificate contains public key information and other necessary authentication data. To ensure security, the certificate is encrypted and stored in a secure location, such as a local hard drive or cloud storage, for subsequent distribution.

[0125] S113. Distribute SM2 certificates through any network or LAN tool.

[0126] Next, the first client will use existing network infrastructure (such as the Internet, local area network, etc.) to send the encrypted SM2 certificate to the intended recipient, i.e., the second client. This can be done through various methods such as email attachments, File Transfer Protocol (FTP), and cloud storage links.

[0127] S114. The second client receives the SM2 certificate and imports it into the software to complete the interaction.

[0128] Finally, after obtaining the SM2 certificate issued by the first client, the second client needs to import it into its own system. This process involves verifying the certificate's validity and correctly configuring the associated public key. Once successfully imported, both parties can use these certificates and corresponding keys to conduct secure data exchange and communication, ensuring the security and privacy of information transmission.

[0129] The entire process begins with the production of the hardware module and continues until two clients can communicate securely using encrypted certificates. This ensures the uniqueness of the key pair and the security of the private key, while providing a convenient way to share and use encrypted certificates, thus enhancing the overall security of the system.

[0130] S120: The second client receives encrypted information and key decryption information, and securely processes the key decryption information through a USB chip-level hardware module to ensure that the key decryption information is sealed within the hardware.

[0131] In one embodiment, step S120 described above may include steps S121 to S122.

[0132] S121. When the second client receives the encrypted content, it obtains the decryption key information associated with the encrypted content, wherein the decryption key information includes the encryption public key information and the encryption key information of the second client.

[0133] When the second client (User B) receives the encrypted content from the first client (User A), in addition to the actual encrypted data, it will also receive decryption key information transmitted along with it. This decryption key information includes:

[0134] Encryption public key information: This is the public key information of the second client itself, used to identify and verify whether the encryption key used by the sender is associated with this terminal.

[0135] Encryption key information: This is an encryption key generated by the first client using the public key of the second client, specifically used to decrypt the encrypted content of this transmission. This encryption key is obtained by performing asymmetric encryption (such as SM2) on the seed key of a symmetric encryption algorithm (such as SM4) to ensure that only the terminal holding the corresponding private key can decrypt this key.

[0136] S122. The key decryption information is transmitted to the USB chip-level hardware module as a whole, and the key decryption information is decrypted. The decryption result is stored in the USB chip-level hardware module and is not transmitted out of the USB chip-level hardware module during the entire life cycle of the key.

[0137] In this step, the second client transmits all the crucial decryption information, including the encrypted public key and the encrypted encryption key, to its USB chip-level hardware module. This process involves the following specific operations:

[0138] Importing key decryption information: All necessary key decryption information is input into the USB chip-level hardware module, ready for decryption processing.

[0139] Decrypting the encryption key: The previously mentioned encryption key is decrypted using the SM2 private key built into the USB chip-level hardware module. This process ensures that even if intercepted during network transmission, a third party cannot obtain the original encryption key due to the lack of the corresponding private key.

[0140] Encapsulating the decrypted key: Once the original encryption key (e.g., the SM4 key) is successfully decrypted, it is immediately encapsulated in a secure storage area within the USB chip-level hardware module. This means that the key will not leave the hardware environment throughout its entire lifecycle, greatly improving security.

[0141] Setting the status to "Pending": After completing the above operations, the status of the USB chip-level hardware module may be updated to "Pending" or "Ready," indicating that it can begin processing specific encrypted content decryption tasks.

[0142] This process design not only ensures the security of key management but also guarantees that encrypted content can only be transmitted and decrypted between legitimate and authorized terminals, thus providing an efficient and secure data exchange mechanism. This hardware-level encryption and decryption strategy effectively prevents the risk of key leakage and enhances the information security of both communicating parties.

[0143] S130. An encryption key is generated and managed on the USB chip-level hardware module. The first client receives the encrypted information and ensures the security of the public and private keys to support encryption and decryption operations.

[0144] In one embodiment, step S130 described above may include steps S131 to S133.

[0145] S131. Generate a chip-level encryption key and an encrypted encryption key through a USB chip-level hardware module.

[0146] In this embodiment, the SB chip-level hardware module uses a True Random Number Generator (TRNG) to generate a unique encryption key. This key is typically used in symmetric encryption algorithms such as SM4 to ensure the security of data transmission.

[0147] To further enhance security, the originally generated encryption key will be re-encrypted using an asymmetric encryption method (such as SM2). Specifically, the original encryption key is encrypted using the public key of a second client (user B), forming a so-called "encrypted encryption key." This step ensures that even if intercepted during network transmission, a third party cannot easily decrypt the original encryption key unless they possess the corresponding private key.

[0148] S132. An encryption key derived from the encrypted encryption key, and encrypted content and information encrypted to the chip-level hardware.

[0149] Based on the initial encryption key, a series of derived keys can be generated. These derived keys can be used for different sessions or encryption needs, ensuring that each encryption task has its own unique key, thus improving overall security.

[0150] The aforementioned encryption keys (including derived keys) are used to encrypt the information or files to be sent. All encryption processes are completed within the USB chip-level hardware module, ensuring that the keys are not leaked to the external environment. Furthermore, the encrypted information includes metadata such as the encryption algorithm and key version, enabling correct identification and processing during subsequent decryption.

[0151] S133. The first client receives the encryption key, encrypted content, and encrypted information from the above, and uses the decryption key to decrypt the encrypted content to generate decrypted content. The decryption key, the encrypted content, and the encrypted information correspond to the encryption key, encrypted encryption key, session information, or session content of the first client, respectively, and are encrypted by a USB chip-level hardware module. The encryption key is derived from the encryption by the USB chip-level hardware module, and the session key is used to encrypt the session content data.

[0152] When the first client (user A) receives the encrypted information sent by the second client (user B), it contains not only the actual encrypted data, but also the encryption key required for decryption (usually the encryption key of the encryption), the encrypted content, and related encryption information (such as encryption algorithm identifier, key version, etc.).

[0153] Decryption process:

[0154] First, the first client transmits the encrypted encryption key to the USB chip-level hardware module and decrypts it using its own private key (i.e., the SM2 private key) to obtain the original encryption key.

[0155] Next, the original encryption key (usually an SM4 key) is used to decrypt the encrypted content. Since the entire decryption process is performed within the USB chip-level hardware module, the key is never exposed to the external environment throughout its lifecycle, greatly enhancing security.

[0156] Finally, the decrypted plaintext content will be transmitted from the USB chip-level hardware module and processed or displayed to the user by the application.

[0157] Through this design, the USB chip-level hardware module not only provides robust key management and encryption capabilities but also ensures the security and integrity of keys throughout their entire lifecycle. This mechanism effectively prevents the risk of key leakage and protects the secure transmission of sensitive information. Simultaneously, strict control and management of encryption keys makes encryption between different sessions more independent and secure, enhancing the overall security level of communication.

[0158] S140. The first client uses a USB chip-level hardware module to generate and export an SM2 certificate. After verification, the second client imports the verified certificate into the application, selects the certificate to encrypt files or folders, and saves the encrypted files to a specified location.

[0159] In one embodiment, step S140 described above may include steps S141 to S147.

[0160] S141. The USB chip-level hardware module distributes and creates information for the SM2 certificate to ensure the uniqueness of the key pair. The key pair exports the public key outside the chip through the application's interface to form an encryption certificate, while its private key is permanently stored inside the chip.

[0161] A unique key pair (public and private keys) is generated using a True Random Number Generator (TRNG) within the USB chip-level hardware module. The private key is permanently stored within the chip to ensure its security. Using an interface provided by the application, the generated public key can be exported from the chip to create an SM2 certificate. This certificate is used for subsequent data encryption and verification processes.

[0162] S142. The first client distributes the exported SM2 certificate to the corresponding second client through communication software or other tools.

[0163] The first client (User A) sends the generated SM2 certificate to the second client (User B) via a secure method (such as email, instant messaging software, etc.). This step ensures that both parties have exchanged the necessary public key information before communicating.

[0164] S143. The second client receives the encryption certificate, determines its validity, and imports it into the application. The application displays the first client's SM2 certificate or a list of SM2 certificates.

[0165] After receiving the SM2 certificate from the first client, the second client first needs to verify the certificate's validity, including but not limited to signature verification and validity period checks. Once verification is successful, the second client will import the certificate into its encryption application for subsequent use. Simultaneously, the application may display a list of imported certificates for user viewing and management.

[0166] S144. When the second client triggers encrypted communication, the application starts the certificate selection interface, selects the corresponding user certificate through the radio button, and transmits the public key information in the corresponding user certificate to the USB chip-level hardware module to realize the conversion of chip task mode.

[0167] When encrypted communication is required, the second client application provides a certificate selection interface, allowing the user to choose a suitable certificate. After the certificate is selected, the relevant public key information is transmitted to the USB chip-level hardware module, ready to execute the specific encryption task.

[0168] S145. After switching to encrypted outgoing mode, the application guides the second client to select the file that needs to be communicated in encrypted form.

[0169] Based on the user's actions, the application will prompt the user to select the file or folder to be encrypted and prepare to enter the encryption process.

[0170] S146. After receiving the file or folder specified by the user, the second client categorizes the file and manages it through a list.

[0171] Selected files or folders are categorized and managed within the application, typically presented in a list format for easy user confirmation and operation.

[0172] S147. The file is split and encrypted using a USB chip-level hardware module with SM4 symmetric encryption. The encryption key is generated by a true random number and encrypted with an SM2 certificate before being stored in the chip. After encryption, the file is saved to the specified location. If the integrity check fails, the temporary file is deleted.

[0173] In one embodiment, step S147 described above may include steps S1471 to S1476.

[0174] S1471. The application processes the first file and divides it into several parts according to the rules of the file system.

[0175] To improve encryption efficiency and flexibility, the original file is first divided into multiple smaller parts by the application according to certain rules (such as size or logical segmentation). Each part will be processed separately to ensure an efficient and flexible encryption process.

[0176] S1472. Several data sets are sequentially transmitted to the USB chip-level hardware module in a concatenated manner. The module will generate a set of SM4 encryption keys corresponding to the first client user, generated by a true random function generator, according to the chip task mode. The SM4 encryption keys are then encrypted using SM2 according to the public key in the first client certificate to obtain an encrypted encryption key. The encrypted encryption key is then imported into the chip and will not leave the chip, remaining in the chip. The chip's state is set to the pre-encryption ready state, and the application software is set to the waiting-for-return state.

[0177] For each segmented file data, the USB chip-level hardware module generates a unique set of SM4 encryption keys. These keys are generated by a true random number generator within the module, ensuring their unpredictability and security. Then, the SM4 encryption key is encrypted using the first client's public key (i.e., the SM2 public key), forming an "encrypted encryption key." This encryption key does not leave the chip but is securely stored there, ensuring its confidentiality.

[0178] After completing the above operations, the chip's state will be set to the pre-encryption ready state, while the application will enter the waiting-for-return state, ready to receive the encryption result.

[0179] S1473, The application software of the second client writes the encrypted encryption key information transmitted from the USB chip-level hardware module to a specified location in the intermediate temporary file.

[0180] The encryption key information obtained from the USB chip-level hardware module is recorded in a temporary file, specifically at line N of this intermediate temporary file. This file is typically used to store critical information needed for decryption. This step ensures that the correct key can be accurately found and used during the decryption process.

[0181] S1474. The application sends the segmented file content to the USB chip-level hardware module in a queue. The USB chip-level hardware module performs SM4 symmetric encryption on the encrypted content according to the pre-set process. The entire process and encryption key are all confined within the chip, and the outside world cannot obtain its important encryption key, encryption process, or memory information during encryption.

[0182] The segmented file contents are transmitted sequentially to a USB chip-level hardware module, where SM4 symmetric encryption is performed. The entire encryption process is executed within the hardware module, preventing external access to the encryption key or encryption procedure, thus enhancing security.

[0183] The S1475 and USB chip-level hardware modules transmit the encrypted content to the application, which then stores the encrypted content in a suitable location within a temporary file.

[0184] The encrypted content is sent back to the application and stored in a specific location in a temporary file as needed. The application stores the encrypted content below line N+9 of the temporary file, which is used to temporarily store all encrypted file fragments until all content has been processed.

[0185] S1476. After the application saves one copy, it continues to execute the transmission of the next encrypted content until the entire file is executed. The application then judges the integrity of the encryption and, based on the judgment result, places the encrypted communication file in the specified location or deletes the temporary file.

[0186] After encrypting a portion of the file, the application checks the integrity of that portion. If it's 100% complete, the encrypted communication file is placed in the designated location; otherwise, temporary files are deleted. Once no errors are confirmed, it continues processing the next file segment until the entire file is encrypted. Finally, if the entire encryption process is successful, the encrypted file is placed in the designated location; conversely, if any incomplete parts are found, the associated temporary files are deleted to prevent incomplete data from being left behind.

[0187] This detailed step-by-step design not only improves the security and efficiency of file encryption, but also ensures the confidentiality of encryption keys throughout their entire lifecycle, greatly enhancing communication security.

[0188] This design not only improves the security and efficiency of encryption, but also ensures the confidentiality of the key throughout its lifecycle, greatly enhancing the security of communication.

[0189] S150: Insert the USB chip-level hardware module and prepare the decryption environment. Verify the validity of the encryption key and decrypt the file using the SM2 private key. After decryption, replace the original encrypted file or retain the original encrypted file if the decryption fails.

[0190] In one embodiment, step S150 described above may include steps S151 to S159.

[0191] S151. The first client inserts the USB chip-level hardware module and initializes it through the application, entering the decryption waiting state.

[0192] The user first inserts the USB chip-level hardware module into the first client device and performs initialization through a specific application. After initialization, the application enters a state awaiting decryption.

[0193] Specifically, when a user inserts a USB chip-level hardware module, the operating system should automatically recognize and install the corresponding driver. The application needs to be able to detect new hardware connections and start automatically or prompt the user to start manually after detecting the USB chip-level hardware module.

[0194] In some application scenarios, additional authentication steps (such as PIN code input) may be required to ensure that only authorized users can access the USB chip-level hardware module.

[0195] During initialization, the application checks whether the USB chip-level hardware module is in good condition, such as confirming whether the key pairs, certificates and other information stored inside the module are complete and intact.

[0196] S152. The first client user navigates through the UI interface, selects the file to be decrypted, and the application enters the decryption process.

[0197] The application provides an intuitive and easy-to-use file browsing interface, allowing users to easily find and select files or folders that need to be decrypted. In addition to selecting individual files, it should also support batch decryption of multiple files or entire folders at once. To improve the user experience, an estimated completion time function can be added to the interface, predicting the required time based on known file sizes and previous decryption speeds.

[0198] S153. The application selects the file or folder from the first client and organizes the task file list.

[0199] The corresponding encryption key information is accurately extracted from the intermediate temporary file and transmitted to the USB chip-level hardware module for verification. Throughout the extraction and transmission process, data security must be ensured to prevent any form of data leakage or tampering. If any anomalies are found during verification (such as key mismatch), the user should be notified immediately and subsequent operations should be stopped.

[0200] S154. The first client obtains the file information to be decrypted and performs private key verification and legality verification processes using the encrypted key brought in by A093.

[0201] In this embodiment, the corresponding encryption key information is accurately extracted from the intermediate temporary file and transmitted to the USB chip-level hardware module for verification. Throughout the extraction and transmission process, data security must be ensured to prevent any form of data leakage or tampering. If any anomalies are found during verification (such as key mismatch), the user should be notified immediately and subsequent operations should be stopped.

[0202] S155. After the first client verification is completed, the encrypted encryption key is decrypted into plaintext encryption key using the SM2 private key. The plaintext encryption key is strictly controlled to prevent it from being transmitted out of the USB chip-level hardware module. It is fixed in the USB chip-level hardware module, and the USB chip-level hardware module is set to the state of pending encryption.

[0203] The primary objective at this stage is to ensure that the decryption request and the data involved (including but not limited to encryption keys, file information, etc.) are legitimate and have not been tampered with. Specific operations may include the following:

[0204] Private key verification: The first client passes the encryption key to the USB chip-level hardware module, and then verifies the key using the private key pre-stored in the module. This step ensures that only users with the correct private key can access or decrypt the corresponding data.

[0205] Validity verification:

[0206] Digital signature check: If the data has been digitally signed before transmission, this step is required to verify the validity of the signature to confirm the reliability and integrity of the data source.

[0207] Certificate verification: In some cases, it may be necessary to verify the identities of both parties involved in the communication, which typically involves the use of digital certificates. Checking the validity of certificates (e.g., whether they have expired, whether they were issued by a trusted certificate authority) can further enhance system security.

[0208] Permission checks: Depending on the application scenario, additional permission checks may be required to ensure that the current user has the right to decrypt the specified file.

[0209] Error feedback mechanism: If any of the above verification or validation steps fail, the system should be able to quickly identify and provide a clear error message to the user, while simultaneously preventing subsequent decryption processes. This not only helps protect data security but also helps users quickly locate the problem.

[0210] After these verifications and checks are completed, the system proceeds to step S156, initiating the actual file decryption process. This design enhances system security, ensuring that only authorized users can access sensitive information and that all interactions are based on trust.

[0211] S156. The first client application splits the file to be decrypted into several parts and sequentially sends them to the USB chip-level hardware module for decryption.

[0212] Based on the actual file size and system performance limitations, select an appropriate segmentation strategy (such as fixed-size blocks or intelligent segmentation). Consider whether to allow multiple threads to process different file segments simultaneously to accelerate the overall decryption speed. Each segment of decrypted data needs a corresponding verification mechanism to ensure it has not been corrupted or tampered with.

[0213] The S157 and USB chip-level hardware modules transmit the decrypted file content to the first client application, which then stores the decrypted content in a temporary file.

[0214] In this embodiment, an efficient communication protocol is used to ensure that data can be quickly and securely transferred from the USB chip-level hardware module back to the application.

[0215] Temporary storage management: Properly plan the storage location and naming rules for temporary files to facilitate subsequent management and cleanup.

[0216] S158. After the first client application has saved one copy, it continues to execute the process of decrypting the next piece of content until the entire file is executed.

[0217] After processing each part of the file, the application will move on to the next part until all the content has been decrypted.

[0218] S159. After the first client completes decryption, the application determines the integrity of the decryption. Based on the determination result, it deletes the encrypted communication file and modifies the plaintext file to the corresponding file name to replace the encrypted file, or deletes the temporary file and retains the original encrypted file.

[0219] The application determines the integrity of the decryption. If it is 100% complete, the encrypted communication file is deleted, the plaintext file is renamed to the corresponding file name, and the encrypted file is replaced. If it is not 100% complete, the temporary file is deleted, and the original encrypted file is retained.

[0220] The system compares the integrity of the original and decrypted files using hash values ​​or other methods to ensure complete consistency. It provides users with the option to retain the original encrypted file as a backup, and allows setting automatic restore points. Once decryption is confirmed, all related temporary files and cached data are promptly cleared to free up system resources.

[0221] These refined operations not only help improve system stability and efficiency, but also enhance user experience and security.

[0222] In the encryption process of terminal B, the core lies in using a random code generated by the USB chip-level hardware module as the encryption password. This random code is used to generate a random and unique SM4 encryption password, ensuring the security and uniqueness of the encrypted file. The specific steps include: First, a random number is generated within the USB chip-level hardware module, and a unique SM4 encryption password is generated based on this random number. Then, the generated SM4 encryption password is encrypted using the SM2 public key pre-stored in the USB, and the SM4 encryption password encrypted with the SM2 public key is exported outside the USB chip-level hardware module, forming a strong binding strategy to ensure that only a specific terminal can decrypt the key, achieving the uniqueness or specificity of the key. Finally, a new file containing the encrypted encryption key and encrypted content is generated.

[0223] For terminal A, the file decryption process must strictly follow certain steps to ensure security. First, the received encryption key (i.e., the encrypted SM4 encryption key) is decrypted using the SM2 private key within the USB chip-level hardware module. It is crucial that the original SM4 encryption key obtained through decryption remains within the USB chip-level hardware module and is strictly prohibited from being transmitted externally to enhance security. Based on the decrypted SM4 encryption key, a corresponding decryption environment is created within the USB chip-level hardware module. The content to be decrypted is then passed into this environment, decrypted according to the pre-defined decryption rules, and the decrypted content is exported from the USB chip-level hardware module. Finally, a new file containing the decrypted content is generated.

[0224] Furthermore, the process of encrypting the file to be sent using a USB chip-level hardware module to obtain ciphertext includes randomly generating a seed key (one key for each file), and using the seed key to encrypt the file to be sent through the USB chip-level hardware module, thereby obtaining ciphertext. A more detailed description further includes generating an encryption seed key by importing the public key used to encrypt the seed, exporting the encryption seed key to the USB chip-level hardware module, and using the encryption seed key to encrypt the file to be sent through the USB chip-level hardware module to obtain ciphertext. A further extended description includes generating a session key by combining the seed key with a scheme set within the USB chip-level hardware module, and using the session key to encrypt the file to be sent through the USB chip-level hardware module to obtain ciphertext. Finally, the process of sending the ciphertext to the terminal that needs to conduct encrypted communication, and the terminal decrypting it according to the relevant key in the USB chip-level hardware module, includes sending the ciphertext to the target terminal, the target terminal determining whether the ciphertext is a ciphertext communication file of a specified format, and if it is correct, reading the public key information, seed key, and ciphertext communication flag in the local USB chip-level hardware module, checking whether the public key certificate used by the ciphertext matches the public key certificate of this terminal, decrypting the encrypted seed key using the private key inside the USB chip-level hardware module, generating a session key using the decrypted seed key, and decrypting the ciphertext using the session key.

[0225] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the secure communication and file encryption method of the aforementioned secure USB chip-level hardware encryption system 100 can be found in the corresponding descriptions in the aforementioned system embodiments. For the sake of convenience and brevity, these details will not be repeated here.

[0226] The aforementioned secure USB chip-level hardware encryption system 100 can be implemented as a computer program, which can be used in, for example... Figure 3 It runs on the computer device shown.

[0227] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0228] See Figure 3 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0229] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a secure communication and file encryption method of a secure USB chip-level hardware encryption system 100.

[0230] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0231] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a secure communication and file encryption method of a secure USB chip-level hardware encryption system 100.

[0232] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0233] The processor 502 is used to run a computer program 5032 stored in the memory to implement all steps of the secure communication and file encryption method of the secure USB chip-level hardware encryption system 100.

[0234] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0235] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0236] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein when executed by a processor, the computer program causes the processor to perform all steps of the secure communication and file encryption method of the secure USB chip-level hardware encryption system 100.

[0237] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0238] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0239] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0240] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0241] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or 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, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0242] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A secure USB chip-level hardware encryption system, characterized in that, include: User terminal software, USB chip-level hardware encryption module, communication module; The USB chip-level hardware encryption module is used to generate user certificates. It is specified that the user certificate is generated by combining the true random number generator built into the chip with the SM2 key pair generation algorithm. A USB module contains only one valid public-private key pair, and the private key is restricted to the internal hardware. Each of the aforementioned user terminal software includes an application program, a driver program, an operating system, a storage module, and a communication module; The application is responsible for the UI interaction functions of user behavior and tasks, monitors the priority and mutual exclusion relationship of multiple tasks, and executes corresponding actions. The execution actions of the application include device authentication, certificate management, task navigation, and information display of the USB chip-level encryption module, and are connected in series with the USB chip-level hardware encryption module, system files or messages, and user needs. The driver program is used to perceive user behavior in file operations, and also manages the file system, splits file content into segments, and calculates cursor offsets. The operating system is used to support the normal operation of user terminal applications; The storage module is used to store user information or related files; The communication module serves as a bridge for message transmission between the kernel and the user. The communication module is used for communication between the user terminal software and the USB chip-level hardware encryption module.

2. The secure USB chip-level hardware encryption system according to claim 1, characterized in that, The USB chip-level hardware encryption module includes Chinese cryptographic algorithms SM1, SM2, SM3, and SM4, a true random function generator, and related containers. SM1 and SM4 are used for symmetric encryption and decryption, SM3 is used for hash verification, SM2 is used for asymmetric encryption and decryption, and the random function generator is used to generate random numbers that meet the specified requirements. It also performs SM4 encryption on the data content of the encrypted file when the user initiates encryption, and performs SM2 public key encryption on the encryption key and exports it to the chip. When a user initiates decryption, the SM2 private key is used to restore the encryption key of the content to be decrypted. The restored encryption key is not sent out of the chip but used for internal verification of the USB chip. If the decryption verification is successful, the decryption state is initiated. The incoming content is then decrypted using the SM4 decryption key, and the result is sent out of the USB chip. The storage module stores the user's necessary files or corresponding communication encryption certificates.

3. The secure USB chip-level hardware encryption system according to claim 2, characterized in that, The USB chip-level hardware encryption module performs symmetric and asymmetric hybrid encryption on the data content of the encrypted file according to the internal process and state control of the USB chip, resulting in a combination of encrypted content and verification information with mutual verification function.

4. A secure communication and file encryption method for a secure USB chip-level hardware encryption system as described in any one of claims 1 to 3, characterized in that, include: The system generates and initializes a USB chip-level hardware module containing a unique SM2 public-private key pair. The first client generates an encrypted SM2 certificate and shares it with the second client over the network. The second client imports the SM2 certificate for interactive use. The second client receives encrypted information and key decryption information, and securely processes the key decryption information through a USB chip-level hardware module to ensure that the key decryption information is sealed within the hardware. Encryption keys are generated and managed on a USB chip-level hardware module. The first client receives encrypted information while ensuring the security of public and private keys to support encryption and decryption operations. The first client uses a USB chip-level hardware module to generate and export an SM2 certificate. After verification, the second client imports the verified certificate into the application, selects the certificate to encrypt files or folders, and saves the encrypted files to a specified location. Insert the USB chip-level hardware module and prepare the decryption environment. Verify the validity of the encryption key and decrypt the file using the SM2 private key. After decryption, replace the original encrypted file or retain the original encrypted file if decryption fails.

5. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 4, characterized in that, The process involves producing and initializing a USB chip-level hardware module containing a unique SM2 public / private key pair. The first client generates an encrypted SM2 certificate and shares it over the network with the second client. The second client imports the SM2 certificate for interactive use, including: Generate and initialize USB chip-level hardware modules, and generate unique random key pairs through the USB chip-level hardware modules; The first client generates an SM2 certificate through the application software, encrypts and exports it, and saves it in the storage module or other easily accessible location; Distribute SM2 certificates using network or LAN tools; The second client receives the SM2 certificate and imports it into the software to complete the interaction.

6. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 4, characterized in that, The second client receives encrypted information and key decryption information, and securely processes the key decryption information through a USB chip-level hardware module to ensure that the key decryption information is sealed within the hardware, including: When the second client receives encrypted content, it obtains the decryption key information associated with the encrypted content, wherein the decryption key information includes the encryption public key information and the encryption key information of the second client. The key decryption information is transmitted as a whole to the USB chip-level hardware module, and the key decryption information is decrypted. The decryption result is then stored in the USB chip-level hardware module and is not transmitted out of the USB chip-level hardware module throughout the entire lifecycle of the key.

7. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 4, characterized in that, The process of generating and managing encryption keys on a USB chip-level hardware module, with the first client receiving encrypted information and ensuring the security of public and private keys to support encryption and decryption operations, includes: Generate chip-level encryption keys and encrypted encryption keys through a USB chip-level hardware module; The encryption key derived from the encrypted encryption key, as well as the encrypted content and information encrypted to the chip-level hardware; The first client receives the encryption key, encrypted content, and encrypted information from the above, and uses the decryption key to decrypt the encrypted content to generate decrypted content. The decryption key, the encrypted content, and the encrypted information correspond to the first client's encryption key, encrypted encryption key, session information, or session content, respectively, and are encrypted by a USB chip-level hardware module. The encryption key is derived from the encryption by the USB chip-level hardware module, and the session key is used to encrypt the session content data.

8. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 4, characterized in that, The first client uses a USB chip-level hardware module to generate and export an SM2 certificate. The second client verifies the certificate, imports it into the application, selects the certificate to encrypt files or folders, and saves the encrypted files to a specified location, including: The USB chip-level hardware module distributes and creates SM2 certificates to ensure the uniqueness of key pairs. The key pair exports the public key outside the chip through the application's interface to form an encryption certificate, while the private key is permanently stored inside the chip. The first client distributes the exported SM2 certificate to the corresponding second client through communication software or other tools; The second client receives the encryption certificate, determines its validity, and imports it into the application. The application then displays the first client's SM2 certificate or a list of SM2 certificates. When the second client triggers encrypted communication, the application starts the certificate selection interface, selects the corresponding user certificate through radio buttons, and transmits the public key information in the corresponding user certificate to the USB chip-level hardware module to realize the chip task mode conversion. After switching to encrypted transmission mode, the application guides the second client to select the file that needs to be communicated in encrypted form; After receiving the files or folders specified by the user, the second client categorizes the files and manages them through a list. The file is segmented and encrypted using a USB chip-level hardware module with SM4 symmetric encryption. The encryption key is generated by a true random number and encrypted with an SM2 certificate before being stored in the chip. After encryption, the file is saved to a specified location. If the integrity check fails, the temporary file is deleted.

9. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 8, characterized in that, The file is segmented and encrypted using a USB chip-level hardware module with SM4 symmetric encryption. The encryption key is generated by a true random number and encrypted with an SM2 certificate before being stored within the chip. After encryption, the file is saved to a designated location. If the integrity check fails, temporary files are deleted, including: The application processes the first file, dividing it into several parts according to the rules of the file system; Several data sets are sequentially transmitted to the USB chip-level hardware module in a concatenated manner. The module will generate a set of SM4 encryption keys corresponding to the first client user, generated by a true random function generator, according to the chip task mode. The SM4 encryption key will be encrypted using SM2 according to the public key in the first client certificate to obtain an encrypted encryption key. The encrypted encryption key will be imported into the chip and will not leave the chip, but will remain in the chip. The chip's state will be set to the pre-encryption ready state, and the application software will be set to the waiting return state. The application software of the second client writes the encrypted encryption key information transmitted from the USB chip-level hardware module to a specified location in the intermediate temporary file. The application sends the segmented file content to the USB chip-level hardware module in a queue. The USB chip-level hardware module performs SM4 symmetric encryption on the encrypted content according to a pre-set process. The entire process and encryption key are all locked inside the chip, and the outside world cannot obtain its important encryption key, encryption process, or memory information during encryption. The USB chip-level hardware module transmits the encrypted content to the application, which then stores the encrypted content in a suitable location in a temporary file. After the application saves one copy, it continues to transmit the next encrypted message until the entire file is processed. The application then checks the integrity of the encryption and, based on the result, places the encrypted communication file in a specified location or deletes a temporary file.

10. The secure communication and file encryption method of the secure USB chip-level hardware encryption system according to claim 4, characterized in that, The process of inserting the USB chip-level hardware module and preparing the decryption environment, verifying the legality of the encryption key, decrypting the file using the SM2 private key, and replacing the original encrypted file after decryption or retaining the original encrypted file in case of failure includes: The first client inserts the USB chip-level hardware module and initializes it through the application, entering a decryption waiting state. The first client user navigates through the UI interface, selects the file to be decrypted, and the application enters the decryption process. The application selects the file or folder from the first client and organizes the task file list; The first client obtains the file information that needs to be decrypted, and performs private key verification and legality verification processes using the encrypted key brought in by A093; After the first client verification is completed, the encrypted encryption key is decrypted into plaintext using the SM2 private key. The plaintext encryption key is strictly controlled to prevent it from being transmitted out of the USB chip-level hardware module. It is fixed in the USB chip-level hardware module, and the USB chip-level hardware module is set to the state of pending encryption. The first client application splits the file that needs to be decrypted into several parts and sends them to the USB chip-level hardware module for decryption processing in sequence. The USB chip-level hardware module transmits the decrypted file content to the first client application, which then stores the decrypted content in a temporary file. After the first client application saves a copy, it continues the process of decrypting the next piece of content until the entire file is executed. After the first client completes decryption, the application checks the integrity of the decryption. Based on the check result, it deletes the encrypted communication file and modifies the plaintext file to the corresponding file name to replace the encrypted file. Alternatively, it deletes the temporary file and retains the original encrypted file.

Images