Encrypted data transmission method for virtual devices integrating proprietary transmission protocols

Abstract

This invention discloses a method for encrypted data transmission of virtual devices involving an integrated proprietary transmission protocol, belonging to the field of communication security management technology. The method includes: powering on the MCU and detecting the VBUS signal, determining that it is in mobile hard drive mode, the MCU instructing the bridge chip, the MCU creating a virtual partition table disk, the PC client and the MCU performing bidirectional authentication and key exchange to establish an encrypted secure channel, the encrypted file blocks sent by the PC being disguised as target read / write commands through protocol steganography, transmitted and intercepted and decrypted by the MCU, and if it is a secure transmission request, written to the memory. This method is used to solve the technical problem in the prior art that it is impossible to ensure covert and secure data transmission while satisfying transmission mode compatibility. By combining virtual devices and proprietary protocols in a dual-mode switching hardware architecture, it ensures both data transmission rate and ease of use, and achieves end-to-end encryption and steganography protection, thereby improving overall security and practicality.

Description

Technical Field

[0001] This invention relates to the field of communication security management technology, and more specifically to a method for encrypted data transmission of virtual devices that integrates proprietary transmission protocols. Background Technology

[0002] Current data storage and transmission devices generally have dual application scenarios: they can be used as network storage servers and also connect directly to a computer via USB to function as external hard drives. However, existing technologies often suffer from limited interface speeds, making it difficult to meet high-speed transmission demands. Furthermore, separate power and data cables are typically required, increasing complexity and power consumption. Additionally, the need for a System-on-a-Chip (SoC) system to power on results in higher overall power consumption, hindering low-power design. Moreover, the lack of adaptive security mechanisms during data transmission between the PC and the device makes the transmission process highly vulnerable to unauthorized interception or tampering.

[0003] In summary, how to achieve covert and secure data transmission while maintaining compatibility of transmission modes, so as to improve the security and practicality of data transmission, is a technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a method for encrypted data transmission of virtual devices that integrates a proprietary transmission protocol, which addresses the technical problem in existing technologies that cannot ensure confidential and secure data transmission while satisfying transmission mode compatibility.

[0005] In view of the above problems, this application provides a method for encrypted data transmission of virtual devices that integrates a proprietary transmission protocol.

[0006] This application provides a method for encrypted data transmission of a virtual device integrating a proprietary transmission protocol. The method includes: a PC is connected via a bus; the MCU is powered on and detects the presence of a VBUS signal; if the VBUS signal is valid, it is determined to be in mobile hard drive mode; mode control is performed according to a deployed dual-mode switching circuit; when entering mobile hard drive mode, the MCU instructs the bridge chip, and the PC sends an encrypted file block; before responding to the PC's command, the MCU virtualizes a partition table disk, wherein the partition table disk includes a first partition and a second partition; the PC client and the MCU perform bidirectional authentication and key exchange to establish an encrypted secure channel; the encrypted file block sent by the PC is disguised as a target read / write command through protocol steganography, transmitted through the encrypted secure channel and intercepted by the MCU; the target read / write command is decoded and verified; if the verification is a secure transmission request, it is sent to the hardware encryption engine for processing and written to the memory; wherein the authentication parties are the client and the second partition in the partition table disk.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0008] The virtual device data encryption transmission method integrating a proprietary transmission protocol provided in this application embodiment involves a PC connected via a bus. The MCU powers on and detects the presence of a VBUS signal. If the VBUS signal is valid, it is determined to be in mobile hard drive mode. Mode control is performed according to the deployed dual-mode switching circuit. When entering mobile hard drive mode, the MCU instructs the bridge chip, and the PC sends an encrypted file block. Before responding to the PC's command, the MCU creates a virtual partition table disk. The PC client and the MCU perform bidirectional authentication and key exchange to establish an encrypted secure channel. The encrypted file block sent by the PC is disguised as a target read / write command through protocol steganography and transmitted through the encrypted secure channel. The MCU intercepts the target read / write command, decodes and verifies it. If the verification is a secure transmission request, it is sent to the hardware encryption engine for processing and written to the memory. This method solves the technical problem in the prior art that it is impossible to ensure confidential and secure data transmission while satisfying transmission mode compatibility. By combining virtual devices and proprietary protocols under a dual-mode switching hardware architecture, it ensures both data transmission rate and ease of use, while achieving end-to-end encryption and steganography protection, thereby improving overall security and practicality. Attached Figure Description

[0009] Figure 1 This application provides a schematic diagram of a method for encrypted data transmission of virtual devices integrating a proprietary transmission protocol;

[0010] Figure 2 This application provides a connection diagram illustrating mode switching in a virtual device data encryption transmission method integrating a proprietary transmission protocol;

[0011] Figure 3 This application provides a schematic diagram of mode switching control in a virtual device data encryption transmission method integrating a proprietary transmission protocol. Detailed Implementation

[0012] This application provides a method for encrypted data transmission of virtual devices that integrates a proprietary transmission protocol, thereby addressing the technical problem in existing technologies that cannot ensure covert and secure data transmission while satisfying transmission mode compatibility.

[0013] like Figure 1 As shown, this application provides a method for encrypted data transmission of a virtual device integrating a proprietary transmission protocol, the method comprising:

[0014] S1: The PC is connected via the bus. The MCU is powered on and detects whether there is a VBUS signal. If the VBUS signal is valid, it is determined to be in mobile hard drive mode. The mode is controlled according to the deployed dual-mode switching circuit.

[0015] In this embodiment, the PC is connected to the device via a bus. The bus is preferably a universal serial bus, which has the characteristics of plug-and-play and high-speed data transmission.

[0016] Specifically, after the PC establishes a physical connection with the device, the MCU inside the device is powered on and started. In this application, the MCU refers to the microcontroller unit, which is the core control unit of the entire dual-mode switching circuit. It is used to detect external input signals and make logical judgments, thereby realizing subsequent mode recognition and switching operations.

[0017] Subsequently, after the MCU completes its power-on self-test, it first checks whether a VBUS signal exists. In this application, the VBUS signal is the power supply voltage signal provided by the host in the USB interface, which is usually 5V and is used to characterize the physical connection status between the host and the peripheral.

[0018] By detecting the VBUS signal, the MCU can confirm whether the device is correctly recognized and powered by the PC. For example, when the PC powers a peripheral device through a USB port, the VBUS pin will output a stable voltage, and the MCU can determine that the signal is valid after capturing it.

[0019] Subsequently, when the MCU detects that the VBUS signal is valid, it determines the current device operating mode as external hard drive mode.

[0020] In this embodiment, the portable hard drive mode refers to the device being recognized by the PC as a large-capacity storage device, enabling file read and write interactions as a disk. In this mode, the device does not require the NAS main control system to be powered on and running; it can directly map the storage medium to the PC via a bridging chip, featuring ease of operation and low power consumption.

[0021] Furthermore, after confirming entry into mobile hard drive mode, the MCU performs mode control according to the pre-deployed dual-mode switching circuit. The dual-mode switching circuit proposed in this application refers to a circuit structure composed of a switching chip, a bridging chip, and related peripheral devices, which functions to switch the path between network mode and mobile hard drive mode.

[0022] For example, in external hard drive mode, the MCU controls the switching chip to connect the SSD's SATA path to the USB bridge chip, thereby enabling a direct connection between the PC and the storage medium; while in another network mode, the NAS controller chip takes over the control of the storage medium.

[0023] Through the above process, the device can automatically enter the external hard drive mode when it detects the VBUS signal, ensuring that users can identify and use the storage device with just one USB data cable, providing a good user experience and system compatibility.

[0024] Furthermore, based on the deployed dual-mode switching circuit, mode control is performed. Step S1 of this application includes:

[0025] The MCU continuously monitors the VBUS signal. When the VBUS signal is valid, it enters the external hard drive mode, in which the MCU disconnects from the NASSOC and the MCU takes over all communication with the bridge chip. When the VBUS signal is invalid, it enters the network mode, in which the MCU starts the NAS SOC and transfers control of the SSD to the NAS SOC through the switching chip.

[0026] Further, it includes: when there is a mode switching operation based on a dual-mode switching circuit, determining the security context information and encrypting and encapsulating it, and temporarily storing it in a dedicated memory; the MCU transmits and loads the encrypted and encapsulated security context information through a security message.

[0027] In this embodiment, the MCU, as the core control unit of the device, is in a continuous working state and monitors the VBUS signal in real time.

[0028] The VBUS signal is a power voltage signal provided by the PC's USB interface, used to characterize the connection status between the host and the peripheral device. When the MCU detects a valid VBUS signal, it means that the PC has powered the device through the USB interface and established a communication link. At this time, the MCU immediately determines that the device should enter external hard drive mode.

[0029] In one specific embodiment provided in this application, the ability to detect a VBUS signal and stabilize it at 5V is considered valid.

[0030] Subsequently, after entering the external hard drive mode, the MCU will actively disconnect the logical connection with the NAS main control chip, i.e., the SOC, thereby avoiding the high power consumption caused by the SOC system power-on operation. At the same time, the MCU will take over all communication between the SSD and the PC through the control bridge chip.

[0031] Preferably, in portable hard drive mode, the PC can directly recognize the storage medium as a large-capacity disk, enabling the same read and write operations as a portable hard drive, thus ensuring the dual advantages of high speed and low power consumption.

[0032] On the other hand, when the MCU detects that the VBUS signal is invalid during continuous monitoring, that is, the USB interface fails to obtain a valid power supply signal from the PC, specifically, the VBUS signal cannot be detected or the VBUS signal cannot remain stable, the MCU determines that it should enter network mode.

[0033] Subsequently, the MCU starts the NAS SOC, powering on the SOC system and switching control of the SSD from the bridge chip to the NAS SOC via the control switch chip, thus allowing the NAS SOC to take over access to and management of the memory.

[0034] In the network mode, the device has complete network storage capabilities and can provide data services to the outside world through the Ethernet interface, enabling remote access and centralized storage management.

[0035] In summary, through the aforementioned automated mode determination and switching mechanism, the device can flexibly adapt to different application scenarios based on external power supply and communication status, avoiding manual operation by users and improving ease of use and system stability.

[0036] Furthermore, when a mode switching operation based on a dual-mode switching circuit occurs, the MCU not only performs path switching but also processes the security context information of the current communication. The security context information proposed in this application refers to the security session parameters, key data, and authentication status established in the previous mode, used to maintain communication continuity and security.

[0037] Specifically, when the MCU detects a mode switch, it immediately encrypts and encapsulates the security context information and temporarily stores it in a dedicated memory to prevent the information from being leaked or lost during the switch.

[0038] For example, when switching from external hard drive mode to network mode, the established encrypted session parameters are encapsulated into ciphertext by the hardware encryption module and then written to the isolated storage unit for secure storage.

[0039] Subsequently, after the security context information is encrypted and temporarily stored, the MCU transmits and loads the encrypted information and services through a secure messaging mechanism.

[0040] Specifically, the security message refers to the encrypted communication format used when transmitting sensitive data between different functional modules within the device, which has the characteristics of integrity verification and confidentiality protection. Through this security message mechanism, the MCU transmits the encrypted and encapsulated context information to the service module corresponding to the new operating mode, for example, to the encryption service engine of the NAS SOC, enabling it to restore the previous secure communication state upon loading.

[0041] In summary, this ensures the continuity of encrypted communication sessions and the security of data interaction even when the device frequently switches between the two modes, avoiding redundant authentication or key negotiation operations for the user, thereby improving the system's security, reliability, and user experience.

[0042] S2: When entering the external hard drive mode, the MCU instructs the bridge chip and the PC to send encrypted file blocks. Before responding to the PC's command, the MCU virtualizes a partition table disk, which contains a first partition and a second partition.

[0043] In this embodiment, when the device is determined to enter the mobile hard drive mode by the MCU, the MCU first issues a control command to the bridge chip, so that the bridge chip establishes a communication path with the PC.

[0044] In the mode switching circuit provided in this application, a bridge chip is added to perform the protocol conversion, mapping the USB data request sent by the PC to the SATA or PCIe command that the memory can recognize, thereby ensuring that the PC can access the device in the manner of a standard external hard drive.

[0045] In this state, the PC can send encrypted file blocks to the device. The encrypted file block refers to a file data unit that has been encrypted by the client. As the basic unit of data transmission, the file block is always in an encrypted state during the transmission process to ensure the confidentiality and integrity of the data.

[0046] Subsequently, before responding to access commands from the PC, the MCU virtually generates a partition table disk. The virtual partition table disk proposed in this application refers to a disk partition structure simulated by the MCU through firmware logic. This structure does not actually exist in the physical storage medium, but rather appears externally as a standard disk through memory mapping and software definition. The purpose of generating this partition table disk is to establish logical isolation and a secure channel for subsequent data transmission; internally, it is divided into two functionally distinct partitions.

[0047] The first partition, serving as a public communication partition, is in a visible state and is recognized and mounted by the PC operating system. Users can see the normal file structure in this partition, thus maintaining consistency with the regular external hard drive mode.

[0048] The second partition is the encrypted communication partition, which is hidden and invisible in the normal operating system environment. It will not be automatically mounted or recognized. This partition mainly undertakes the functions of secure communication and key exchange.

[0049] In this application, by coexisting public and hidden partitions in the virtual partition table, both user-side compatibility and intuitive experience are guaranteed, while an independent and concealed logical channel is provided for encrypted communication between the MCU and the PC client, achieving a balance between security and convenience.

[0050] Furthermore, step S2 of this application includes:

[0051] The first partition is a public communication partition, and the second partition is an encrypted communication partition. The first partition in the virtual partition table disk of the MCU is in a visible state, and the second partition is in a hidden state. The hidden state means that it is not visible at the operation level and cannot be recognized and mounted by the mainstream operating system. It is used by the MCU to transmit encrypted private protocol data packets.

[0052] In this embodiment, the first partition is defined as a public communication partition, which logically corresponds to the visible space of a regular storage device. When the MCU virtualizes the disk partition table, it sets the first partition to a visible state, meaning it can be directly recognized and mounted in the PC operating system, allowing users to access and operate it like a regular external hard drive. The existence of this partition maintains a consistent interactive experience with conventional USB mass storage devices, thus ensuring compatibility with mainstream operating systems and user-level usability.

[0053] Correspondingly, the second partition is defined as an encrypted communication partition. This partition is designed to establish a secure and covert transmission channel between the MCU and the PC client. When the MCU is running the virtual partition table disk, it sets the second partition to a hidden state, meaning that this partition is not visible at the operational level. It will not appear in the disk management tools or file managers of mainstream operating systems, nor can it be accessed through conventional mounting mechanisms.

[0054] Preferably, the hidden state of the second partition is characterized by: on the one hand, it is not exposed at the external usage level, avoiding direct interference from user misoperation or malicious programs; on the other hand, it reserves a dedicated data interaction area for the MCU to carry encrypted private protocol data packets.

[0055] In practical applications, after the PC client establishes an encrypted channel with the MCU, the encrypted file block is encapsulated into a private protocol data packet and interacted with through the second partition. Subsequently, the MCU internally intercepts and parses the data read / write requests of this partition to achieve the sending, receiving, and verification of encrypted data.

[0056] Therefore, the public communication partition is responsible for maintaining the normal data interaction experience from the outside, while the encrypted communication partition works with the MCU to perform covert data transmission and security protocol operations. Together, they constitute the complete functional framework of the virtual partition table disk, ensuring the security and covertness of data transmission without affecting the user experience.

[0057] S3: The PC client and MCU perform two-way authentication and key exchange to establish an encrypted secure channel. The encrypted file block sent by the PC is disguised as the target read / write command through protocol steganography, transmitted through the encrypted secure channel and intercepted by the MCU. The target read / write command is decoded and verified. If the verification is a secure transmission request, it is sent to the hardware encryption engine for processing and written to the memory. The two parties to the authentication are the client and the second partition in the partition table disk.

[0058] In this embodiment, when the PC client application starts, it first initiates a two-way authentication process with the MCU inside the device. That is, both the client and the MCU need to complete identity verification to ensure the compliance and trustworthiness of both parties in the communication.

[0059] The MCU has a pre-installed device private key and a corresponding public key certificate, while the client has the same public key certificate embedded as the verification basis. During authentication, the client uses the public key certificate to encrypt a randomly generated verification code and sends it to the MCU. The MCU then decrypts the verification code using its own private key and returns the result, thus completing two-way identity verification. This process ensures that unauthorized terminals cannot access the communication channel.

[0060] Following the completion of two-way authentication, the client and MCU enter the key exchange phase. This involves both parties negotiating and generating a shared key through a secure protocol mechanism. Based on this shared key and their respective random numbers, a session key pair is derived, including but not limited to symmetric encryption keys for data encryption and decryption, and authentication keys for integrity verification. Through the derivation of the session key, an encrypted and secure channel is established between the client and MCU, ensuring the confidentiality and integrity of subsequently transmitted data.

[0061] Subsequently, the PC client encrypts the file block and further disguises the encrypted file block through protocol steganography. That is, the encrypted file block is embedded in the data payload area that conforms to the standard read and write command format, making it appear as a compliant target read and write command, thereby circumventing conventional detection mechanisms during transmission.

[0062] For example, the client may encapsulate file blocks as the data phase content of a standard write instruction, so that what appears to be an ordinary data write operation actually carries encrypted file data internally.

[0063] Furthermore, when a disguised target read / write command is transmitted to the device via an encrypted secure channel, the MCU intercepts it when the data flows through the second partition of the virtual partition table disk. The MCU uses pre-defined interpretation rules to interpret and verify the target read / write command to determine whether it is a secure transmission request.

[0064] If the verification passes, indicating that the command is compliant and the data source is trustworthy, the MCU will extract the encrypted file block of the data payload area from the target read / write instruction and send it to the hardware encryption engine for decryption verification. After successful decryption verification, the file data is finally written into the memory, completing the entire secure transmission process.

[0065] In summary, this embodiment uses the client and the second partition in the partition table disk as the interaction object for authentication and transmission, forming a logical isolation and security binding. This ensures that the public partition is not affected, while encrypted communication relies entirely on the hidden partition in collaboration with the MCU, thereby significantly improving the security and concealment of data transmission.

[0066] Furthermore, the PC client and the MCU perform two-way authentication and key exchange to establish an encrypted secure channel. Step S3 of this application includes:

[0067] The client inputs a file block, performs the first encryption process, and determines the encrypted file block. The first encryption process includes two-way authentication and key exchange encryption. If authentication between the two parties fails, the file block transmission is terminated. If authentication between the two parties succeeds, a secure encrypted channel is established and key exchange encryption is performed.

[0068] In this embodiment, the client first inputs a file block to be transmitted. This file block refers to the original data unit that the user needs to write or transmit to the device on the PC. To ensure data security during transmission, the client performs a first encryption process on the file block before transmission. This first encryption process involves pre-processing the data with encryption through a two-way authentication and key exchange mechanism before the file block enters the transmission link, ensuring that the data can only flow between trusted communicating parties.

[0069] In the specific execution of the first encryption process, two-way authentication is a fundamental step. The client and the device's MCU verify each other's identities using a pre-installed public key certificate and the device's private key to ensure that both communicating parties are compliant entities.

[0070] Specifically, if either party fails to authenticate during the authentication process—for example, if the client cannot correctly decrypt the authentication information returned by the MCU—authentication is immediately deemed a failure. In the event of authentication failure, the transmission operation of the current file block is terminated, preventing unauthorized access from obtaining data at the source, thereby ensuring the integrity and security of the transmission channel.

[0071] Conversely, after successful two-way authentication, the client and MCU continue with key exchange encryption. This key exchange involves both parties generating a shared key through a secure negotiation mechanism and deriving a session key pair using their respective random numbers. This session key pair includes a symmetric encryption key and an authentication key. At this point, a secure encrypted channel is formally established, and all data transmitted within this channel is protected by encryption using the session key. During this stage, the client uses the session key to encrypt the input file block, generating an encrypted file block.

[0072] Therefore, the file block is protected as encrypted before transmission, and even if intercepted during transmission, it cannot be illegally parsed or tampered with. These steps ensure the confidentiality, integrity, and resistance to attacks during file block transmission, laying the foundation for subsequent secure transmission.

[0073] Furthermore, step S3 of this application includes:

[0074] The two-way authentication includes: the MCU pre-configures a device private key and a public key certificate, and hardcodes the public key certificate in the PC client; the client encrypts a random verification code using the public key certificate and sends it to the MCU; the MCU decrypts the code based on the device private key and responds, thus completing the two-way authentication.

[0075] The key exchange encryption includes: when two-way authentication is successful, the client and the MCU exchange and generate a shared key; based on the shared key and combined with random numbers from both parties, a session key pair is derived, wherein the session key pair includes a symmetric encryption key and an authentication key; based on the session key, the file block is encrypted to generate an encrypted file block.

[0076] In this embodiment, the two-way authentication process specifically includes the following steps. The MCU has a pre-installed pair of device private key and public key certificates. The private key is securely stored in the MCU's hardware security module for subsequent decryption and signing operations. The corresponding public key certificate is hard-coded in the client application on the PC to ensure that the client can directly call the public key certificate for encryption operations when establishing a connection.

[0077] Specifically, when the client initiates authentication, it will randomly generate a verification code. In the technical solution of this application, the verification code is used as one-time challenge data to verify the authenticity of the MCU.

[0078] Subsequently, the client uses the MCU's public key certificate to encrypt the random verification code and sends the encrypted result to the MCU. Upon receiving the ciphertext, the MCU decrypts it using its internally stored device private key.

[0079] If the decrypted verification code matches the one generated by the client, it indicates successful authentication between both parties. At this point, the MCU will send the decryption result back to the client, completing the two-way authentication process. Through this mechanism, not only does the client confirm the MCU's identity, but the MCU also proves that it possesses the corresponding private key, ensuring the compliance of the communication between the two parties.

[0080] In a further implementation, based on successful two-way authentication, both parties enter the key exchange and encryption phase.

[0081] Specifically, the client and the MCU exchange necessary parameters through a secure negotiation process to generate a shared key. This shared key serves as the basis for subsequent derivations. In one feasible implementation, a session key pair is derived via a key derivation function by combining the random numbers generated by the client and the MCU respectively.

[0082] The session key pair includes a symmetric encryption key for encrypting and decrypting file data, and an authentication key for data integrity verification and authentication. This key pair enables both parties to not only protect the confidentiality of transmitted data but also ensure that the data has not been tampered with or forged.

[0083] Subsequently, after obtaining the session key pair, the client immediately uses the symmetric encryption key to encrypt the input file block, thereby generating an encrypted file block. This encrypted file block remains in ciphertext throughout subsequent transmission, ensuring that even in an untrusted network environment, the data content cannot be illegally parsed or used, thus significantly improving the security and reliability of file transmission.

[0084] Furthermore, the encrypted file blocks sent to the PC are disguised as target read / write commands through protocol steganography. Step S3 of this application includes:

[0085] A private protocol steganography mode is set, and protocol steganography is performed on the encrypted file block according to the private protocol steganography mode to generate read and write commands, wherein the encrypted file block is used as the data phase content of the read and write commands;

[0086] The method for setting the private protocol steganography mode is as follows: for the private protocol, determine the standard field-byte; determine the instruction set definition, wherein the instruction set definition is a redefinition based on the meaning of the private protocol, and includes at least instruction code and sequence number; set the private protocol steganography mode according to the standard field-byte and the instruction set definition.

[0087] In this embodiment, to ensure the concealment and anti-detection properties of the encrypted file block during transmission, this application proposes a private protocol steganography mode. The private protocol steganography mode refers to redefining and embedding an existing transmission protocol, enabling the encrypted file block to disguise itself as normal read / write command data payloads, thereby achieving the effect of transmitting ciphertext in the form of ordinary operations.

[0088] Specifically, after the MCU and the client establish an encrypted channel, they will embed encrypted file blocks into a designated area of ​​the protocol data frame according to the agreed steganography mode, making it appear as a regular storage operation request.

[0089] During execution, the first step is to determine the standard fields (bytes) of the private protocol. Standard fields (bytes) refer to fixed-format areas reserved or defined in the protocol message, such as command headers, length fields, and checksum fields. These fields are indispensable in normal protocol interactions and have stable byte structures and fixed semantics.

[0090] In steganography mode, the MCU uses these standard fields to constrain the data encapsulation process to ensure that the generated messages still conform to the conventional protocol format under external observation and will not cause any abnormalities.

[0091] Secondly, instruction set definition is required. Instruction set definition refers to redefining necessary identifiers such as opcodes under the standard fields of the private transport protocol based on the specific semantics of the private protocol. For example, a one-byte opcode is repositioned as the main instruction code, and a four-byte LBA is redefined as a 32-bit sequence number. At the same time, information about the data segmentation order is embedded in the sequence number to ensure that the encrypted file blocks can be reassembled in the correct order.

[0092] In summary, the redefined instruction set contains at least two core fields: instruction code and sequence number, thus ensuring that the steganographic commands are not only compliant in form but also have complete execution logic.

[0093] Finally, based on the standard field-byte and the redefined instruction set, a complete private protocol steganography pattern is formed.

[0094] In this mode, encrypted file blocks are directly embedded as the data phase content of read / write commands. On the surface, a standard data write request is generated, while the actual payload stores encrypted file blocks. This way, any external monitoring system can only recognize it as a regular write operation and cannot determine the sensitive encrypted data it contains, thus significantly improving the concealment and security of the transmission.

[0095] Furthermore, step S3 of this application includes: performing protocol steganography processing on the encrypted file block according to the private protocol steganography mode to generate the target read / write command; wherein, the first steganography step is a conversion based on the instruction set definition, and the second steganography step is the generation of the read / write command and the writing of the converted encrypted file block command, and the encrypted file block is stored in the data payload area of ​​the read / write command.

[0096] In this embodiment, after setting the private protocol steganography mode, protocol steganography processing is then performed on the encrypted file block to generate target read / write commands. These target read / write commands appear externally as standardized read / write instructions conforming to the storage protocol specification, but internally actually carry encrypted file data. In this way, the encrypted file block is naturally embedded into the regular data stream of protocol interaction, achieving steganographic transmission.

[0097] In the specific processing, the first step of steganography is performed, which is a conversion based on the instruction set definition. In a specific implementation, the ordinary protocol opcodes and sequence numbers are replaced or expanded into the instruction structure required by the steganography protocol using the previously reset instruction set definition, that is, the conversion of the encrypted file block based on the private protocol steganography mode.

[0098] Subsequently, the second steganography step is performed, namely, the generation of read / write commands and the writing of encrypted file block commands. In this step, a standardized read / write command is first generated, and the converted encrypted file block is embedded into the generated read / write command as a data payload.

[0099] Specifically, the data phase portion of the generated read / write command is reused as the payload area, and the encrypted file block is completely written into it, thereby forming a complete command message with steganographic features and generating the target read / write command.

[0100] In the preferred processing method, the generated standardized read and write commands are also converted according to the instruction set definition, so that the MCU can verify whether they are the original commands by decoding after subsequent interception.

[0101] At this point, the target read / write command appears to external monitoring or analysis tools as a routine write operation, as its structure is completely identical to the standard read / write command and will not trigger any anomalies. However, its actual data payload area stores real encrypted file blocks, providing a hidden transmission channel for subsequent decryption and processing.

[0102] Therefore, the generated target read / write commands not only have good camouflage properties, but also ensure the integrity and security of the encrypted file blocks during transmission.

[0103] Furthermore, by transmitting through an encrypted secure channel and intercepting the data with the MCU, the target read / write commands are decoded and verified. Step S3 of this application includes:

[0104] The target read / write command is transmitted to the second partition of the partition table disk, and the MCU intercepts the target read / write command. By interpreting the target read / write command based on the instruction set definition, it is determined whether it is a secure transmission request. If it is a secure transmission request, the MCU will extract the data phase content of the target read / write command, receive the encrypted file block, and send the encrypted file block to the hardware encryption engine for decryption and verification.

[0105] In this embodiment, when a target read / write command is transmitted to the device via an encrypted secure channel, the command is first imported into the second partition of the virtual partition table disk. This second partition, as a hidden partition, is invisible to the operating system and is primarily used for encrypted communication and private protocol data transmission in collaboration with the MCU.

[0106] Furthermore, once the target read / write command enters the second partition, it is not directly recognized as a normal storage request by the operating system. Instead, it is intercepted and managed internally by the MCU. In this way, the MCU can obtain the command message immediately and perform proprietary parsing and security verification to prevent unauthorized data from entering the memory.

[0107] Specifically, after intercepting the target read / write command, the MCU will interpret it based on the instruction set definition of the previously defined private transmission protocol. That is, according to the rules defined in the instruction set, the MCU will parse the opcode, sequence number and additional fields in the target read / write command to determine whether the command is a compliant and secure transmission request.

[0108] For example, if the instruction code and sequence number in the command conform to the format and order required by the steganography protocol, it is considered a valid request; if they do not conform or contain abnormal fields, execution is immediately rejected and processing is aborted. Through the decoding process, the MCU can effectively prevent forged commands or malicious instructions from entering the secure channel, thereby ensuring the integrity and reliability of the transmission process.

[0109] If the determination result indicates that the target read / write command is a secure transmission request, the MCU will further extract the encrypted file block from the data phase of the target read / write command. The content of the data phase, namely the payload area in the target read / write command protocol message that carries the actual file block, has been filled with encrypted file blocks in the steganography step.

[0110] Subsequently, after extracting the content, the MCU hands it over to the device's internal hardware encryption engine for decryption and verification. As a dedicated security processing module, the hardware encryption engine can perform symmetric decryption operations and integrity checks at high speeds, ensuring that the encrypted file block has not been tampered with and its origin is trustworthy during transmission. Only after successful decryption and verification is the file block written to memory, thus completing a full and secure data transmission process.

[0111] In summary, secure file transfer in a virtual partition environment was achieved, which not only ensured the concealment and resistance to detection of encrypted file blocks, but also ensured the confidentiality and integrity of the data.

[0112] The virtual device data encryption transmission method integrating a proprietary transmission protocol provided in this application has the following technical effects:

[0113] 1. Automatic switching between external hard drive mode and network mode is achieved through a dual-mode switching circuit. In external hard drive mode, no power is required from the NAS SOC, reducing power consumption, and only one data cable is needed for connection, improving user convenience. During mode switching, security context information is encrypted and encapsulated for transmission, ensuring the continuity of security status during the switching process and avoiding information leakage or authentication failure. It supports high-speed bridging chips and high-speed storage devices, ensuring encrypted data transmission while taking into account the transmission rate, meeting the needs of efficient data interaction.

[0114] 2. A proprietary transmission protocol and protocol steganography are introduced to disguise encrypted file blocks as target read / write commands, enhancing data transmission concealment and reducing the risk of malicious interception and cracking. A two-way authentication and key exchange mechanism between the client and the MCU ensures identity compliance and key security through device public and private key certificates and shared key-derived session keys, providing an encrypted foundation for data transmission. A hardware encryption engine participates in data processing, improving encryption and decryption efficiency and security, ensuring data security throughout the entire process from transmission to storage. A hidden second partition in the virtual partition table disk is used only for encrypted communication and is not recognized by mainstream systems, further isolating encrypted data and reducing the risk of unauthorized access.

[0115] In a further embodiment, this application provides a connection diagram for mode switching. In the technical solution of this application, switching between mobile hard drive mode and network mode provides the basic conditions for the encrypted transmission scheme of this application.

[0116] like Figure 2 The diagram shown illustrates the connection for mode switching in this invention. Specifically, it includes: a power type-C interface (J1), a type-C interface (J2) for connecting the external hard drive to the PC, a J3 for connecting the SSD, a type-C 10Gbps to SATA 3.0 bridge chip (U3), a SATA 3.0 1 to 2 port switch 10G chip VL163 (U4), an MCU controller (U2), and a NAS SOC controller (U1).

[0117] like Figure 2 , Figure 3 As shown, the specific implementation method of mode switching based on the above circuit is as follows:

[0118] When the user is only using the external hard drive mode, the switch selection pin SEL of U4 has a pull-down resistor R319 by default. The SATA path is switched from the C end to the 2 end by default. That is, the user connects the data cable from the PC to J2, then through the bridge chip U3, and then to the switch chip U4 to connect J3, realizing the SSD to the PC. The user only needs one data cable to connect to the hard drive, and at the same time, there is no need to power on the SOC and MCU, which reduces the power consumption.

[0119] When the user is using network mode, the user plugs in the power supply to J1. The device's MCU (U2) will power on first. The MCU will then check if there is 5V voltage on J2's VBUS, i.e., whether the user is connected to the external hard drive mode through J2. If 5V is detected on J2's VBUS, the switch chip will not perform a switching operation, prioritizing the external hard drive mode. If 5V is not detected on J2's VBUS, then the power supply to U1 will be turned on, and the switch chip will switch the C terminal to the I terminal, safely entering network mode.

[0120] Through the foregoing detailed description of the virtual device data encryption transmission method integrating a proprietary transmission protocol, those skilled in the art can clearly understand the virtual device data encryption transmission method integrating a proprietary transmission protocol in this embodiment. As for the apparatus disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and relevant parts can be referred to the method section description.

[0121] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for encrypted transmission of virtual device data integrating a proprietary transmission protocol, characterized in that, The method comprises: The PC accesses through the bus, the MCU is powered on and detects whether the VBUS signal exists, if the VBUS signal is valid, it is judged as the mobile hard disk mode, and the mode control is performed according to the deployed dual-mode switching circuit; When entering the mobile hard disk mode, the MCU instructs the bridge chip, the PC sends the encrypted file block, and the MCU virtually creates a partition table disk before responding to the command of the PC, wherein the partition table disk comprises a first partition and a second partition; The client of the PC and the MCU perform mutual authentication and key exchange, establish an encrypted secure channel, the encrypted file block sent by the PC is disguised as a target read-write command through protocol steganography processing, is transmitted through the encrypted secure channel and is intercepted by the MCU, the target read-write command is interpreted and detected, if the detection is a safe sending request, is transported to the hardware encryption engine for processing and is written into the memory, wherein the authentication parties are the client and the second partition in the partition table disk; The mutual authentication and key exchange between the client of the PC and the MCU and the establishment of the encrypted secure channel comprise: The client inputs the file block, performs first encryption processing, and determines the encrypted file block, wherein the first encryption processing comprises mutual authentication and key exchange encryption; When the mutual authentication fails, the file block transmission is terminated, and when the mutual authentication succeeds, the secure encrypted channel is established and the key exchange encryption processing is performed; The mutual authentication comprises: The MCU pre-stores a device private key and a public key certificate, and the public key certificate is hard-coded in the client of the PC; The client encrypts a random verification code through the public key certificate and sends it to the MCU, the MCU decrypts it based on the device private key and replies, and the mutual authentication is completed; The key exchange encryption comprises: When the mutual authentication passes, the client and the MCU generate a shared key through exchange; According to the shared key, a session key pair is derived in combination with random numbers of both parties, wherein the session key pair comprises a symmetric encryption key and an authentication key; According to the session key, the file block is encrypted to generate an encrypted file block; The encrypted file block sent by the PC is disguised as a target read-write command through protocol steganography processing, which comprises: A private protocol steganography mode is set, the protocol steganography is performed on the encrypted file block according to the private protocol steganography mode to generate a read-write command, wherein the encrypted file block is taken as the data stage content of the read-write command; The setting mode of the private protocol steganography mode is: A standard field-byte is determined for the private protocol; An instruction set definition is determined, wherein the instruction set definition is a redefinition based on the meaning of the private protocol, and at least comprises an instruction code and a serial number; The private protocol steganography mode is set according to the standard field-byte and the instruction set definition.

2. The virtual appliance data encryption transmission method integrating a private transmission protocol of claim 1, wherein, The mode control according to the deployed dual-mode switching circuit comprises: The VBUS signal is continuously monitored by the MCU, when the VBUS signal is valid, the mobile hard disk mode is entered, wherein the MCU is disconnected with the NAS SOC, and all communications are taken over by the MCU and the bridge chip. When the VBUS signal is invalid, the network mode is entered, wherein the MCU starts the NAS SOC, and transfers the SSD control right to the NAS SOC through the switch chip.

3. The virtual appliance data encryption transmission method integrating a private transmission protocol of claim 2, wherein, When there is a mode switching operation based on the dual-mode switching circuit, the security context information is determined and encrypted and packaged, and temporarily stored in a special memory; The MCU transmits and serves the encrypted and packaged security context information through a security message.

4. The virtual appliance data encryption transmission method integrating a private transmission protocol of claim 1, wherein, According to the private protocol steganography mode, the encrypted file block is protocol steganography processed to generate the target read-write command; Wherein, the conversion based on the instruction set definition is the first steganography step, and the read-write command generation and the converted encrypted file block command writing are the second steganography step, and the encrypted file block is stored in the data payload area of the read-write command.

5. The virtual appliance data encryption transmission method integrating a private transmission protocol of claim 4, wherein, The target read-write command is interpreted and checked through the encrypted security channel transmission and the MCU interception, including: The target read-write command is transmitted to the second partition of the partition table disk, and the MCU intercepts the target read-write command; The target read-write command is interpreted based on the instruction set definition to determine whether it is a security sending request; If it is a security sending request, the MCU extracts the data stage content of the target read-write command, receives the encrypted file block, and sends the encrypted file block to the hardware encryption engine for decryption verification.

6. The virtual appliance data encryption transmission method integrating a private transmission protocol of claim 1, wherein, The first partition is a public communication partition, and the second partition is an encrypted communication partition; Wherein, the first partition of the virtual partition table disk of the MCU is in a display state, and the second partition is in a hidden state, wherein the hidden state represents that it is invisible at the operation level and cannot be recognized and mounted by the mainstream operating system, and is used for transmitting encrypted private protocol data packets in cooperation with the MCU.

Images