Multimedia data transparent encryption method and system

Abstract

The embodiment of the invention provides a multimedia data transparent encryption method and system. The method comprises the following steps: acquiring multimedia data to be encrypted; performing activity verification on the block device corresponding to the multimedia data; if the block device has no active mounting point, performing encryption initialization on a user identity corresponding to the multimedia data so as to enable the block device to enter a filtering state; performing encryption mapping on the block device in the filtering state, and determining that the block device enters an encrypted state; and performing password verification on the block device in the encrypted state, if the password verification fails, performing decryption erasing operation on the block device in the encrypted state, and repeating the processes of activity verification, encryption initialization and encryption mapping until the password verification on the block device in the encrypted state succeeds, thereby obtaining encrypted data. According to the method, the accuracy of encrypted data can be improved, and the security risk is reduced.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a method and system for transparent encryption of multimedia data in the field of data processing technology. Background Technology

[0002] Persistent encryption technology for streaming video data is a key security mechanism to ensure the confidentiality and integrity of multimedia data throughout its entire lifecycle of storage, transmission, and access. This technology transforms plaintext data into encrypted form through cryptographic transformations, ensuring that only authorized entities can perform decryption operations and access the original content. However, existing video encryption solutions still employ algorithms proven to have security weaknesses in cryptography (such as DES and 3DES) in practical deployments. Their key spaces are insufficient to withstand brute-force attacks in modern distributed computing environments. Furthermore, key management involves multiple stages, including generation, injection, storage, distribution, rotation, revocation, and destruction, each with its own security risks. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for transparent encryption of multimedia data, and the specific technical solution adopted is as follows: In a first aspect, embodiments of the present invention provide a method for transparent encryption of multimedia data, the method comprising: Retrieve the multimedia data to be encrypted; The activity of the block device corresponding to the multimedia data is verified. If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized so that the block device enters the filtering state. Encryption mapping is performed on the block device in the filtered state to determine that the block device has entered the encrypted state; Password verification is performed on the block device in the encrypted state. If the password verification fails, the block device in the encrypted state is decrypted and erased. The process of liveness verification, encryption initialization and encryption mapping is repeated until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

[0004] Secondly, a multimedia data transparent encryption system is provided, the system comprising: The acquisition module is used to acquire the multimedia data to be encrypted; The verification module is used to verify the activity of the block device corresponding to the multimedia data; The encryption module is used to initialize the encryption of the user identity corresponding to the multimedia data if the block device has no active mount point, so that the block device enters the filtering state. The mapping module is used to perform encrypted mapping on the block device in the filtered state and determine that the block device has entered the encrypted state; The verification module is used to verify the password of the block device in the encrypted state. If the password verification fails, the block device in the encrypted state is decrypted and erased, and the process of liveness verification, encryption initialization and encryption mapping is repeated until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

[0005] Thirdly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0006] Fourthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0007] This invention offers the following advantages: After acquiring the multimedia data to be encrypted, the activity of the block device corresponding to the multimedia data is verified. If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized to allow the block device to enter a filtering state. This enables more accurate detection and pre-verification of the device. Then, the block device in the filtering state is encrypted and mapped to determine if it has entered an encrypted state. Thus, by encrypting and mapping the block device in the filtering state, the entry of the block device into the encrypted state can be more precisely controlled. Finally, a password verification is performed on the block device in the encrypted state. If the password verification fails, a decryption and erasure operation is performed on the block device in the encrypted state, and the processes of activity verification, encryption initialization, and encryption mapping are repeated until the password verification for the block device in the encrypted state is successful, resulting in encrypted data. In this way, by performing password verification on the block device in the encrypted state, if the password verification fails, the process returns to the activity verification stage, and repeats the activity verification, encryption initialization, and encryption mapping until the password verification is successful, thereby obtaining the encrypted data. This can improve the accuracy of the encrypted data and reduce security risks. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram illustrating the implementation process of a multimedia data transparent encryption method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of another implementation process of a multimedia data transparent encryption method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating another implementation process of a multimedia data transparent encryption method provided in this embodiment of the invention; Figure 4 This is a schematic diagram illustrating the implementation framework of a multimedia data transparent encryption method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating an application scenario of a multimedia data transparent encryption method provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating another application scenario of a multimedia data transparent encryption method provided in this embodiment of the invention; Figure 7 This is a schematic diagram illustrating another application scenario of the multimedia data transparent encryption method provided in this embodiment of the invention; Figure 8 This is a schematic diagram of the composition structure of a multimedia data transparent encryption system provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer block device provided in an embodiment of the present invention. Detailed Implementation

[0010] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a multimedia data transparent encryption method proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments may be combined from any suitable form.

[0011] In the description of the embodiments of the present invention, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present invention, "multiple" means two or more.

[0012] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0014] In practical deployments, video recording encryption solutions have revealed the following technical defects and security risks: 1. Cryptographic vulnerabilities and structural leakage risks of related symmetric cryptographic algorithms: Some related technical solutions still employ algorithms that have been proven by the cryptography community to have security weaknesses (such as the Data Encryption Standard (DES) and 3DES), whose key spaces are insufficient to withstand brute-force attacks in modern distributed computing environments. Specifically: (1) Lagging algorithm generation evolution: The 56-bit effective key length of the DES algorithm can be traversed in a few hours under the current graphics processing unit (GPU) cluster acceleration environment; although 3DES has been extended to a nominal key length of 168 bits, the actual security strength is only equivalent to 112 bits due to the Meet-in-the-Middle Attack, and the computational performance is 3-5 times worse than AES.

[0015] (2) Inappropriate choice of working mode of block cipher: When using Electronic Codebook (ECB) mode, the same plaintext block is encrypted into the same ciphertext block, which leads to the leakage of the statistical characteristics and structural information of the original data through the ciphertext mode, making it vulnerable to pattern analysis attacks; Although Cipher Block Chaining (CBC) mode introduces initialization vector (IV), improper management or reuse of IV will lead to the predictability of key flow, and its serial dependency characteristics restrict the performance of parallel computing capabilities.

[0016] (3) The trust chain of key distribution and storage is fragile: In traditional schemes, keys are stored in configuration files in plaintext or weak encryption form, or transmitted through insecure channels, which are vulnerable to threats such as man-in-the-middle attack (MITM), memory dump analysis, and side-channel attacks (such as timing attacks and power consumption analysis). Once the key is leaked, all encrypted data will be compromised.

[0017] 2. Engineering complexity and single point of failure risk in key lifecycle management: Key management involves multiple stages, including generation, injection, storage, distribution, rotation, revocation, and destruction, each of which presents security risks. (1) Insufficient key generation entropy source: Some embedded systems lack a high-quality hardware random number generator (HRNG). If the seed is predictable when relying on a pseudo random number generator (PRNG), it will lead to a substantial reduction in the key space.

[0018] (2) Threat of weak passwords in human-computer interaction: User-set passwords are often vulnerable to brute-force attacks or rainbow table attacks due to weaknesses such as insufficient length, single character set, and inclusion of dictionary words; and passwords may be stolen by keyloggers, shoulder surfing and other means during input.

[0019] (3) Centralization risk of key escrow system: The centralized key management server (KMS) constitutes a single point of failure (SPOF). Once it suffers a denial-of-service attack (DoS) or privilege escalation vulnerability, all dependent devices will be unable to decrypt data normally.

[0020] (4) Lack of key rotation and disaster recovery mechanisms: Long-term use of the same key increases the amount of accumulated ciphertext and amplifies the probability of successful cryptanalysis attacks; the lack of an automated key rotation mechanism makes manual operation complex and error rate restricts the implementation of security policies; if there is no backup and recovery mechanism in the case of lost or damaged keys, the data will become permanently inaccessible.

[0021] 3. The closed ecosystem of encrypted data and the barriers to cross-platform interoperability: (1) Vendor lock-in effect of proprietary encryption formats: Some schemes use non-standard proprietary file formats to encapsulate ciphertext, and the encryption header contains vendor-specific metadata structures, which forces users to be bound to specific decryption software and cannot freely choose third-party tools or migrate to other platforms.

[0022] (2) Data silo problem caused by strong platform dependence: When encryption implementation depends on specific operating system APIs (such as Windows CNG, macOS Keychain) or hardware security modules (HSM), encrypted data cannot be transferred between heterogeneous environments (Linux / Windows / macOS / Android / iOS), which seriously restricts business scenarios such as emergency recovery, off-site backup, and cross-departmental collaboration.

[0023] (3) Fragmentation and maintenance costs of decryption toolchain: Dedicated decryption clients need to be developed, tested and deployed separately for different platforms. Software version fragmentation leads to an exponential increase in the complexity of the compatibility matrix, resulting in high long-term maintenance costs and difficulty in ensuring the consistency of functions across platforms.

[0024] Based on this, embodiments of the present invention provide a transparent encryption method for multimedia data. The specific scheme of this transparent encryption method for multimedia data provided by the present invention will be described in detail below with reference to the accompanying drawings. Please refer to... Figure 1 The illustration shows a schematic diagram of the implementation process of a multimedia data transparent encryption method according to an embodiment of the present invention. The method includes: 101, retrieve the multimedia data to be encrypted.

[0025] Here, multimedia data can include video, images, and other data. A four-layer encryption technology stack is constructed, including: a first layer (block device abstraction layer), a second layer (encryption mapping layer), a third layer (file system layer), and a fourth layer (application service layer). The first layer, the block device abstraction layer, provides a unified block device access interface, shielding the differences in underlying storage media (SD card / eMMC / SSD / hard disk drive, etc.).

[0026] Technical implementation: The Linux kernel block device subsystem (Block Layer) abstracts block devices through the gendisk structure, provides the submit_bio() interface to receive I / O requests, and optimizes scheduling through request_queue.

[0027] The second layer: The function of the encryption mapping layer is to insert encryption conversion logic between the raw block device and the file system, and to perform bidirectional conversion of encrypted data.

[0028] Technical Implementation: The dm-crypt target type of the Device Mapper framework defines the mapping relationship through the device mapper table: 0 <size>crypt aes-xts-plain64 <key>0 / dev / sdX 0, the kernel creates / dev / mapper / for each mapping. <name>Virtual block device node.

[0029] The third layer: The function of the file system layer is to organize data into a file / directory tree structure and provide functions such as metadata management, space allocation, and log recovery. Technical implementation: in / dev / mapper / <name>Journaling file systems such as Ext4 / XFS are created on encrypted devices. The file system driver sends all I / O requests to the encryption mapping layer, making encryption completely transparent.

[0030] The fourth layer: the application business layer, is responsible for implementing business logic such as video capture, storage, retrieval, playback, and export.

[0031] Technical implementation: Files are manipulated through standard POSIX APIs (open / write / read / close / mmap) or high-level language I / O libraries, without the need to integrate any encryption libraries or modify the code.

[0032] 102. Perform an activity verification on the block device corresponding to the multimedia data.

[0033] Here, by detecting the type, capacity, and existing file system type of the block device, it is determined whether the block device has an active mount point, thus realizing the verification of the block device's activity.

[0034] In some possible implementations, the activity of the block device is verified by determining the block device type, capacity, and file system type of the block device; and based on the block device type, capacity, and file system type, determining whether the block device has no active mount point and whether it is occupied by an active process.

[0035] Here, during the encryption initialization phase, the block device is in an unencrypted state, meaning it's a standard file system. Device detection and pre-verification are performed during this phase. The operations include: using a detection tool (lsblk -f / dev / sdX) to detect the block device type, capacity, and existing file system type; then proceeding to the verification phase, which confirms that the device has no active mount points (checking ` / proc / mounts`) and no active processes using it (`lsof / dev / sdX`); after verification, the following JSON information about the device is output: `{"device": " / dev / sdX", "size_gb": 32, "type": "sd", "mounted": false}`.

[0036] 103. If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized so that the block device enters the filtering state.

[0037] Here, if the block device has no active mount point, user authentication and password strength verification are performed, and the original file system is unloaded and the cache is cleared, thereby achieving encryption initialization and causing the block device to enter the filtering state.

[0038] In some possible implementations, step 103 above can be achieved by... Figure 2 The steps shown are to be implemented as follows: 201. If the block device has no active mount point, output a first prompt message to prompt the user to enter an encrypted password.

[0039] Here, the initial prompt can be a text prompt, or it can be a voice prompt, an image prompt, etc.

[0040] 202. Calculate the entropy value based on the encrypted password input by the user, and determine whether the entropy value meets the preset policy requirements.

[0041] Here, the preset strategy requirement can be a custom requirement; for example, the preset strategy requirement can be a custom entropy value.

[0042] 203. If the entropy value does not meet the preset strategy requirements, determine and output the target weakness in the encryption password so that the block device enters the filtering state.

[0043] Here, if the entropy value does not meet the preset policy requirements, that is, it does not meet the custom entropy value, then the processing is determined to have failed. This means that the encrypted password entered by the user is weak, and the specific weakness is displayed so that the user can re-enter the password until the processing is successful, so that the block device can enter the filtering state.

[0044] In some possible implementations, based on the target weakness, a second prompt message is output to prompt the user to re-enter the encrypted password. The entropy value of the re-entered encrypted password is calculated and it is determined whether the entropy value meets the requirements of the preset strategy. This process continues until the entropy value of the re-entered encrypted password meets the preset strategy, at which point the block device is determined to enter the filtering state.

[0045] Here, the operations involved in the user authentication and password strength verification process include: prompting the user to enter an encrypted password (using getpass() to hide the echo) and requiring the user to confirm again; calling the password strength evaluation function to calculate the entropy value and check whether it meets the preset policy requirements; if the encrypted password is weak, displaying the specific weakness (such as "contains the dictionary word 'password'") and requiring the user to re-enter the encrypted password.

[0046] The output format of the second prompt message can be the same as or different from that of the first prompt message. After the user re-enters the encrypted password, the entropy value of that password is recalculated, and it is determined whether the entropy value meets the preset policy requirements. This process continues until the entropy value of the user's re-entered encrypted password meets the preset policy, indicating successful processing, and the device enters a filtering state. This ensures both the accuracy of the input encrypted password and improves the security of subsequent encryption of multimedia data.

[0047] After user authentication and password strength verification, the original file system is unloaded and the cache is cleared; for example, the original file system and cache of the block device are determined; and the original file system and cache are cleaned up to obtain the block device in the filtered state.

[0048] Here, the operations involved in unmounting the original file system and clearing the cache include unmounting and clearing the cache (umount / dev / sdX* 2> / dev / null) to ensure that no residual data remains in memory and to avoid conflicts in subsequent operations.

[0049] 104. Perform encryption mapping on the block device in the filtered state to determine that the block device has entered the encrypted state.

[0050] Here, the encrypted mapping operation "echo-n" is used. <password>The "|cryptsetup open" command enables encrypted mapping of the block device in the filtered state, allowing the block device to transition from the filtered state to the encrypted state.

[0051] In some possible implementations, step 104 above can be achieved through... Figure 3 The steps shown are to be implemented as follows: 301. Perform an encrypted mapping between the block device in the filtered state and the corresponding file system, and determine whether the block device mapping is successfully established.

[0052] Here, the encryption operation "echo-n" is used. <password>The "|cryptsetup open" command establishes an encrypted mapping between a block device and its corresponding file system, and simultaneously checks whether the mapping was successfully established. For example, it checks whether the / dev / mapper / encrypted_sdcard device node was created successfully to determine if the encrypted mapping was established successfully.

[0053] In some possible implementations, step 301 above can be achieved through the following process: First, determine the plaintext sector data, ciphertext sector data, 256-bit data encryption key, and 256-bit adjustment value generation key of the block device; Next, the adjustment value is obtained by multiplying the 256-bit adjustment value generation key, the block offset corresponding to the block device, and the primitive element by a domain; Next, the adjustment value and the plaintext sector data are XORed to obtain the first XOR result; Next, the first XOR result is multiplied by the 256-bit data encryption key, and the product is XORed with the adjustment value to obtain the second XOR result; Finally, based on the first XOR result, an encrypted mapping is performed between the block device in the filtered state and the corresponding file system.

[0054] Here, the AES-XTS (Advanced Encryption Standard - XEX-based Tweaked-codebook mode with ciphertext Stealing) algorithm is adopted. The AES algorithm is based on the Rijndael block cipher, which includes 128 / 192 / 256-bit key lengths and a 14-round substitution-permutation network (SPN) structure, realizing the standardized status and cryptographic guarantee of the AES-XTS algorithm.

[0055] Using a total key length of 512 bits (decomposed into two 256-bit subkeys K1 and K2), the key search space reaches Even assuming that future quantum computers will implement Grover's algorithm and reduce the search complexity to... Still need This operation far exceeds the total number of atoms in the universe (approximately...). It is physically unbreakable; thus achieving a brute-force cracking computational complexity of a 512-bit composite key space.

[0056] XTS mode introduces sector address-related adjustment values ​​(Tweak) to cryptographically decorrelate the ciphertext blocks corresponding to each Logical Block Address (LBA), completely eliminating the structural leakage problem of the same plaintext producing the same ciphertext in ECB mode; at the same time, it avoids the IV reuse vulnerability and error propagation characteristics of CBC mode, and achieves sector-level parallel encryption and random access capabilities.

[0057] The SHA-512 hash algorithm is used as the key derivation function (KDF) to map user passwords to high-entropy key material. SHA-512's 512-bit output length and 2^128 collision resistance ensure that even if an attacker obtains the derived key, they cannot recover the original password through reverse computation. Combined with appropriate salt and iteration counts, it effectively resists pre-computed attacks (such as rainbow tables) and GPU-accelerated brute-force attacks, thereby improving the one-wayness and resistance to dictionary attacks of the key derivation function.

[0058] Among some possible implementations, the technical mechanisms and security features of the AES-XTS cryptographic algorithm include: (1) The mathematical principles of the XEX (XOR-Encrypt-XOR) adjustment mode, including: The encryption process in XTS mode can be formally represented as: ; Where: P represents plaintext sector data (512 / 4096 bytes); C represents encrypted sector data; K1 represents the data encryption key (256 bits). K2 represents the adjustment value to generate the key (256 bits); T represents the adjustment value, calculated as follows: Where LBA stands for logical block address. for The domain primitive, j is the offset within the block.

[0059] E represents the AES block cipher encryption function.

[0060] This represents the XOR algorithm.

[0061] This represents Galois field multiplication.

[0062] (2) Key isolation design of dual-key structure, including: K1 and K2 functions are strictly separated: K1 is used for actual data encryption, while K2 is only used to generate adjustment values ​​related to sector positions. Even if an attacker obtains the plaintext-ciphertext pair of a sector, they cannot use K2 to deduce K1, and vice versa, thus achieving isolation of key responsibilities.

[0063] (3) The stateless nature of the plain64 IV generation strategy includes: The adjustment value directly uses the 64-bit sector number (LBA), eliminating the need to maintain a global counter or random IV pool. This stateless design naturally supports parallelization and out-of-order execution of cryptographic operations, while avoiding security vulnerabilities caused by IV reuse or prediction in CBC mode.

[0064] (4) The processing of unaligned data by ciphertext interception techniques includes: When the data at the end of a sector is less than one AES block (16 bytes), XTS uses ciphertext stealing technology to borrow part of the ciphertext from the previous block to complete the padding, ensuring that the length of the ciphertext is strictly equal to that of the plaintext, and avoiding the risk of length leakage introduced by padding schemes such as PKCS#7.

[0065] 302. If the block device mapping is successfully established, the block device is determined to enter the encrypted state.

[0066] In some embodiments, a file system is unmounted, encryption mapping is disabled, and a new file system is created in the block device in the encrypted state; based on the new file system, the status flags of the block device are updated, thereby enabling more explicit identification of the various states of the block device.

[0067] Here, block devices include four core states: 1) Unencrypted state (PLAINTEXT): The device uses a standard file system; 2) Encrypted state: The mapping has been established and mounted normally, and can be read and written normally; 3) Verification failure status (AUTH_FAILED): Incorrect password or corrupted mapping, access denied; 4) Filtering state (TRANSITIONING): Encryption initialization or erasure operation is being performed; State transition rules include: PLAINTEXT --[Initialize Encryption]-->ENCRYPTED; ENCRYPTED --[Incorrect password]-->AUTH_FAILED; AUTH_FAILED --[Re-enter password]-->ENCRYPTED; ENCRYPTED --[Erase Decryption]-->PLAINTEXT; By establishing an encrypted mapping for the block device in steps 301 and 302 above, the block device can be accurately entered into the encrypted state.

[0068] 105. Perform password verification on the block device in the encrypted state. If the password verification fails, perform decryption and erasure operations on the block device in the encrypted state, and repeat the process of liveness verification, encryption initialization, and encryption mapping until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

[0069] Here, after establishing the encrypted mapping, the encrypted device is formatted and a file system is created, and the mapped device is mounted and automount rules are configured. Password verification is performed on the block device in the encrypted state. If password verification fails, a decryption and erasure operation is performed on the encrypted block device, bringing it to an unencrypted state. Steps 102 to 104 are repeated until the password verification for the encrypted block device is successful, yielding the encrypted data. In some possible implementations, the decryption and erasure operation includes: 1) Unmounting the file system: `umount / mnt / recordings`; 2) Closing the encrypted mapping: `cryptsetupclose encrypted_sdcard`; 3) Creating a new file system on the original device: `mkfs.ext4 -F / dev / sdX`; 4) Updating the block device's status flags.

[0070] In some embodiments, after a block device enters an encrypted state, the legacy mapping of the block device in the encrypted state is detected and closed; the file system is mounted on the block device in the encrypted state and the encryption state is updated; and the updated encryption state is sent to the application layer corresponding to the block device.

[0071] Here, by executing the "cryptsetup open" operation to open the encrypted device and branching the process, the file system is mounted, the encryption state is updated (ENCRYPTED), and the application layer is notified of the branch success. If the branch fails, the updated state is "AUTH_FAILED".

[0072] In this embodiment of the invention, after acquiring the multimedia data to be encrypted, the activity of the block device corresponding to the multimedia data is verified. If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized to allow the block device to enter a filtering state. This enables more accurate detection and pre-verification of the device. Then, the block device in the filtering state is encrypted and mapped to determine if it has entered an encrypted state. Thus, by encrypting and mapping the block device in the filtering state, the entry of the block device into the encrypted state can be more precisely controlled. Finally, a password verification is performed on the block device in the encrypted state. If the password verification fails, a decryption and erasure operation is performed on the block device in the encrypted state, and the processes of activity verification, encryption initialization, and encryption mapping are repeated until the password verification of the block device in the encrypted state is successful, thus obtaining the encrypted data. In this way, by performing password verification on the block device in the encrypted state, if the password verification fails, the process returns to the activity verification stage, and repeats the activity verification, encryption initialization, and encryption mapping until the password verification is successful, thereby obtaining the encrypted data. This can improve the accuracy of the encrypted data and reduce security risks.

[0073] The present invention provides a multimedia data transparent encryption method, wherein the zero-intrusion transparent encryption architecture based on a kernel-mode device mapper includes: (1) I / O stack integration mechanism of Device Mapper framework: This invention utilizes the dm-crypt target type of the Linux kernel Device Mapper subsystem to insert an encryption conversion layer between the block device driver and the file system. All I / O requests (read / write / ioctl) are transmitted to upstream and downstream only after the encryption / decryption operation is completed in kernel space. When the application accesses data through the standard POSIX interface (open / read / write), it is completely unaware of the encryption, realizing true transparent encryption.

[0074] (2) Compatibility guarantee with zero code modification at the application layer: Since the encryption operation is performed at the block device abstraction layer, the file system (Ext4 / XFS / Btrfs, etc.) treats the encrypted mapping device as an ordinary block device. Existing video capture, playback, export and other applications can run directly on the encrypted storage without any code modification or recompilation, which is perfectly compatible with existing business processes and protocol stacks.

[0075] (3) Unified encrypted protection of file system metadata and user data: Block device layer encryption ensures that all data written to the storage medium, including file system metadata such as inodes, directory entries, extended attributes, and logs, is in an encrypted state, avoiding the problem of plaintext leakage of sensitive information such as file names, directory structures, and access times in file-level encryption schemes.

[0076] (4) Automated orchestration of state machine in hot-swappable scenarios: Integrating device manager (udev) rules and service unit (systemd) to achieve automatic capture of storage card (Secure Digital Card, SD) insertion events, on-demand creation of encrypted mapping, automatic mounting of file system and graceful degradation in case of failure. The entire process does not require manual intervention, significantly reducing the complexity of operation and maintenance and the risk of operational errors.

[0077] Ecosystem interoperability and migration flexibility based on open standards include: (1) Cross-platform consistency of the cryptsetup toolchain: cryptsetup is the user-space management tool of dm-crypt, which has been integrated by default in mainstream Linux distributions (Ubuntu / Debian / CentOS / Fedora / Arch, etc.). macOS can be installed via the Homebrew package manager, and Windows environments can use it with the help of WSL2 (Windows Subsystem for Linux 2)'s native block device passthrough capabilities. A unified command-line interface (CLI) ensures that the operation process is consistent across platforms.

[0078] (2) LUKS specification compatibility and tool ecosystem richness: Although the present invention can use plain mode (headless encryption) to maximize storage space utilization, it is fully compatible with the LUKS (Linux Unified Key Setup) specification, supports the key slot mechanism in the LUKS header to realize advanced functions such as multi-password management, key rotation, and key revocation, and can be seamlessly integrated with third-party tools such as cryptmount and zuluCrypt.

[0079] (3) Raw device encryption paradigm without proprietary file formats: Encrypted data is stored directly in the raw sectors of the block device without introducing any proprietary file headers or container formats. From a physical perspective, it is only a pseudo-random byte stream. This design allows encrypted data to be copied at the block level and backed up off-site using standard Unix tools such as dd and rsync, and even supports online expansion (through LVM or mdadm) without the need for dedicated software intervention.

[0080] (4) Native block device mapping support of Windows subsystem: WSL2 implements direct binding between the / dev / sdX device node and the Windows physical disk through the 9P protocol, enabling the Linux kernel driver to natively access the storage device of the Windows host. When cryptsetup is executed in the WSL2 environment, its behavior is completely consistent with that of the native Linux environment, breaking the barrier to encrypted data access on the Windows platform.

[0081] Performance optimization and resource efficiency for phase-oriented streaming write scenarios include: (1) Synergistic effect of sequential write mode and block alignment optimization: In video recording scenarios, the data write mode exhibits significant sequentiality and large block characteristics (typically 4KB-1MB continuous I / O), which naturally matches the sector-level processing granularity of block device encryption. When I / O requests are aligned to 4KB pages, read-modify-write operations can be avoided, and the entire sector encryption write can be completed directly, minimizing additional overhead.

[0082] (2) Scalability of multi-core parallel encryption: The combination of the AES-NI (Advanced Encryption Standard New Instructions) hardware acceleration instruction set and the sector independence feature of XTS mode enables multiple CPU cores to process encryption operations of different sectors in parallel, with performance scaling approximately linearly with the number of cores. Actual tests show that on x86 platforms supporting AES-NI, block device encryption can reduce CPU usage by 60%-80% compared to application-layer encryption.

[0083] (3) Avoid the overhead of repeated initialization in file-level encryption: File-level encryption schemes require maintaining an independent encryption context (key, IV, padding state) for each file. In recording scenarios, frequent creation and switching of files (such as time-segmented) will generate a large amount of initialization and context switching overhead. Block device encryption establishes a mapping once and maintains it for a long time, eliminating such redundant operations.

[0084] (4) Minimize latency of direct I / O path: Kernel-mode encryption avoids data copying between user mode and kernel mode (reducing one copy_to_user / copy_from_user call), while dm-crypt supports the bypass_kcryptd parameter to enable synchronous encryption mode, so that I / O requests are directly encrypted in the context of the submission thread and sent to the block device driver, further reducing latency jitter.

[0085] The technical implementation path for cross-platform compatibility of a multimedia data encryption method provided in this embodiment of the invention includes: (1) Native support in the Linux environment, including: All mainstream kernels (≥3.0) compile the dm-crypt module by default, and the distribution comes pre-installed with the cryptsetup toolkit, so it can be used without additional configuration.

[0086] (2) Adaptation solutions for the MacOS environment, including: Install cryptsetup and its dependencies via Homebrew: brew install cryptsetup brew install --cask osxfuse # or macFUSE Limitations: macOS lacks native Device Mapper support, and cryptsetup uses the FUSE user-space file system for simulation, resulting in slightly inferior performance compared to the native Linux implementation.

[0087] (3) The WSL2 integration path in the Windows environment includes: 1) WSL2 provides native block device mounting capabilities: # Mounting a physical disk to WSL in PowerShell wsl --mount \\.\PhysicalDrive1 --bare 2) In a WSL2 Linux environment: Operate in the standard Linux manner, using `cryptsetup open / dev / sdcencrypted` to open an encrypted partition or device and make it accessible. Then, use `mount / dev / mapper / encrypted / mnt / data` to mount the encrypted storage device to the specified location on the file system.

[0088] In this embodiment of the invention, the state transition process of the block device is as follows: Figure 4 As shown, first, the block device is in an unencrypted state (PLANINTEXT). Encryption initialization is performed on the user of this unencrypted block device, entering a filtering state (TRANSITIONING). Then, encryption mapping is performed. If the mapping is successful, the block device enters an encrypted state (ENCRYPTED). Afterwards, password verification is performed on the encrypted block device. If the password verification fails, the device enters an AUTH_FAILED state, performing erase / write / decryption. After erasure, it returns to the unencrypted state. During the encryption of multimedia data, the SD card is formatted and no password is set, as shown in the following diagram. Figure 5 As shown, the SD card has been password-protected and the verification was successful. Figure 6 As shown, the SD card encryption verification failed. Figure 7 As shown.

[0089] In this embodiment of the invention, a novel multimedia data protection method based on transparent encryption at the block device layer achieves a balance between simplicity of engineering implementation, cross-platform interoperability, and high performance while ensuring cryptographic security.

[0090] This invention provides a multimedia data transparent encryption system. Please refer to [link / reference]. Figure 8 This diagram illustrates the structural composition of a multimedia data transparent encryption system according to an embodiment of the present invention. The system 800 includes: Acquisition module 801 is used to acquire the multimedia data to be encrypted; Verification module 802 is used to perform activity verification on the block device corresponding to the multimedia data; Encryption module 803 is used to initialize encryption of the user identity corresponding to the multimedia data if the block device has no active mount point, so that the block device enters the filtering state; The mapping module 804 is used to perform encrypted mapping on the block device in the filtered state and determine that the block device has entered the encrypted state; The verification module 805 is used to perform password verification on the block device in the encrypted state. If the password verification fails, the block device in the encrypted state is decrypted and erased, and the process of activity verification, encryption initialization and encryption mapping is repeated until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

[0091] In some possible implementations, the verification module 802 is further configured to determine the block device type, capacity, and file system type of the block device; based on the block device type, capacity, and file system type, determine whether the block device has no active mount point and whether it is occupied by an active process, so as to complete the activity verification of the block device.

[0092] In some possible implementations, the encryption module 803 is further configured to: output a first prompt message to prompt the user to enter an encryption password if the block device has no active mount point; calculate an entropy value based on the encryption password entered by the user and determine whether the entropy value meets the preset policy requirements; if the entropy value does not meet the preset policy requirements, identify and output the target weakness in the encryption password so that the block device enters a filtering state.

[0093] In some possible implementations, the encryption module 803 is further configured to output a second prompt message based on the target weakness to prompt the user to re-enter the encryption password, calculate the entropy value of the re-entered encryption password and determine whether the entropy value meets the preset policy requirements, until the entropy value of the re-entered encryption password meets the preset policy, and determine that the block device enters the filtering state.

[0094] In some possible implementations, the encryption module 803 is further configured to determine the original file system and cache of the block device; perform a cleanup operation on the original file system and cache to obtain the block device in the filtered state.

[0095] In some possible implementations, the mapping module 804 is further configured to perform encrypted mapping between the block device in the filtering state and the corresponding file system, and determine whether the block device mapping is successfully established; if the block device mapping is successfully established, it is determined that the block device has entered the encrypted state.

[0096] In some possible implementations, the mapping module 804 is further configured to: determine the plaintext sector data, ciphertext sector data, 256-bit data encryption key, and 256-bit adjustment value generation key of the block device; perform field multiplication on the 256-bit adjustment value generation key, the block offset corresponding to the block device, and the primitive to obtain an adjustment value; perform XOR processing on the adjustment value and the plaintext sector data to obtain a first XOR result; multiply the first XOR result with the 256-bit data encryption key, and perform XOR on the product with the adjustment value to obtain a second XOR result; and perform encrypted mapping between the block device in the filtering state and the corresponding file system based on the first XOR result.

[0097] In some possible implementations, the mapping module 804 is further configured to detect and close the legacy mapping of the block device in the encrypted state; mount the file system on the block device in the encrypted state and update the encryption state; and send the updated encryption state to the application layer corresponding to the block device.

[0098] In some possible implementations, the mapping module 804 is further configured to unload the file system, close the encryption mapping, and create a new file system in the block device in the encrypted state; and update the status flag of the block device based on the new file system.

[0099] Optionally, the transmission medium can be a wired link (e.g., but not limited to, coaxial cable, optical fiber, and Digital Subscriber Line (DSL)) or a wireless link (e.g., but not limited to, Wireless Fidelity (WIFI), Bluetooth, and mobile block device networks). It should be noted that the control block device provided in the above embodiments is only an example illustrating the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer block device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0100] Figure 9 This is a schematic diagram of the structure of a computer block device provided in an embodiment of the present invention. For example, as shown... Figure 9 As shown, the computer block device 900 includes: a memory 901, a processor 902, and a computer program 903 stored in the memory 901 and running on the processor 902, wherein when the processor 902 executes the computer program 903, the computer block device can execute any of the multimedia data transparent encryption methods described above.

[0101] Furthermore, this embodiment of the invention also protects a control block device, which may include a memory and a processor. The memory stores executable program code, and the processor is used to call and execute the executable program code to perform a multimedia data transparent encryption method provided by this embodiment of the invention. This embodiment can divide the control block device into functional modules based on the above method example. For example, each module can correspond to a specific function, or two or more functions can be integrated into a processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents a logical functional division; other division methods may exist in actual implementation. It should also be noted that all relevant content of each step involved in the above method embodiment can be referenced to the functional description of the corresponding functional module, and will not be repeated here. It should be understood that the control block device provided in this embodiment is used to execute the above-mentioned multimedia data transparent encryption method, and therefore can achieve the same effect as the above-mentioned implementation method. When using integrated units, the control block device may include a processing module and a storage module. When the control block device is applied to a block device, the processing module can be used to control and manage the actions of the block device. The storage module can be used to support block devices in executing mutual program code, etc. The processing module can be a processor or controller, which can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module can be a memory.

[0102] Furthermore, the control block device provided in the embodiments of the present invention may specifically be a chip, component, or module. The chip may include a connected processor and a memory. The memory stores instructions, and when the processor calls and executes the instructions, the chip can execute the multimedia data transparent encryption method provided in the above embodiments. This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned method steps to implement the multimedia data transparent encryption method provided in the above embodiments.

[0103] This embodiment also provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the aforementioned related steps to implement the multimedia data transparent encryption method provided in the above embodiment. The control block device, computer-readable storage medium, computer program product, or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they achieve can be referred to in the beneficial effects of the corresponding methods provided above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art can understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the control block device can be divided into different functional modules to complete all or part of the functions described above. In the embodiments provided by this invention, it should be understood that the disclosed control block device and method can be implemented in other ways. For example, the control block device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another control block device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, control block device or unit, and can be electrical, mechanical or other forms.

[0104] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multiple task processing and parallel processing are possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above content is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be covered within the protection scope of the present invention.< / password> < / password> < / name> < / name> < / key> < / size>

Claims

1. A method for transparent encryption of multimedia data, characterized in that, The method includes: Retrieve the multimedia data to be encrypted; The activity of the block device corresponding to the multimedia data is verified. If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized so that the block device enters the filtering state. Encryption mapping is performed on the block device in the filtered state to determine that the block device has entered the encrypted state; Password verification is performed on the block device in the encrypted state. If the password verification fails, the block device in the encrypted state is decrypted and erased. The process of liveness verification, encryption initialization and encryption mapping is repeated until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

2. The method according to claim 1, characterized in that, The activity verification of the block device corresponding to the multimedia data includes: Determine the block device type, capacity, and file system type of the block device; Based on the block device type, capacity, and file system type, determine whether the block device has no active mount point and whether it is occupied by an active process, so as to complete the activity verification of the block device.

3. The method according to claim 1, characterized in that, If the block device has no active mount point, the user identity corresponding to the multimedia data is encrypted and initialized to allow the block device to enter a filtering state, including: If the block device has no active mount point, output a first prompt message to prompt the user to enter an encrypted password; The entropy value is calculated based on the encrypted password input by the user, and it is determined whether the entropy value meets the preset policy requirements. If the entropy value does not meet the preset policy requirements, the target weakness in the encrypted password is identified and output so that the block device enters the filtering state.

4. The method according to claim 3, characterized in that, The method further includes: Based on the target weakness, a second prompt message is output to prompt the user to re-enter the encrypted password. The entropy value of the encrypted password re-entered by the user is calculated and it is determined whether the entropy value meets the requirements of the preset strategy. The process continues until the entropy value of the encrypted password re-entered by the user meets the preset strategy, at which point the block device is determined to enter the filtering state.

5. The method according to claim 3, characterized in that, The method further includes: Determine the original file system and cache of the block device; The original file system and cache are cleaned up to obtain the block device in the filtered state.

6. The method according to claim 1, characterized in that, The step of performing encrypted mapping on the block device in the filtered state to determine that the block device has entered the encrypted state includes: An encrypted mapping is performed between the block device in the filtered state and the corresponding file system, and it is determined whether the block device mapping is successfully established. If the block device mapping is successfully established, the block device is determined to have entered the encrypted state.

7. The method according to claim 6, characterized in that, The method further includes: The plaintext sector data, ciphertext sector data, 256-bit data encryption key, and 256-bit adjustment value of the block device are determined to generate a key; The adjustment value is obtained by multiplying the 256-bit adjustment value by a key, the block offset corresponding to the block device, and the primitive element. The adjustment value and the plaintext sector data are XORed to obtain the first XOR result; Multiply the first XOR result by the 256-bit data encryption key, and then XOR the product with the adjustment value to obtain the second XOR result; Based on the first XOR result, an encrypted mapping is performed between the block device in the filtered state and the corresponding file system.

8. The method according to claim 1, characterized in that, The method further includes: Detect and disable legacy mappings of the block device in the encrypted state; Mount the file system and update the encryption status of the block device in the encrypted state; The updated encryption state is sent to the application layer corresponding to the block device.

9. The method according to claim 1, characterized in that, The method further includes: Unmount the file system, disable the encryption mapping, and create a new file system in the block device that is in the encrypted state; Based on the new file system, update the status flags of the block device.

10. A multimedia data transparent encryption system, characterized in that, The system includes: The acquisition module is used to acquire the multimedia data to be encrypted; The verification module is used to verify the activity of the block device corresponding to the multimedia data; The encryption module is used to initialize the encryption of the user identity corresponding to the multimedia data if the block device has no active mount point, so that the block device enters the filtering state. The mapping module is used to perform encrypted mapping on the block device in the filtered state and determine that the block device has entered the encrypted state; The verification module is used to verify the password of the block device in the encrypted state. If the password verification fails, the block device in the encrypted state is decrypted and erased, and the process of liveness verification, encryption initialization and encryption mapping is repeated until the password verification of the block device in the encrypted state is successful and the encrypted data is obtained.

Images