CN118821177A - Multimedia encryption method, device, electronic device and storage medium - Google Patents

Abstract

The application discloses a multimedia encryption method, a device, an electronic device and a storage medium, under the condition of receiving a system call initiated by a user application program, judging whether the system call relates to a multimedia file in a mounting directory in the encrypted file system or not, and judging whether the system call is in a current kernel queue or not. And in the case that the former conditions are met and the writing operation is carried out on the multimedia file, the multimedia file is encrypted in parallel, a target multimedia file is generated, and response information is returned to the user application program. Thus, the parallel encryption file system effectively provides a high performance encryption solution to handle large data files and reduces the impact of heavy workload and thus can be used to meet real-time requirements. The system response time can be shortened, and the performance of the existing encrypted file system can be improved.

Description

Multimedia encryption method, device, electronic device and storage medium

Technical Field

The present application belongs to the field of information security, and in particular relates to a multimedia encryption method, device, electronic device and storage medium.

Background Art

Multimedia data such as images and videos currently play an important role in society, and a large number of multimedia files are stored on disk drives and removable storage media. However, many potential threats and security attacks are aimed at infringing the privacy of personal information on these storage devices, especially multimedia, which has attracted great attention.

In the prior art, File System in User Space (FUSE) is a Unix-like framework that allows non-privileged users to implement a file system to perform specific functions in user space. This approach can provide storage security without editing the underlying kernel level or significantly changing the design and implementation of the basic file system. However, the prior art still has some shortcomings, including long read and write response times, and further improvement and optimization are needed.

Summary of the invention

The embodiments of the present application provide a multimedia encryption method, device, electronic device and storage medium, which can achieve the lowest possible response time when reading or writing stored multimedia files.

In a first aspect, an embodiment of the present application provides a multimedia encryption method, which may include:

In the case of receiving a system call initiated by a user application, obtaining a first judgment result according to the system call, wherein the first judgment result is used to indicate whether the system call involves a multimedia file in a mount directory in the encrypted file system;

When the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, comparing the system call with a kernel queue to obtain a second judgment result, wherein the second judgment result is used to indicate whether the system call is in a current kernel queue;

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file;

When the target multimedia file is generated, response information is returned to the user application.

In one embodiment, when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, after comparing the system call with the kernel queue to obtain a second judgment result, the method further includes:

When the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file.

In one embodiment, the above-mentioned when a system call initiated by a user application is received, before obtaining a first judgment result according to the system call, further includes:

generating an encryption key and a decryption key upon receiving a first storage instruction, wherein the decryption key and the encryption key are symmetric keys to each other, and the first storage instruction is used to store the multimedia file in a mount directory in the encrypted file system for the first time;

The multimedia file is encrypted in parallel according to the random encryption key, and an encrypted version of the multimedia file is generated in a mount directory in the encrypted file system.

In one of the embodiments, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file includes:

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel by pairing the encryption keys to generate the target multimedia file;

Return the target multimedia file to the callback layer.

In one embodiment, when the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file, including:

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, extracting a header of the encrypted multimedia file and calling a decryption key, the encryption key and the decryption key are symmetric keys to each other;

When the user identity verification is successful, the encrypted multimedia file is decrypted in parallel according to the decryption key to generate and return the target multimedia file.

In one of the embodiments, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file includes:

When the second judgment result indicates that the system call is in the current kernel queue and the multimedia file is written, the CPU utilization of each thread is obtained according to the amount of time each thread is executed on the kernel;

According to the CPU utilization of each thread and the load of multiple cores, the processing tasks of encrypting the multiple multimedia files are allocated in parallel to generate multiple target multimedia files.

In one of the embodiments, the processing tasks of encrypting the plurality of multimedia files are allocated in parallel according to the CPU utilization of each thread and the load of the plurality of cores to generate the plurality of target multimedia files, including:

According to the CPU utilization of each thread and the load of multiple cores, multiple sub-processes are created to distribute the processing tasks of encrypting multiple multimedia files in parallel, and multiple target multimedia files are generated. Each sub-process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other.

In one of the embodiments, the processing tasks of encrypting the plurality of multimedia files are allocated in parallel according to the CPU utilization of each thread and the load of the plurality of cores to generate the plurality of target multimedia files, including:

According to the CPU utilization of each thread and the load of multiple cores, multiple threads belonging to a single parent process are created through a thread method, and the processing tasks of encrypting multiple multimedia files are allocated in parallel to generate multiple target multimedia files. Each child process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other. The multiple threads belonging to a single parent process share the same address space and parameters through global variables.

In a second aspect, an embodiment of the present application provides a multimedia encryption device, which may include:

A first judgment module, configured to, upon receiving a system call initiated by a user application, obtain a first judgment result according to the system call, wherein the first judgment result is used to indicate whether the system call involves a multimedia file in a mount directory in the encrypted file system;

A second judgment module is used to compare the system call with the kernel queue to obtain a second judgment result when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, and the second judgment result is used to indicate whether the system call is in a current kernel queue;

an encryption module, configured to, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypt the multimedia file in parallel to generate a target multimedia file;

The returning module is used to return the response information to the user application program when the target multimedia file is generated.

In a third aspect, an embodiment of the present application provides an electronic device, the device comprising:

processor;

a memory for storing processor-executable instructions;

The processor is configured to execute instructions to implement the multimedia encryption method as shown in any one of the embodiments of the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer storage medium, on which a computer program is stored. When the computer program is executed by a processor, the multimedia encryption method shown in any one of the embodiments of the first aspect is implemented.

In the fifth aspect, an embodiment of the present application also provides a computer program product, which includes a computer program stored in a readable storage medium, and at least one processor of the device reads and executes the computer program from the storage medium, so that the device implements the multimedia encryption method shown in any one of the embodiments of the first aspect.

The embodiments of the present application provide a multimedia encryption method, device, electronic device, and storage medium. Compared with the prior art, the present application has the following beneficial effects:

A multimedia encryption method, device, electronic device and storage medium according to an embodiment of the present application, when receiving a system call initiated by a user application, determines whether the system call involves a multimedia file in a mounted directory in the encrypted file system. When the system call involves a multimedia file in a mounted directory in the encrypted file system, determines whether the system call is in the current kernel queue. When the system call is in the current kernel queue and a write operation is performed on the multimedia file, the multimedia file is encrypted in parallel to generate a target multimedia file, and a response message is returned to the user application.

Therefore, the parallel encrypted file system effectively provides a high-performance encryption solution to handle large data files and reduce the impact caused by heavy workloads, so it can be used to meet real-time requirements. It can shorten the system response time and improve the performance of the existing encrypted file system.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

FIG1 is a schematic diagram of a flow chart of a multimedia encryption method provided in an embodiment of the present application;

FIG2 is a diagram of a parallel file system architecture based on a multi-core processor provided in an embodiment of the present application;

FIG3 is a flowchart of a BingxingFS component for multimedia file encryption/decryption provided in an embodiment of the present application;

FIG4 is a flowchart of thread scheduling on a CPU core in a parallel system provided by an embodiment of the present application;

FIG5 is a diagram of a parallel encryption architecture using a branch- and thread-based parallel method provided in an embodiment of the present application;

FIG6 is a schematic diagram of an algorithm for writing multimedia files using BingxingFS provided in an embodiment of the present application;

FIG7 is a schematic diagram of a parallel multimedia encryption algorithm provided in an embodiment of the present application;

FIG8 is a schematic diagram of parallel encryption processing on BingxingFS provided in an embodiment of the present application;

FIG9 is a schematic diagram of a parallel multimedia decryption algorithm provided in an embodiment of the present application;

FIG10 is a schematic diagram of the structure of a multimedia encryption device provided in an embodiment of the present application;

FIG. 11 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

DETAILED DESCRIPTION

The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

It is obvious to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit or scope of the present application. Therefore, the present application is intended to cover modifications and changes of the present application that fall within the scope of the corresponding claims (technical solutions for protection) and their equivalents. It should be noted that the implementation methods provided in the embodiments of the present application can be combined with each other without contradiction.

According to the background technology, the existing technical solutions have a long read and write response time and still need further improvement and optimization. In order to solve the above technical problems, the embodiments of the present application provide a multimedia encryption method, device, electronic device and storage medium. When a system call initiated by a user application is received, it is determined whether the system call involves a multimedia file in a mounted directory in the encrypted file system. When the system call involves a multimedia file in a mounted directory in the encrypted file system, it is determined whether the system call is in the current kernel queue. When the system call is in the current kernel queue and a write operation is performed on the multimedia file, the multimedia file is encrypted in parallel to generate a target multimedia file, and a response message is returned to the user application.

Therefore, the parallel encrypted file system effectively provides a high-performance encryption solution to handle large data files and reduce the impact caused by heavy workloads, so it can be used to meet real-time requirements. It can shorten the system response time and improve the performance of the existing encrypted file system.

The following will describe embodiments of a multimedia encryption method, device, electronic device, and storage medium in conjunction with the accompanying drawings.

The following first introduces the multimedia encryption method provided by the embodiment of the present application. As shown in FIG1 , the multimedia encryption method provided by the embodiment of the present application includes the following steps:

S101: when a system call initiated by a user application is received, obtaining a first judgment result according to the system call, the first judgment result being used to indicate whether the system call involves a multimedia file in a mount directory in the encrypted file system;

S102: When the first judgment result indicates that the system call involves a multimedia file in a mounted directory in the encrypted file system, compare the system call with a kernel queue to obtain a second judgment result, wherein the second judgment result is used to indicate whether the system call is in a current kernel queue;

S103: When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypt the multimedia file in parallel to generate a target multimedia file;

S104: When the target multimedia file is generated, response information is returned to the user application.

The embodiment of the present application provides a multimedia encryption method, device, electronic device and storage medium. When a system call initiated by a user application is received, it is determined whether the system call involves a multimedia file in a mounted directory in the encrypted file system. When the system call involves a multimedia file in a mounted directory in the encrypted file system, it is determined whether the system call is in the current kernel queue. When the system call is in the current kernel queue and a write operation is performed on the multimedia file, the multimedia file is encrypted in parallel to generate a target multimedia file, and a response message is returned to the user application.

Therefore, the parallel encrypted file system effectively provides a high-performance encryption solution to handle large data files and reduce the impact caused by heavy workloads, so it can be used to meet real-time requirements. It can shorten system response time and improve the performance of existing encrypted file systems.

It should be noted that the system provided by this proposal allows users to use it in a similar way to traditional file systems and is able to work with single-user and multi-user systems. The general FUSE framework is built by the FUSE kernel driver and the user space file system daemon. Through the FUSE library, the FUSE kernel driver provides developers with a set of standard system calls that support the development of custom FUSE file systems to add new features or improve existing functions. BingxingFS, a parallel user-level encrypted file system for multimedia data based on FUSE technology, is designed as a backend file system layer located in the user space to provide transparent encryption services for dynamic multimedia files.

In S101, as shown in FIG2, when a user or application initiates a system call for a multimedia file, the system call is dynamically intercepted by the VFS layer of the Linux kernel. VFS is a kernel software layer that provides an interface for all file systems and storage devices. It handles all system calls, abstracts the functions of the file system, queries the mounted file system table, and resolves the file path.

When VFS realizes that the system call involves multimedia files stored in a directory mounted in BingxingFS, it forwards the system call to dev/FUSE. At the user level, the FUSE library handles the main functions responsible for mounting BingxingFS, initializing data structures, and managing communication between the FUSE kernel driver and the BingxingFS daemon.

In S102, when the FUSE library realizes that the system call is currently in the kernel queue, it calls the request from dev/FUSE, processes it, and involves the callback function required to execute BingxingFS.

In one example, when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, after comparing the system call with the kernel queue to obtain a second judgment result, the method further includes:

When the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file.

In S103, the BingxingFS file system encrypts and decrypts the multimedia file before executing the write or read operation. After executing the encryption and decryption function, the FUSE library writes the result back to dev/FUSE, and then writes it back to the FUSE kernel driver.

In one example, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file includes:

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel by pairing the encryption keys to generate the target multimedia file;

Return the target multimedia file to the callback layer.

In S104 , the FUSE driver returns a response to the user application that sent the request.

In one example, in the case of receiving a system call initiated by a user application, before obtaining a first judgment result according to the system call, the method further includes:

generating an encryption key and a decryption key upon receiving a first storage instruction, wherein the decryption key and the encryption key are symmetric keys to each other, and the first storage instruction is used to store the multimedia file in a mount directory in the encrypted file system for the first time;

The multimedia file is encrypted in parallel according to the random encryption key, and an encrypted version of the multimedia file is generated in a mount directory in the encrypted file system.

In the above embodiment, the present scheme provides a mandatory mechanism for encrypting and decrypting multimedia files each time a user sends a request and before performing a write or read operation. When a multimedia file is stored in a directory mounted under BingxingFS for the first time, an encryption key and a decryption key are randomly generated, the decryption key and the encryption key are mutually symmetric keys, and the multimedia file blocks are encrypted so that an encrypted file version is generated in this secure source directory without user intervention. The designed file system can support a wide range of multimedia file formats and is compatible with various multimedia applications, including image, audio and video file formats. We use magic signatures stored on multimedia file header metadata to identify file types. In addition, by limiting the decryption process to the fine-grained level of a single multimedia file, the file system is designed to avoid unnecessary decryption and re-encryption of unused files each time the user mounts the file system. When a user mounts BingxingFS on a root directory (e.g., /Multidir), the hierarchical structure tree of the root directory will become a mount point, which will automatically display the user-selected files in an unencrypted format. This provides users with the flexibility to store secure multimedia files without being limited to a single directory location. At the same time, all stored files are transparently encrypted on the corresponding source directory, which is provided with the suffix extension /Multidir.sec to distinguish it.

BingxingFS is also designed to handle the dynamic key management process and enforce user authentication during mounting. The system administrator is responsible for mounting the BingxingFS file system and configuring the authentication policy to allow non-privileged users to mount the file system and enter a secure mount session. Each user has a login authentication key for mounting the file system, which is generated from the hash of the Linux login passphrase using SHAKE-128. In addition, each user has a public and private key pair (Pk, Prk) for encrypting/decrypting symmetric file encryption keys. When encrypting file data using the symmetric key K, K is encrypted using the user's Pk and appended to the header of the multimedia file. As shown in Figure 3, Figure 3 summarizes the interactions between the proposed multimedia file system components when performing the encryption/decryption process for stored/opened multimedia files.

In one example, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file includes:

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel by pairing the encryption keys to generate the target multimedia file;

Return the target multimedia file to the callback layer.

In the above embodiment, as shown in Figure 3, Figure 3 is the workflow of the BingxingFS component for multimedia file encryption/decryption, which is the read and write permissions of the file. When the file is written, the BingxingFS daemon is called to operate on the plaintext multimedia file, and the encryption process is completed by pairing the encryption key. Finally, the generated encrypted multimedia block is returned to the callback layer, and the kernel FUSE module is directly operated through the libfuse and glibc underlying applications to complete the encryption process.

In one example, when the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file, including:

When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, extracting a header of the encrypted multimedia file and calling a decryption key, the encryption key and the decryption key are symmetric keys to each other;

When the user identity verification is successful, the encrypted multimedia file is decrypted in parallel according to the decryption key to generate and return the target multimedia file.

In the above embodiment, as shown in Figure 3, when the user executes file reading, the BingxingFS daemon is responsible for verifying the identity of the accessing user by extracting the header of the encrypted multimedia file and calling the decryption key. When the verification passes, the decryption operation is completed and the original multimedia file is returned; when the identity verification fails, the access process is directly denied to achieve secure access permission control of the file.

In one example, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file includes:

When the second judgment result indicates that the system call is in the current kernel queue and the multimedia file is written, the CPU utilization of each thread is obtained according to the amount of time each thread is executed on the kernel;

According to the CPU utilization of each thread and the load of multiple cores, the processing tasks of encrypting the multiple multimedia files are allocated in parallel to generate multiple target multimedia files.

In the above embodiments, encryption consists of a series of sequential processes of file blocks that run independently in both sequential and parallel processing modes; the encryption of each block relies on the immediate output of the previous encrypted block. Therefore, reading and writing large storage files using encryption services is a major bottleneck. The difficulty of this challenge increases if applied to user space applications. Encrypting file systems generally optimize performance because they combine encryption and integrity protection techniques, and all related computations are performed in a highly seamless and compatible manner without many data copies between the kernel and user space. However, file system schemes are designed to primarily process files as addressable sequences of bytes and blocks, preventing them from taking advantage of recent advances in multi-core processors.

Parallel encrypted file systems can significantly address the processing overhead caused by encryption operations and shorten system response time. Here, encryption and decryption of individual file blocks are calculated independently and processed concurrently in a parity form using multiple processes and threads. While encrypted file systems require less memory in sequential construction, parallel encrypted file systems effectively provide a high-performance encryption solution to handle large data files and reduce the impact of bottlenecks (caused by heavy workloads), so they can be used to meet real-time requirements. The proposal improves the performance of existing encrypted file systems by concurrently processing a set of common multimedia file blocks and developing BingxingFS to support encryption workloads.

The main goal of BingxingFS is to achieve higher encryption performance and faster response time for each multimedia file read and write request. However, the performance level is driven by the reserved process, resource workload, and technical environment. In addition, changes in synchronization and differences in parallel thread computations can affect the performance of CPU cores. In a multi-core CPU, one core may be overloaded by waiting for I/O operations or entering a low-power idle state. When executing tasks of varying sizes, one core may complete its own process before other cores, thereby reducing efficiency and increasing the response time of the system. To avoid this, in the proposed scheme, we measure the CPU utilization of threads by measuring the amount of time each thread executes on a core. The thread scheduling in BingxingFS is based on Linux's Completely Fair Scheduler (CFS). It periodically and dynamically measures the CPU utilization of running threads so that fewer encryption processing tasks can be assigned to cores with heavier loads, while larger tasks can be assigned to cores with less data processing or in an idle state. A thread pool is designed here in the BingxingFS file system daemon to execute parallel encryption tasks running on CPU cores. Figure 4 shows the thread scheduling on CPU cores, where Tz represents the thread size in bytes and U represents the core utilization.

FIG4 is a flowchart of thread scheduling on the CPU core in a parallel system. As shown in FIG4, when the BingxingFS daemon monitors the file encryption and decryption process, its main function is to realize centralized scheduling management of the CPU core. When the daemon receives the user's operation task message for the multimedia folder, it first checks the resources in the thread pool, establishes the task dispatching of identity authentication, key pairing and OpenSSL link respectively, and calculates the CPU core resources at the same time. By sorting the priority and load index of the scheduling tasks, it reasonably arranges the tasks to be executed with reference to the performance of the virtual core.

In one example, the process of allocating the encryption processing tasks of the plurality of multimedia files in parallel according to the CPU utilization of each thread and the load of the plurality of cores to generate the plurality of target multimedia files includes:

According to the CPU utilization of each thread and the load of multiple cores, multiple sub-processes are created to distribute the processing tasks of encrypting multiple multimedia files in parallel, and multiple target multimedia files are generated. Each sub-process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other.

In another example, the encrypting processing tasks of the plurality of multimedia files are distributed in parallel according to the CPU utilization of each thread and the load of the plurality of cores to generate the plurality of target multimedia files, including:

According to the CPU utilization of each thread and the load of multiple cores, multiple threads belonging to a single parent process are created through a thread method, and the processing tasks of encrypting multiple multimedia files are allocated in parallel to generate multiple target multimedia files. Each child process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other. The multiple threads belonging to a single parent process share the same address space and parameters through global variables.

In the above two examples, as shown in Figure 5, parallel encryption based on multi-core processors can be implemented in two different ways. The first method can be implemented by creating many child processes, each of which has a different process ID and a separate memory location in a virtual memory with a different address space and executes independently of each other. In the second method, a threading method can be used to create many threads belonging to a single parent process and share the same address space and parameters through global variables. Figure 5 shows the architecture of the parallel encryption design using the branch-based and thread-based parallel methods.

The structure of the parallel system is designed using a threading approach. Here, the FUSE driver is used to hook system calls related to BingxingFS operations. When an I/O request accesses a file in the mount point directory, the request is forwarded to perform a customized encryption process. Otherwise, the process passes the request to the underlying kernel file system. When a write() request is received, the plaintext file is divided into several blocks, each with a maximum size of 4KB. These blocks are then divided into several sub-blocks, each with a size of 1KB. We use the pre-branching technique by creating a task manager and push tasks to the task manager queue using an inter-process communication (IPC) method. This can provide an effective mechanism for communication between multiple processes and reduce the bottleneck effect caused by process and thread allocation, thereby improving performance. In addition, we build a thread pool that includes multiple threads belonging to one parent process and sharing the same address space and parameters through global variables. Then, the created thread pops the task from the task manager and distributes the task according to the CFS CPU scheduler. Here, in the task manager, the push operation is given a higher priority than the pop operation. In addition, a lock is designed to block the thread when the task manager is emptied.

After creating the threads, each thread encrypts independently and all threads encrypt in parallel. In addition, all encryption parameters required by the encryption function, such as encryption keys, parameters, are passed. Subsequently, considering the task order, the output of each thread is collected in reverse order because the tasks will not end in the same order. Algorithm 1 shown in Figure 6 describes the steps involved in BingxingFS when a write() request for a multimedia file is received.

Allocate a number of shared memory slots, each of which is the same size as the sub-block, and the number of slots is the number of pre-forked processes, which should be a multiple of 4, with at least 4 slots, since most current multi-core processors are structured with 4 processes and threads. At the same time, use a lock around each slot to ensure that all slots belong to the same task and avoid deadlocks caused by not being able to achieve a free slot for each slot due to slots belonging to different tasks. After filling the slots with data segments, we queue the tasks for each passed key and IV (initial vector), which can be in shared memory. In addition, for each shared slot index, we associate an IPC event with all service sub-processes. Then, wait for the slot notification: use event.wait() on one end and event.notify() on the other end at the same time. When all segments are completed and notified, the waiting caller collects the results from the same slot as the encoding function. It takes the sub-block from shared memory, encrypts it, and puts it back in the same shared memory. The slots of global variables are used in the same way when using threads for the second method instead of processes for the first method.

Parallel encryption and decryption:

Multimedia files written in the mounted directory are intercepted by BingxingFS, and then the files are encrypted using a hybrid encryption scheme with symmetric and asymmetric ciphers. In symmetric encryption, all file blocks are encrypted using the Blowfish encryption algorithm with a key length of 128 bits and a block size of 4kb. A 64-bit file salt is randomly generated for each new multimedia file encryption, and our scheme adopts the counter mode (CTR). CTR is a fully parallelizable operation mode that can be effectively used for multimedia encryption and provides random access to any block cipher without error propagation or ciphertext expansion. Each data block has a unique IV generated by XORing the file salt, and a counter block corresponds to each data block, which prevents similar plaintext blocks from being encrypted into the same ciphertext block. Therefore, the uniqueness requirement of the counter block needs to be set in all file blocks to guarantee better protection. After the file body is symmetrically encrypted, the encryption key (with the file salt) is asymmetrically encrypted using the RSA-2048 algorithm and encrypted with the user's public key, which is then stored with the header of the multimedia file. Algorithm 2 shown in Figure 7 describes the file encryption steps involved in the BingxingFS daemon. First, the system generates all unique encryption block counters (ctr) that are the same number (n) as the number of data blocks (B) in the multimedia file (F). Then, all unique IVs associated with all data blocks are created by XORing the global file salt (FSalt) with each corresponding block encryption counter (ctri).

Figure 8 shows the parallel encryption processing of data blocks. As input, the encryption function splits a single 4kb data block (Bi) into m sub-blocks (SB1, SB2, …, SBm), corresponding unique IVi and encryption key K. The same IV is used, all sub-blocks belong to the same parent block, and all file blocks share the same K. Once the encryption parameters are received, the parallel encryption function is ready for execution. Each data sub-block is associated with a thread, which encrypts the data segment independently, independent of other sub-blocks, and all threads execute in parallel. Once the parallel execution of all sub-blocks is completed, encrypted sub-blocks (CSB1, CSB2, …, CSBm) are generated, which are combined into an encrypted block (CB). This operation is repeated for all file blocks (n) and all generated encrypted blocks (CB1, CB2, …, CBn) are collected and written to disk in the form of an encrypted multimedia file (CF).

Decryption works similarly, but in reverse. First, K and FSalt are extracted from the image header, they are decrypted using the user's private key, and all used IVs are reconstructed. As input, the decryption function takes the encrypted blocks (CB1, CB2, ..., CBn), the corresponding IVi, and the same encrypted k. Subsequently, each encrypted block is split into sub-blocks and processed in parallel. This operation is repeated until all encrypted blocks are decrypted, resulting in the original plaintext of the multimedia file F. Algorithm 3 shown in Figure 9 describes the parallel decryption steps involved in BingxingFS when a read() request is received for a stored multimedia file.

Based on a multimedia encryption device provided in the above embodiment, accordingly, as shown in FIG10 , an embodiment of the present application provides a multimedia encryption device 1000, which may include:

A first judgment module 1001 is used for, when receiving a system call initiated by a user application, obtaining a first judgment result according to the system call, wherein the first judgment result is used to indicate whether the system call involves a multimedia file in a mount directory in the encrypted file system;

A second judgment module 1002 is used to compare the system call with the kernel queue to obtain a second judgment result when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, wherein the second judgment result is used to indicate whether the system call is in a current kernel queue;

The encryption module 1003 is used to encrypt the multimedia file in parallel to generate a target multimedia file when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file;

The return module 1004 is used to return response information to the user application when the target multimedia file is generated.

Based on the multimedia encryption method provided in the above embodiment, the embodiment of the present application further provides an electronic device 1100, as shown in FIG11 :

The invention comprises a processor 1101, a memory 1102, and a computer program stored in the memory 1102 and executable on the processor 1101. When the computer program is executed by the processor 1101, each process of the above-mentioned multimedia encryption method embodiment is implemented, and the same technical effect can be achieved.

Specifically, the processor 1101 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

The memory 1102 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 1102 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 1102 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 1102 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 1102 is a non-volatile solid-state memory.

In certain embodiments, the memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical/tangible memory storage device. Thus, typically, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of the present application.

The processor 1101 implements any one of the multimedia encryption methods in the above embodiments by reading and executing computer program instructions stored in the memory 1102 .

In one example, the electronic device may further include a communication interface 1103 and a bus 1110. As an example, as shown in FIG11 , the processor 1101, the memory 1102, and the communication interface 1103 are connected via the bus 1110 and communicate with each other.

The communication interface 1103 is mainly used to implement communication between various modules, devices, units and/or equipment in the embodiments of the present application.

Bus 1110 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-end bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 1110 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above-mentioned key negotiation method and identity authentication method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. Among them, the computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

The above reference is according to the flowchart and/or block diagram of the method, device and computer program product of the embodiment of the present application to describe various aspects of the present application.It should be understood that each square block in the flowchart and/or block diagram and the combination of each square block in the flowchart and/or block diagram can be realized by computer program instructions.These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the realization of the function/action specified in one or more square blocks of the flowchart and/or block diagram.Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit.It can also be understood that each square block in the block diagram and/or flowchart and the combination of square blocks in the block diagram and/or flowchart can also be realized by the dedicated hardware that performs the specified function or action, or can be realized by the combination of dedicated hardware and computer instructions.

The above are only specific implementation methods of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims (12)

1. A multimedia encryption method, characterized in that the method comprises: In the case of receiving a system call initiated by a user application, obtaining a first judgment result according to the system call, wherein the first judgment result is used to indicate whether the system call involves a multimedia file in a mount directory in the encrypted file system; When the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, comparing the system call with a kernel queue to obtain a second judgment result, wherein the second judgment result is used to indicate whether the system call is in a current kernel queue; When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file; When the target multimedia file is generated, response information is returned to the user application. 2. The method according to claim 1, characterized in that when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, after comparing the system call with a kernel queue to obtain a second judgment result, the method further comprises: When the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file. 3. The method according to claim 2, characterized in that, in the case of receiving a system call initiated by a user application, before obtaining the first judgment result according to the system call, it also includes: generating an encryption key and a decryption key upon receiving a first storage instruction, wherein the decryption key and the encryption key are symmetric keys to each other, and the first storage instruction is used to store the multimedia file in a mount directory in the encrypted file system for the first time; The multimedia files are encrypted in parallel according to a random encryption key, and an encrypted version of the multimedia files is generated in a mount directory in the encrypted file system. 4. The method according to claim 3, characterized in that, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file comprises: When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel by pairing the encryption keys to generate the target multimedia file; Return the target multimedia file to the callback layer. 5. The method according to claim 4, characterized in that, when the second judgment result indicates that the system call is in the current kernel queue and a read operation is performed on the multimedia file, the multimedia file is decrypted in parallel to generate a target multimedia file, comprising: When the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, extracting a header of the encrypted multimedia file and calling a decryption key, the encryption key and the decryption key are symmetric keys to each other; When the user identity verification is successful, the encrypted multimedia file is decrypted in parallel according to the decryption key to generate and return the target multimedia file. 6. The method according to any one of claims 1 to 5, characterized in that, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypting the multimedia file in parallel to generate a target multimedia file comprises: When the second judgment result indicates that the system call is in the current kernel queue and the multimedia file is written, the CPU utilization of each thread is obtained according to the amount of time each thread is executed on the kernel; According to the CPU utilization of each thread and the load of multiple cores, the processing tasks of encrypting the multiple multimedia files are allocated in parallel to generate multiple target multimedia files. 7. The method according to claim 6, characterized in that the parallel allocation of the processing tasks for encrypting the plurality of multimedia files to generate the plurality of target multimedia files according to the CPU utilization of the respective threads and the load of the plurality of cores comprises: According to the CPU utilization of each thread and the load of multiple cores, multiple sub-processes are created to distribute the processing tasks of encrypting multiple multimedia files in parallel, and multiple target multimedia files are generated. Each sub-process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other. 8. The method according to claim 6, characterized in that the parallel allocation of the processing tasks for encrypting the plurality of multimedia files to generate the plurality of target multimedia files according to the CPU utilization of the respective threads and the load of the plurality of cores comprises: According to the CPU utilization of each thread and the load of multiple cores, multiple threads belonging to a single parent process are created through a thread method, and the processing tasks of encrypting multiple multimedia files are allocated in parallel to generate multiple target multimedia files. Each child process has a different process identity and a separate memory location in a virtual memory with a different address space and is executed independently of each other. The multiple threads belonging to a single parent process share the same address space and parameters through global variables. 9. A multimedia encryption device, characterized in that the device comprises: A first judgment module, configured to, upon receiving a system call initiated by a user application, obtain a first judgment result according to the system call, wherein the first judgment result is used to indicate whether the system call involves a multimedia file in a mount directory in an encrypted file system; A second judgment module is used to compare the system call with the kernel queue to obtain a second judgment result when the first judgment result indicates that the system call involves a multimedia file in a mount directory in the encrypted file system, and the second judgment result is used to indicate whether the system call is in a current kernel queue; an encryption module, configured to, when the second judgment result indicates that the system call is in the current kernel queue and a write operation is performed on the multimedia file, encrypt the multimedia file in parallel to generate a target multimedia file; The returning module is used to return the response information to the user application program when the target multimedia file is generated. 10. An electronic device, characterized in that the device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the multimedia encryption method according to any one of claims 1 to 8 is implemented. 11. A computer-readable storage medium, characterized in that computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, the multimedia encryption method according to any one of claims 1 to 8 is implemented. 12. A computer program product, characterized in that when instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the multimedia encryption method according to any one of claims 1 to 8.