A cloud storage transparent encryption file system and key cross-device synchronization method

Abstract

The application discloses a cloud storage transparent encryption file system and a key cross-device synchronization method, and comprises the following steps: a transparent encryption interception layer is established between a cloud disk synchronization client and a local file system of a user local device, and a virtual disk symbol is mounted in a virtual disk mode and is independent of a cloud disk synchronization directory; the cloud disk synchronization directory is a synchronization folder of the cloud disk synchronization client on the local, is located below the transparent encryption interception layer, is managed by the cloud disk synchronization client and is not managed by the transparent encryption interception layer, and the transparent encryption interception layer intercepts a write operation and a read operation on a file in the virtual disk symbol; after the write operation forms an encrypted file, the write operation is written into the cloud disk synchronization directory and is synchronized to a cloud storage by the cloud disk synchronization client; and the read operation finds a corresponding file encryption key from a local key vault according to a key identifier KeyID. In the cloud storage scene, the application realizes automatic encryption and other functions before a file leaves the local.

Description

Technical Field

[0001] This invention relates to the fields of information security and computer system architecture technology, and in particular to a cloud storage transparent encrypted file system and a method for synchronizing keys across devices. Background Technology

[0002] With the development of cloud computing, mobile internet, and mobile office, individual and enterprise users are storing large amounts of files on cloud storage service platforms such as Baidu Cloud, Alibaba Cloud, OneDrive, and Google Drive. However, under conventional storage models, cloud service providers can access file content in plaintext on the server side, exposing file data to risks such as leakage by service provider personnel, cyberattacks, data misuse, and judicial investigations. Meanwhile, my country's Cybersecurity Level Protection 2.0 and cryptographic application security assessment have set forth clear requirements for the protection of important data, making the use of national cryptographic algorithms such as SM4 for encrypted data storage a compliance requirement.

[0003] Several solutions exist for cloud data encryption, but all have shortcomings to varying degrees. Cryptomator is an open-source, transparent encrypted virtual disk that uses the AES algorithm to encrypt files and mounts them as a virtual disk, synchronizing user files to the cloud drive in encrypted form. However, this solution does not support the national standard SM series algorithms, failing to meet the compliance requirements of Cybersecurity Classified Protection 2.0 and the Cybersecurity Assessment; furthermore, key synchronization across devices requires manual export by the user, making end-to-end automatic synchronization impossible. Boxcryptor is a commercial encryption layer that can encrypt files on cloud drives, but this product has been acquired by Dropbox and is no longer available. VeraCrypt is a full-disk encrypted container solution, encrypting the entire container rather than individual files; when a small number of files within the container change, the entire GB-level container file needs to be retransmitted, making it unsuitable for incremental file-level synchronization. The server-side encryption function built into cloud drives uses keys held by the cloud service provider, allowing them to decrypt and access file content. This cannot resist service provider snooping or judicial investigation needs, lacking zero-knowledge protection.

[0004] In summary, none of the existing solutions mentioned above can simultaneously achieve the four objectives of "zero-knowledge storage in the cloud," "compliance with national cryptographic standards (SM4)," "file-level incremental synchronization," and "automatic end-to-end synchronization of keys across devices." Therefore, how to achieve zero-knowledge storage in the cloud, file-level incremental synchronization, and automatic end-to-end synchronization of keys across devices while meeting national cryptographic standards compliance requirements has become an urgent technical problem to be solved. Summary of the Invention

[0005] The purpose of this invention is to overcome the aforementioned deficiencies in the existing technology and provide a cloud storage transparent encrypted file system and a key synchronization method across devices. In a cloud storage scenario, this invention achieves the following: automatic encryption of files before they leave the local machine, with only the ciphertext stored in the cloud (zero-knowledge); encryption / decryption is seamless for the user (drag and drop to encrypt, open to decrypt); secure synchronization of file encryption keys between devices without exposing them to the cloud; compliance with national cryptographic standard SM4; file-level granularity, incremental synchronization with modifications to individual blocks, avoiding overall retransmission.

[0006] To achieve the above objectives, the present invention provides the following technical solution: This invention discloses a cloud storage transparent encrypted file system and a method for synchronizing keys across devices, comprising the following steps: S1. Establish a transparent encryption interception layer between the cloud disk synchronization client on the user's local device and the local file system. Mount the virtual disk as a virtual drive letter independent of the cloud disk synchronization directory. The transparent encryption and decryption interception layer intercepts write and read operations on files within the virtual drive letter. For write operations, execute step S2; for read operations, execute step S3. S2. For write operations, the following sub-steps are included: S21. Divide the plaintext file to be written into at least one data block according to a preset block division strategy, and generate a random initialization vector IV for each data block independently; S22. Encryption is performed using the national cryptographic SM4-GCM authentication encryption algorithm to generate ciphertext data blocks and their authentication tags; S23. Generate a self-describing metadata header, which includes a format magic number, version number, key identifier KeyID and initialization vector IV. Then, concatenate the ciphertext data and authentication tag to form an encrypted file, and write it to the cloud disk synchronization directory, and synchronize it to the cloud storage by the cloud disk synchronization client. S3. For read operations, the following sub-steps are included: S31. Identify the format magic number in the file metadata header to distinguish between encrypted and regular files; S32. For encrypted files, retrieve the corresponding file encryption key from the local key vault based on the key identifier KeyID, perform SM4-GCM decryption and verify the authentication tag. If the authentication is successful, return the plaintext file content; if the authentication fails, refuse to read and issue an alarm. S5. The file encryption key is stored only in a local key vault and does not enter or leave the cloud; the cloud storage service can only access encrypted files in ciphertext form and cannot recover plaintext files.

[0007] The metadata header also includes the encrypted original filename to prevent the cloud from inferring file content information from the filename; during decryption, the original filename is recovered from the metadata header and presented to the application.

[0008] The preset block division strategy is as follows: when the file size is lower than the preset threshold, the entire file is encrypted into a single block; when the file size exceeds the threshold, it is divided into blocks of a fixed size, and each block generates an initialization vector and authentication tag independently. When the file is modified, only the blocks that have been changed are re-encrypted and the initialization vector of the corresponding blocks is updated. Unchanged blocks remain unchanged to ensure compatibility with incremental / differential synchronization of cloud disk synchronization clients.

[0009] It also includes a key-to-device secure synchronization step: the first device generates a temporary ML-KEM-768 key pair, and sends the public key and device authentication token to the second device via the cloud; the second device uses the public key to encapsulate a session key, encrypts the file key material to be synchronized with the session key, and sends it back to the first device via the cloud; the first device decapsulates the session key and decrypts the file key material, and stores it in a local key vault; wherein, the cloud only relays encrypted messages and cannot obtain plaintext key material, achieving zero-knowledge transmission in the cloud.

[0010] The synchronization request message carries a device authentication token generated based on a chained HMAC audit chain. The device authentication token binds the device identity to the request sequence to prevent replay attacks and forgery of device identity. The device authentication token itself does not carry any file key material.

[0011] The local key vault uses the PBKDF2 key derivation function to derive the master key from the user's master password, and the master key is sealed and stored in the local file system; the file encryption key is stored after being encrypted with the master key, and it only resides in memory during runtime, and exists only in ciphertext form when written to disk.

[0012] During the execution of steps S1 to S3 of the method described in claim 1, an operation auditing step is also included: generating a chained HMAC audit record for each file upload, download, modification, and deletion operation. The audit chain is stored in a local isolated environment, supporting post-event verification of the integrity of the audit chain, and any tampering of any record can be detected.

[0013] The transparent encryption interception layer is implemented as a virtual disk driver in the operating system. It is mounted as a virtual drive letter in the system. User file read and write operations on the virtual drive letter are intercepted by the driver layer and then encrypted / decrypted. It is compatible with Windows and Linux platforms.

[0014] The virtual disk interception layer is implemented using a user-space file system framework, including FUSE for Dokany on Windows and FUSE for Linux. It can obtain a unified virtual mount point across platforms without kernel driver signing. The interception layer performs transparent interception and encryption / decryption of file I / O on top of the mount point.

[0015] A cloud storage transparent encrypted file system includes a set of modules for performing each step of the method according to any one of claims 1 to 9, including at least: a transparent encryption interception module, an SM4-GCM encryption engine module, a metadata header generation and parsing module, a local key vault module, a key cross-device synchronization module, and an operation audit module; wherein the file encryption key is stored only in the local key vault and does not enter or leave the cloud.

[0016] The present invention has the following beneficial effects: This invention achieves zero-knowledge security in the cloud by storing only ciphertext, which cannot be recovered by service providers or judicial investigations. It employs SM4-GCM authentication encryption, meeting the compliance requirements of the Information Security Level Protection 2.0 and the ciphertext evaluation. It uses file-level incremental synchronization and block-specific independent IVs to re-encrypt changed blocks, compatible with OneDrive's incremental synchronization, avoiding the need for complete retransmission of GB-level containers. Session key encapsulation based on ML-KEM-768 enables automatic end-to-end key synchronization across devices, with the cloud only relaying ciphertext. SM4-GCM authentication tags ensure that ciphertext tampering results in decryption failure, and a chained HMAC audit chain guarantees the immutability of operation logs. User operation of the virtual drive is equivalent to operation of the encrypted cloud disk, transparent and seamless, without altering usage habits. Furthermore, its core features have been verified through real-world engineering, demonstrating high security, compliance, transmission efficiency, and ease of use. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0018] Figure 1 This is an overview diagram of the system architecture of an embodiment of the present invention.

[0019] Figure 2 This is a flowchart of the transparent encryption / decryption interception process according to an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of the encrypted file metadata header format according to an embodiment of the present invention.

[0021] Figure 4 This is a timing diagram of the key cross-device secure synchronization protocol according to an embodiment of the present invention.

[0022] Figure 5This is a schematic diagram of large file block encryption and breakpoint resume transmission according to an embodiment of the present invention. Detailed Implementation

[0023] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. Obviously, the embodiments described are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0024] Example: like Figure 1 , Figure 2 As shown in the embodiment of the present invention, a cloud storage transparent encrypted file system and key cross-device synchronization method are described. The transparent encryption interception layer is implemented in the form of an operating system virtual disk, mounted as an independent drive letter (e.g., Z:) in the system, and lies between the cloud disk synchronization client and the local file system. User file read and write operations on the virtual drive letter are intercepted by the driver (or user-space file system framework): transparent encryption during writing and transparent decryption during reading. Production deployment adopts user-space file system frameworks—Dokany's FUSE on the Windows platform and FUSE on the Linux platform, which can obtain a unified virtual mount point across platforms without kernel driver signing. Real environment verification: The minimal verification service implemented with the WebDAV protocol is run end-to-end in a Windows administrator environment. The WebDAV service is mounted as a real drive letter Z: using net use Z:. Plaintext files are written to disk via Z: and encrypted files are written back to disk. The plaintext is consistent with the encrypted file name. <hash>The .cftv file and the CFTV header contain no plaintext on the disk. The transparent encryption interception layer is implemented as a virtual disk driver within the operating system, mounted as a virtual drive letter. User file read / write operations on this virtual drive letter are intercepted by the driver layer and then encrypted / decrypted. It is compatible with both Windows and Linux platforms.

[0025] like Figure 3 As shown, the encryption engine implements the national standard SM4-GCM authentication encryption (GB / T 32907), and has passed KAT self-testing. Files written are divided into blocks according to a preset block division strategy: files below a threshold (e.g., 64MB) are encrypted as a single block; files exceeding the threshold are divided into fixed-size blocks, each generating an independent 12-byte random IV and a 16-byte authentication tag. When a file is modified, only the changed blocks are re-encrypted and their IVs are updated; unmodified blocks remain unchanged, thus ensuring compatibility with differential / incremental synchronization from cloud disk synchronization clients and avoiding complete retransmission.

[0026] Each encrypted file header (format magic number CFTV) contains: Magic (4B) | Version (1B) | Flags (1B) | KeyID (32B) | IV (12B) | Reserved, followed by the ciphertext data and authentication tag (16B).

[0027] The metadata header also includes the encrypted original filename to prevent the cloud from inferring file content information from the filename; during decryption, the original filename is recovered from the metadata header and presented to the application. The original filename, encrypted, is also stored in the header and is only visible to the cloud. <hash>.cftv is a encrypted filename, and its content cannot be inferred from the filename.

[0028] During reading, the encrypted file is first identified by the header Magic; for the encrypted file, the corresponding file encryption key is retrieved from the local vault by KeyID, and SM4-GCM is executed to decrypt and verify the authentication tag: if the tag matches, the plaintext is returned; if the tag does not match (ciphertext has been tampered with or the key is incorrect), reading is refused and an alarm is issued to ensure data integrity and tamper protection.

[0029] The key vault derives the master key from the user's primary password using PBKDF2-HMAC-SHA256 (approximately 600,000 iterations, 16-byte salt). The file encryption key is encrypted with the master key and stored locally in a sealed manner. During runtime, it resides only in memory and exists only in ciphertext form when written to disk. The file encryption key never leaves the cloud, and the cloud cannot recover the plaintext key through any synchronization messages.

[0030] like Figure 4 As shown, the cross-device key synchronization protocol is based on the ML-KEM-768 post-quantum key encapsulation mechanism: The first device generates a temporary ML-KEM-768 key pair and forwards the public key and device authentication token to the second device via the cloud; the second device encapsulates the session key with the public key, encrypts the file key material to be synchronized with the session key, and sends it back; the first device decapsulates the session key with its private key and decrypts the file key material, storing it in a local vault. The cloud only relays encrypted messages and cannot obtain plaintext key material, achieving zero-knowledge transmission in the cloud and preventing decryption. The synchronization request message carries a device authentication token generated based on a chained HMAC audit chain, binding the device identity to the request sequence to prevent replay attacks and device identity forgery.

[0031] For each file upload, download, modification, and deletion operation, a chain of HMAC audit logs is generated and stored in a local isolated environment. Tampering with any log will cause the chain verification to fail and be detected, forming an immutable operation log to support compliance auditing and post-event traceability.

[0032] The cloud drive synchronization client synchronizes the local encrypted directory to the cloud; the cloud adapter (such as TencentCOSAdapter with actual wiring cos-nodejs-sdk-v5) only processes the encrypted objects, and the key does not leave the cloud, achieving zero-knowledge transmission to the cloud. This invention adapts to mainstream cloud drives (Baidu Cloud Drive / Alibaba Cloud Drive / OneDrive / Tencent Cloud COS, etc.) using a plug-in adapter, decoupling it from the core encryption logic.

[0033] Another embodiment of the present invention provides a cloud storage transparent encrypted file system, comprising a set of modules for performing each step of the method of any of the above claims, including at least: a transparent encryption interception module, an SM4-GCM encryption engine module, a metadata header generation and parsing module, a local key vault module, a key cross-device synchronization module, and an operation audit module; wherein, the file encryption key is stored only in the local key vault and does not enter or leave the cloud.

[0034] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any modifications, alterations, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.< / hash> < / hash>

Claims

1. A cloud storage transparent encrypted file system and a method for synchronizing keys across devices, characterized in that, Includes the following steps: S1. Establish a transparent encryption interception layer between the cloud disk synchronization client on the user's local device and the local file system. Mount the virtual disk as a virtual drive letter independent of the cloud disk synchronization directory. The transparent encryption and decryption interception layer intercepts write and read operations on files within the virtual drive letter. For write operations, execute step S2; for read operations, execute step S3. S2. For write operations, the following sub-steps are included: S21. Divide the plaintext file to be written into at least one data block according to a preset block division strategy, and generate a random initialization vector IV for each data block independently; S22. Encryption is performed using the national cryptographic SM4-GCM authentication encryption algorithm to generate ciphertext data blocks and their authentication tags; S23. Generate a self-describing metadata header, which includes a format magic number, version number, key identifier KeyID and initialization vector IV. Then, concatenate the ciphertext data and authentication tag to form an encrypted file, and write it to the cloud disk synchronization directory, and synchronize it to the cloud storage by the cloud disk synchronization client. S3. For read operations, the following sub-steps are included: S31. Identify the format magic number in the file metadata header to distinguish between encrypted and regular files; S32. For encrypted files, retrieve the corresponding file encryption key from the local key vault based on the key identifier KeyID, perform SM4-GCM decryption and verify the authentication tag. If the authentication is successful, return the plaintext file content; if the authentication fails, refuse to read and issue an alarm. S5. The file encryption key is stored only in a local key vault and does not enter or leave the cloud; the cloud storage service can only access encrypted files in ciphertext form and cannot recover plaintext.

2. The method according to claim 1, characterized in that, The metadata header also includes the encrypted original filename to prevent the cloud from inferring file content information from the filename; during decryption, the original filename is recovered from the metadata header and presented to the application.

3. The method according to claim 1, characterized in that, The preset block division strategy is as follows: when the file size is lower than the preset threshold, the entire file is encrypted into a single block; when the file size exceeds the threshold, it is divided into blocks of a fixed size, and each block generates an initialization vector and authentication tag independently. When the file is modified, only the blocks that have been changed are re-encrypted and the initialization vector of the corresponding blocks is updated. Unchanged blocks remain unchanged to ensure compatibility with incremental / differential synchronization of cloud disk synchronization clients.

4. The method according to claim 1, characterized in that, After establishing the transparent encryption interception layer and completing the initialization of the local key vault in step S1 of the method described in claim 1, when it is necessary to synchronize the file key materials in the local key vault to another user device, a key cross-device secure synchronization step is further included: the first device is the user's local device that currently holds the local key vault, and the second device is another user's local device that the user needs to synchronize to obtain the file key materials; the first device generates a temporary ML-KEM-768 key pair, and sends a synchronization request message to the second device via the cloud, the synchronization request message carrying the public key and the device authentication token; The second device uses the public key to encapsulate the session key, encrypts the file key material to be synchronized with the session key, and transmits it back to the first device via the cloud; the first device decapsulates the session key and decrypts the file key material, and stores it in a local key vault; wherein, the cloud only relays encrypted messages and cannot obtain plaintext key material, thus achieving zero-knowledge transmission in the cloud.

5. The method according to claim 4, characterized in that, The synchronization request message sent by the first device to the second device as described in claim 4 carries a device authentication token generated based on a chained HMAC audit chain. The device authentication token binds the device identity to the request sequence to prevent replay attacks and forgery of device identity. The device authentication token itself does not carry any file key material. The device authentication token is used to authenticate the legitimate source of the synchronization request, which is different from the file key material encrypted with the session key returned by the second device.

6. The method according to claim 1, characterized in that, The local key vault uses the PBKDF2 key derivation function to derive the master key from the user's master password, and the master key is sealed and stored in the local file system; the file encryption key is stored after being encrypted with the master key, and it only resides in memory during runtime, and exists only in ciphertext form when written to disk.

7. The method according to claim 1, characterized in that, During the execution of steps S1 to S3 of the method described in claim 1, an operation auditing step is also included: generating a chained HMAC audit record for each file upload, download, modification, and deletion operation. The audit chain is stored in a local isolated environment, supporting post-event verification of the integrity of the audit chain, and any tampering of any record can be detected.

8. The method according to claim 1, characterized in that, The transparent encryption interception layer is implemented in the form of an operating system virtual disk driver. It is mounted as a virtual drive letter in the system. User file read and write operations on the virtual drive letter are intercepted by the driver layer and then encrypted / decrypted. It is compatible with Windows and Linux platforms.

9. The method according to claim 8, characterized in that, The virtual disk interception layer is implemented using a user-space file system framework, including FUSE for Dokany on Windows and FUSE for Linux. It can obtain a unified virtual mount point across platforms without kernel driver signing. The interception layer performs transparent interception and encryption / decryption of file I / O on top of the mount point.

10. A cloud storage transparent encrypted file system, characterized in that, It includes a set of modules for performing each step of the method according to any one of claims 1 to 9, including at least: a transparent encryption interception module, an SM4-GCM encryption engine module, a metadata header generation and parsing module, a local key vault module, a key cross-device synchronization module, and an operation auditing module; wherein the file encryption key is stored only in the local key vault and does not enter or leave the cloud.

Images