Virtual disk file encryption method, device and equipment

Abstract

The present invention provides a virtual disk file encryption method, apparatus, and device for addressing the technical problem of hardware encryption of virtual disk files in cloud platforms. This method implements hardware encryption and decryption of encrypted virtual disk file data by invoking an extended LUKS sub-driver via the virtual disk file driver in QEMU. This LUKS sub-driver then invokes the API interface of a hardware encryption card driver. The hardware encryption solution provided by this invention seamlessly integrates with the host machine's virtualization system, offers excellent compatibility, and enables physical isolation of data, thereby enhancing data security.

Description

Technical Field

[0001] The present invention relates to the field of communication and storage technology, and in particular to a virtual disk file encryption method, device and equipment. Background Art

[0002] In the virtualization field, data security in virtual disk files has always been a major concern. Software-implemented encryption, such as AES, 3DES, CAST5, and Twofish, is commonly used in production environments. However, these encryption algorithms and their implementations are public and not completely secure. The current mainstream implementation involves setting a key when creating a virtual encrypted disk and storing it on the cloud computing platform. Subsequent read and write operations on the virtual disk are encrypted and decrypted using this key. Even without the key, if a criminal gains access to the virtual disk file, they can still brute-force the key, resulting in a data breach. Alternatively, some vendors have developed hardware devices for data encryption. While this approach provides physical isolation and addresses potential vulnerabilities in software-implemented encryption algorithms, it lacks integration with cloud computing infrastructure (such as the fast emulator QEMU) and does not fully support basic operations required in cloud computing scenarios, such as snapshotting and migrating virtual machine disks.

[0003] Currently, one solution is to add the Linux Unified Key Setup (LUKS) driver framework to the block device driver layer of the Quick Emulator (QEMU). This framework specifically supports encryption of virtual disks in the qcow2 (QEMU Copy On Write 2) format. Currently, the LUKS disk encryption specification framework supports six encryption algorithms: AES, DES-RFD, 3DES, CAST5, Serpent, and Twofish. The LUKS implementation of qcow2 disk encryption is divided into three steps:

[0004] First, when creating a virtual disk, the key and key configuration (encryption algorithm and algorithm parameters) are passed to the Luks driver layer. Luks metadata is generated based on the passed parameters and stored in the header of the created qcow2 virtual disk. Finally, the virtual disk file is written to the physical storage, completing the virtual disk creation. Virtualization technology virtualizes the virtual disk file on the physical storage into a virtual disk for use by the virtual machine. Therefore, each virtual disk corresponds to a virtual disk file.

[0005] Second, read data from the virtual disk. The read operation of the virtual disk (such as reading the disk inside the virtual machine, reading snapshot data, etc.) must pass in the encrypted disk key, and compare the passed-in key with the key stored in the metadata. If the key is correct, the disk is opened, and the key can be used to decrypt the encrypted data read from the disk file. If the key is incorrect, the disk is opened and an error is reported, and the disk operation is exited.

[0006] Third, write data to the virtual disk. Writing data is the reverse process of reading data. The key is also verified first, and then the plaintext data to be written is encrypted and written to the virtual disk file corresponding to the virtual disk.

[0007] Although the above scheme can encrypt and decrypt virtual disk data, the key is transmitted in plain text during the operation process, which poses a risk of key leakage. Moreover, the principles and implementation of these algorithms are public. If the virtual disk file is copied to another location via the network, with the help of a computer with strong computing power, it is theoretically possible to brute force the key, thereby leading to data leakage.

[0008] In addition, some hardware encryption card manufacturers have implemented solutions for unified key management on cloud platforms. Specifically, a centralized encryption key management service (KMS) is deployed in the cloud platform environment to centrally manage the keys used for data encryption and decryption. This system, combined with encryption cards and encryption and decryption management applications, encrypts and decrypts the data that requires protection. This solution is called a hardware encryption and decryption system. This solution is generally applicable to the following two scenarios: The first involves the hardware encryption and decryption system working with the business system in the virtual machine. When the business layer reads and writes data from the underlying cloud platform storage, the data stream passes through the hardware encryption and decryption system to complete the data encryption and decryption, thereby achieving data protection. The second scenario involves the hardware encryption and decryption system working with the cloud platform's backend storage server system. Data is sent from the virtual machine to the host virtualization layer and ultimately transmitted to the storage server. Before the data is actually read or written to the physical storage, the data stream passes through the hardware encryption and decryption system to complete the data encryption and decryption, ultimately achieving data protection. This solution processes encryption and decryption operations at the upper or lower layer of the qcow2 format virtual disk file. Although it can also achieve data protection, the system deployment is complex, and the cooperating system needs to call the API of the encryption and decryption system for secondary development and adaptation. The business systems deployed in different cloud platforms and the types of back-end storage server systems used are also different, so repeated development and adaptation work is required, and the versatility is relatively poor. Summary of the Invention

[0009] In view of this, the present invention provides a virtual disk file encryption method, device and equipment for solving the technical problem of hardware encryption of virtual disk files in a cloud platform.

[0010] According to one aspect of an embodiment of the present invention, the present invention provides a virtual disk file encryption device, which is located in a fast emulator QEMU and includes:

[0011] The virtual disk file driver module is used to receive read or write requests for encrypted virtual disk files sent by the virtual machine, read the requested data from the encrypted virtual disk file, or write the requested data to the encrypted virtual disk file; during the process of reading or writing data, the LUKS driver module is called to decrypt or encrypt the requested data, and the processing result is fed back to the requester;

[0012] The LUKS driver module is used to determine whether software encryption or hardware encryption is used based on the encryption parameters of the encrypted virtual disk file, and to actually perform the corresponding decryption or encryption process based on the judgment result;

[0013] The encryption card driver interface module is called by the LUKS driver module and is used to perform hardware decryption or encryption on the requested read or write data through the encryption card driver interface.

[0014] Furthermore, the LUKS driver module includes one or more LUKS sub-driver modules, and different LUKS sub-driver modules correspond to different hardware encryption algorithms and encryption modes; the LUKS driver module calls the corresponding LUKS sub-driver module according to the encryption algorithm parameters and encryption mode in the encryption parameters of the encrypted virtual disk file, and then the LUKS sub-driver module calls the encryption card driver interface module to perform hardware decryption or encryption.

[0015] Furthermore, the encryption card driver interface module performs hardware decryption or encryption of the requested read or write data by calling the application programming interface API and API static library of the hardware encryption card driver, and the hardware encryption card driver is connected to the hardware encryption card installed on the host machine where the QEMU is located.

[0016] Furthermore, the virtual disk file driver module is further configured to receive a virtual disk file creation request and determine whether encryption parameters carried in the creation request are supported; the encryption parameters include: encryption algorithm name, encryption algorithm length, encryption mode, key index, and whether hardware encryption is used;

[0017] The LUKS driver module is further configured to determine whether hardware encryption is used based on encryption parameters carried in the creation request; when hardware encryption is used, create an encryption metadata object for the virtual disk file based on the encryption parameters and initialize the encryption card driver interface module;

[0018] The LUKS driver module is further used to create a virtual disk file and store the encrypted metadata object content in the header of the created virtual disk file.

[0019] Furthermore, the virtual disk file driver module is also used to receive a virtual disk file opening request, determine whether the key index carried in the opening request is the same as the key index stored in the virtual disk file header, and if they are the same, the virtual disk file is opened successfully.

[0020] According to another aspect of an embodiment of the present invention, the present invention further provides a virtual disk file encryption method, which is applied to a fast emulator QEMU in a host machine where a virtual machine is located. The method includes:

[0021] Receive read or write requests from virtual machines for encrypted virtual disk files, read the requested data from the encrypted virtual disk files, or write the requested data to the encrypted virtual disk files; during the data reading or writing process, call the LUKS driver to decrypt or encrypt the requested data, and feedback the processing results to the requester;

[0022] When performing the decryption or encryption process, the LUKS driver determines whether software encryption or hardware encryption is used based on the encryption parameters of the encrypted virtual disk file, and actually executes the corresponding decryption or encryption process according to the determination result;

[0023] The LUKS driver performs hardware decryption or encryption on the requested read or write data by calling the encryption card driver interface.

[0024] Furthermore, the LUKS driver performs hardware decryption or encryption on the requested read or write data by calling the encryption card driver interface, including:

[0025] The LUKS driver includes one or more LUKS sub-drivers, and different LUKS sub-drivers correspond to different hardware encryption algorithms and encryption modes;

[0026] The LUKS driver calls the corresponding LUKS sub-driver according to the encryption algorithm parameters and encryption mode in the encryption parameters of the encrypted virtual disk file, and then the LUKS sub-driver calls the encryption card driver interface module to perform hardware decryption or encryption on the requested read or write data;

[0027] The encryption card driver interface module performs hardware decryption or encryption of the requested read or write data by calling the application programming interface API and API static library of the hardware encryption card driver.

[0028] Furthermore, the method further comprises:

[0029] The virtual disk file driver receives the virtual disk file creation request and determines whether the encryption parameters carried in the creation request are supported; the encryption parameters include: encryption algorithm name, encryption algorithm length, encryption mode, key index, and whether hardware encryption is used;

[0030] The LUKS driver determines whether hardware encryption is used based on the encryption parameters carried in the creation request. If hardware encryption is used, it creates an encryption metadata object for the virtual disk file based on the encryption parameters and initializes the encryption card driver interface module.

[0031] The LUKS driver creates a virtual disk file and stores the encrypted metadata object content in the header of the created virtual disk file.

[0032] Furthermore, the method further comprises:

[0033] The virtual disk file driver receives the virtual disk file opening request and determines whether the key index carried in the opening request is the same as the key index stored in the virtual disk file header. If they are the same, the virtual disk file is opened successfully.

[0034] The present invention implements encryption and decryption of data of encrypted virtual disk files by calling an extended LUKS sub-driver through the virtual disk file driver in QEMU, and the LUKS sub-driver calls the API interface of the hardware encryption card driver. The virtual disk file driver in QEMU calls the LUKS driver module to direct the read and write data to the hardware encryption card, and the hardware encryption card performs hardware encryption and decryption on the data of the virtual disk, and then writes the encrypted data to the virtual disk file or feeds the decrypted data back to the upper-layer application through the virtual disk file driver. The hardware encryption card provides a kernel encryption card driver, and the LUKS driver module implements hardware encryption and decryption of virtual disk data by calling the API programming interface of the kernel encryption card driver. The hardware encryption solution provided by the present invention can achieve seamless docking with the virtualization system of the host machine, has good compatibility, can physically isolate data, and improves data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments of the present invention or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings of the embodiments of the present invention.

[0036] Figure 1 A schematic diagram of the software and hardware hierarchical structure of a device using the virtual disk file encryption method provided by the present invention;

[0037] Figure 2 A schematic diagram of a virtual disk file encryption framework structure in a cloud platform provided by an embodiment of the present invention;

[0038] Figure 3A schematic flow chart of the steps for creating an encrypted virtual disk file in a virtual disk file encryption method provided by an embodiment of the present invention;

[0039] Figure 4 A schematic flow chart of the steps of reading and writing encrypted virtual disk file data in a virtual disk file encryption method provided by one embodiment of the present invention;

[0040] Figure 5 A schematic diagram of the structure of an electronic device for implementing a virtual disk file encryption method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0041] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of the present invention. The singular forms "a," "the," and "the" used in the embodiments of the present invention are also intended to include plural forms, unless the context clearly indicates otherwise. The term "and / or" used in the present invention refers to any or all possible combinations of one or more associated listed items.

[0042] It should be understood that although the terms "first," "second," "third," etc. may be used to describe various information in embodiments of the present invention, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, without departing from the scope of embodiments of the present invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the term "if" may also be interpreted as "when," "when," or "in response to determining."

[0043] The present invention provides a virtual disk file encryption method and device. The basic concept of the technical solution of the present invention is as follows: in the fast emulator QEMU, the virtual disk file driver module, the LUKS driver module, and the hardware encryption card cooperate to implement hardware encryption and decryption of the virtual disk. The virtual disk file driver module (e.g., the qcow2 module) in QEMU calls the LUKS driver module to direct read and write data to the hardware encryption card. The hardware encryption card performs hardware encryption and decryption on the virtual disk data. The encrypted write data is then stored in the virtual disk or the decrypted read data is fed back to the upper-layer application through the virtual disk file driver module. The hardware encryption card provides a kernel encryption card driver, and the LUKS driver module implements hardware encryption and decryption of the virtual disk data by calling the programming interface of the kernel encryption card driver. The hardware encryption solution provided by the present invention can achieve seamless integration with the host machine's virtualization system, has good compatibility, and can physically isolate data, thereby improving data security.

[0044] Figure 1This diagram illustrates the hardware and software hierarchical structure of a device that utilizes the virtual disk file encryption method provided by the present invention. A hardware encryption card is installed in the hardware layer for hardware encryption and decryption of disk files. The hardware encryption card manufacturer provides the kernel encryption card driver for the hardware encryption card. The encryption card driver interface module located in the application layer interfaces with the kernel encryption card driver. The thick solid and thick dashed lines represent the processing path for reading hardware-encrypted data from a virtual disk file, while the thin solid and thin dashed lines represent the processing path for writing hardware-encrypted data to a virtual disk file. When a virtual machine reads data from physical storage, the data is first returned from the physical storage to the host machine's kernel file system layer and then to the virtual disk file driver module (e.g., a virtual disk file driver module in qcow2 format). However, at this point, the data is encrypted. The encrypted file data is then transferred along the thick dashed path to the hardware encryption card for decryption. The decrypted data is then returned to the virtual disk file driver module along the same path. The virtual disk file driver module then returns the decrypted data to the virtual machine. When the virtual machine writes data to the physical storage, the written data first reaches the virtual disk file driver module in QEMU. The virtual disk file driver module sends the written data along the path of the thin dotted line to the hardware encryption card for encryption. The encrypted data is returned to the virtual disk file driver module along the original path, and then the virtual disk file driver module writes the encrypted data to the physical storage.

[0045] The hardware encryption card in this invention encrypts and decrypts virtual disk data. The encryption algorithm used within the hardware encryption card is not specific to any particular manufacturer; it can be integrated based on the needs of the application scenario. The hardware encryption card mentioned in the embodiments of this invention does not refer to encryption devices manufactured by a specific manufacturer; any hardware encryption card that can implement the hardware encryption functions required by the embodiments of this invention will suffice.

[0046] The hardware encryption card used in the embodiment of the present invention needs to be provided with a kernel driver to ensure that the encryption card can be loaded on the cloud platform host, and that the encryption card driver interface module can implement hardware encryption and decryption operations of data by calling the encryption card driver in the kernel through the API. The encryption card driver needs to provide the encryption card driver interface module with an application layer API interface implemented in a high-level programming language and a static library of the API to implement functions such as initialization of the encryption card, data encryption and decryption. Among them, the high-level programming language can be C, C++, Java, etc., and the application layer API is generally stored in the form of a header file. The static library of the API is a specific implementation of the application layer API, which is compiled to generate a static library and exists in binary form. The API of the hardware encryption card provides virtual disk creation, encryption, and decryption functions, and the specific logic is implemented by the encryption card manufacturer. The location where the application layer API provided by the encryption card actually performs encryption and decryption is in the encryption card for hardware encryption and decryption.

[0047] In order to improve the key security of the hardware encryption card, the hardware encryption card used in the present invention adopts a special key management method, which does not expose the key to the outside world and only provides a key index to the outside world. When the hardware encryption card is initialized, it will generate a number of keys within the specified specification range (for example, an encryption card supports 1,000 different keys) and number each key, that is, each key has a unique key index. The key actually used to encrypt the data cannot be obtained outside the hardware encryption card. The upper-level caller needs to provide the key index to the hardware encryption card. The hardware encryption card finds the corresponding key based on the key index and then encrypts and decrypts the passed data. The present invention does not specifically limit the management method of the hardware encryption card. For example, it can also be centrally managed by the cloud platform. As long as the encryption parameters and keys are passed in when calling the API interface, the correct encryption and decryption operations can be performed.

[0048] In addition, in order to improve the concurrent processing performance of the hardware encryption card, the hardware encryption card can use the PCI bus, which is easy to expand. Concurrent processing of multiple hardware encryption cards can improve encryption and decryption performance.

[0049] Figure 2 A schematic diagram of a virtual disk file encryption framework structure in a cloud platform provided by an embodiment of the present invention. The virtual disk file encryption device includes Figure 1 The virtual disk file driver module, LUKS driver module, and encryption card driver interface module are included. Cloud platform management software, also known as the cloud computing management platform (referred to as the cloud platform), is used to manage virtualized resources such as virtual machines, storage, and networks, and is installed on the host machine. After the cloud platform management software is installed, the kernel-layer encryption card kernel driver (such as ko) and the application-layer encryption card driver API static library must also be installed on the host machine. Then, the encryption card is installed on the host machine where the virtual machine (guest) disk needs to be encrypted. The host operating system will recognize the encryption card at startup and load the encryption card driver to ensure access to the encryption card hardware.

[0050] After installing the hardware encryption card and starting the host machine, the operation and maintenance personnel can use the encryption card key management software provided by the encryption manufacturer to initialize the encryption card and configure encryption parameters for the encryption card. In the present invention, the encryption process is transparent to both the upper-layer application and the lower-layer storage service end, and supports local storage and shared storage. If the virtual machine of the encrypted disk needs to be migrated, the same model of encryption card must be installed on the destination host machine for migration, and the initialization parameters of the encryption card must be consistent with those on the source host machine. In this way, the virtual machine can be encrypted and decrypted normally after migration, ensuring the correctness of the virtual disk data. At this point, the work of docking the hardware encryption card with the virtual disk file driver module is completed.

[0051] Figure 2In the example, both host 1 and host 2 have hardware encryption cards installed, along with the encryption card's kernel driver and API static library. Both hosts 1 and 2 are configured with local storage pools and shared storage pools, with both hosts 1 and 2 having access to the shared storage pool. When virtual machine guest2's encrypted virtual disk volume2 is stored in the shared storage pool, guest2 can read and write data on both host 1 and host 2. Therefore, guest2 can continue to access encrypted disk volume2 after migrating between hosts 1 and 2. The solid line with an arrow represents the process of virtual machine data reading and writing, while the dashed box and dashed line with an arrow indicate that guest2 can still access the encrypted disk in the shared storage after migrating from host 1 to host 2.

[0052] The core of the technical solution of the present invention is the implementation of a virtual disk file encryption device. This device performs basic cloud computing operations such as virtual disk / virtual disk file creation, reading and writing, snapshots, and migration. It provides transparent virtual disk encryption and decryption functions to the upper layer and calls the hardware encryption card API to encrypt and decrypt virtual disk data to the lower layer. The virtual disk file driver module in this device supports software implementation of encryption algorithms such as AES through LUKS technology, and supports snapshot and migration functions of software-encrypted disks. Therefore, by being compatible with hardware encryption implementation in the LUKS driver, hardware encryption snapshot and migration functions can be supported. However, the implementation of hardware encryption algorithms differs significantly from the implementation of software encryption algorithms such as AES in terms of encryption and decryption processes, and also requires calling the underlying hardware encryption card. Therefore, to make the virtual disk file encryption device provided by the present invention compatible with hardware encryption and decryption supported by hardware encryption cards, the embodiments of the present invention extend the LUKS driver. By extending the LUKS driver, the LUKS driver can call the encryption card driver API interface provided by the hardware encryption card to implement hardware encryption and decryption of virtual disk data. To achieve this goal, in one embodiment of the present invention, the implementation of the hardware encryption algorithm is encapsulated into a sub-driver of the LUKS driver. Multiple hardware encryption algorithms correspond to different sub-drivers. This makes it easy to expand the hardware encryption algorithm. For example, if a hardware encryption card currently needs to support the AES algorithm, the implementation of the AES hardware encryption algorithm can be added to the sub-driver. If other hardware encryption algorithms need to be added later, the corresponding sub-driver can be added to support the corresponding hardware encryption algorithm.

[0053] At least the following interface functions need to be implemented in the extended LUKS sub-driver:

[0054] create, create a hard encrypted virtual disk file;

[0055] open, open the hard encrypted virtual disk file;

[0056] encrypt, encrypt virtual disk file data;

[0057] decrypt, decrypt virtual disk file data;

[0058] getinfo, query the content of the virtual disk file encryption metadata object.

[0059] Figure 3 This is a flowchart of the steps for creating an encrypted virtual disk file in a virtual disk file encryption method provided by one embodiment of the present invention. The steps for creating an encrypted virtual disk file / encrypted virtual disk include:

[0060] Step 301. After receiving a virtual disk file creation request, the virtual disk file driver module determines whether the encryption parameters carried in the creation request are supported. If so, step 302 is executed.

[0061] When creating a virtual disk file, the user must select and enter encryption parameters. When the virtual machine initiates a virtual disk file creation request to the virtual disk file driver module in the virtual disk file encryption device, the request must include the encryption parameters. The required encryption parameters may vary depending on the encryption algorithm. Typical encryption parameters include: encryption algorithm name, encryption algorithm length, encryption mode, key index, and whether hardware encryption is used.

[0062] The encryption mode may be one of the five encryption modes of the Advanced Encryption Standard (AES), or one of the encryption modes of other encryption algorithms, which is not limited in the present invention. The five AES encryption modes are: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Counter (CTR), Cipher Feedback (CFB), and Output Feedback (OFB).

[0063] The key index refers to the index of the secret key in the hardware encryption card. To ensure key security, the key is actually stored in the hardware encryption card and is not exposed to the public. Each key has its own identifier, namely the key index. The application layer uses the key index instead of the actual key when calling the encryption card kernel driver.

[0064] The hardware encryption refers to whether the hardware encryption method provided by the present invention is implemented by the LUKS driver and the hardware encryption card. The present invention is compatible with software encryption methods, thus allowing users to select the encryption method.

[0065] When the virtual disk file driver module, such as the dotted disk file driver module in qcow2 format, determines that the encryption parameters carried in the request are not supported based on the supported encryption parameters, it can directly feedback the creation failure information to the requesting end and exit the creation process.

[0066] If it is determined that the encryption parameters carried in the creation request are not supported, a creation failure message is fed back to the requesting end, and the process ends. Since this step is not the focus of the embodiment of the present invention, it is omitted in the figure with a dotted line. The dotted parts in subsequent steps are similar.

[0067] Step 302. The virtual disk file driver module calls the LUKS driver module;

[0068] Step 303. The LUKS driver module determines whether hardware encryption is used based on the encryption parameters. If hardware encryption is used, the module proceeds to step 304. Otherwise, the module proceeds to software encryption to create an encrypted virtual disk file.

[0069] The virtual disk file driver module calls the LUKS driver in the LUKS driver module and, based on the encryption parameters carried in the creation request, determines whether hardware or software encryption is selected. If hardware encryption is selected, the corresponding LUKS sub-driver is selected based on the encryption parameters. The LUKS sub-driver then performs operations such as initializing the encryption card driver interface module.

[0070] Step 304: The LUKS driver module creates an encryption metadata object for the virtual disk file based on the encryption parameters and initializes the encryption card driver interface module.

[0071] The sub-driver module matching the encryption algorithm in the LUKS driver module creates an encryption metadata object QCryptoCipher of the virtual disk file to be created based on the encryption parameters carried in the creation request. The encryption metadata object is used to store configuration information such as encryption parameters.

[0072] Preferably, to improve security, the key index in the encryption parameter may be encrypted, and the encrypted key index may be stored in the encrypted metadata object. For example, the key index may be encrypted using pbkdf2 (an algorithm specifically designed for password storage).

[0073] Step 305: The virtual disk file driver module creates a virtual disk file by calling the LUKS driver module, and stores the encrypted metadata object content in the header of the created virtual disk file.

[0074] The sub-driver module in the LUKS driver module creates a virtual disk file by calling the interface function for creating a virtual disk file in the sub-driver, and stores the contents of the created encryption metadata object (which may include information such as the encryption algorithm name, encryption algorithm length, encryption mode, encrypted key index, and whether hardware encryption is used) in the metadata storage area in the header of the encrypted virtual disk file and writes it to the physical storage. The creation of the encrypted virtual disk, i.e., the creation of the virtual disk file, is successful, and the process ends.

[0075] Figure 4 This is a flowchart of the steps for reading and writing encrypted virtual disk file data in a virtual disk file encryption method provided by one embodiment of the present invention. The process of reading and writing encrypted virtual disk file data includes the process of encrypting and decrypting the virtual disk data, and the steps include:

[0076] Step 401. After receiving a virtual disk file opening request, the virtual disk file driver module determines whether the key index carried in the opening request is the same as the key index stored in the virtual disk file header. If they are the same, the virtual disk file is opened successfully.

[0077] When it is necessary to open the virtual encrypted disk created by the creation steps in the embodiment of the present invention, the virtual machine will send a virtual disk file opening request to the virtual disk file encryption device in QEMU. After receiving the opening request, the virtual disk file driver module will read the encrypted metadata object content stored in the virtual disk file header according to the metadata information of the virtual disk file (virtual disk file name, storage location information, etc.), create the encrypted metadata object corresponding to the virtual disk file in the memory, and then compare whether the key index carried in the opening request and the key index in the encrypted metadata object are the same. If they are the same, the virtual disk file is opened successfully, otherwise the opening fails. After the opening is successful, the read and write operations of the virtual disk can be performed subsequently. When the opening fails, the error information is fed back to the caller and the process ends. For the sake of simplicity, the steps of the failure branch are omitted.

[0078] Step 402: After receiving the virtual disk file read / write request, the virtual disk file driver module calls the LUKS driver module;

[0079] Step 403. The LUKS driver module determines whether hardware encryption is used based on the encryption parameters in the encrypted metadata object. If hardware encryption is used, step 404 is executed.

[0080] If it is determined that it is not hard encryption, the software encryption / decryption process is entered. For the sake of brevity, the software encryption / decryption process branch is omitted.

[0081] Step 404: The LUKS sub-driver module corresponding to the encryption algorithm in the LUKS driver module calls the encryption card driver interface module to perform hardware encryption and decryption processing on the read / write, and returns the processed data to the caller.

[0082] The LUKS driver module determines hardware encryption based on the "Is Hardware Encryption" parameter in the encryption metadata object QCryptoCipher. If hardware encryption is required, it matches a LUKS sub-driver based on the encryption algorithm and encryption mode in the QCryptoCipher object. Once a matching LUKS sub-driver is found, it calls the matching LUKS sub-driver for processing. The LUKS sub-driver further calls the encryption card driver interface module, which performs hardware encryption on written data or hardware decryption on read data by calling the encryption card driver's API. After completing the read / write data interface or encryption processing, the processed data is fed back to the virtual machine through the virtual disk file driver module.

[0083] The minimum length of the data segment processed by the virtual disk file driver module is configurable via parameters, and can be 512 bytes. If the data segment is long, it will be completed in multiple steps, and the read and write results will be returned to the upper layer to complete the data encryption and decryption. In addition, the key index is only verified when the virtual disk file is opened; subsequent read and write data do not need to be verified.

[0084] One embodiment of the present invention also provides a query function for the encryption information of an encrypted virtual disk file. The upper-layer application located in the virtual machine can send an encryption information query request to the virtual disk file driver module through the query interface. The virtual disk file driver module reads the content of the encrypted metadata object from the header of the encrypted virtual disk file and feeds it back to the inquirer. The encryption information that can be queried includes: encryption algorithm, encryption algorithm length, encryption algorithm mode, etc.

[0085] Figure 5 This is a schematic diagram of the structure of an electronic device for implementing the virtual disk file encryption method provided in one embodiment of the present invention. The device 500 includes a processor 510, such as a central processing unit (CPU), a communication bus 520, a communication interface 540, and a storage medium 530. The processor 510 and the storage medium 530 can communicate with each other via the communication bus 520. The storage medium 530 stores a computer program that, when executed by the processor 510, implements the functions of one or more steps in the virtual disk file encryption method provided in the present invention.

[0086] The storage medium may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage. In addition, the storage medium may also be at least one storage device located away from the aforementioned processor. The processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0087] It should be appreciated that embodiments of the present invention can be implemented or implemented by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory memory. The method can be implemented in a computer program using standard programming techniques, including a non-transitory storage medium configured with a computer program, wherein the storage medium configured in this manner causes the computer to operate in a specific and predefined manner. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if necessary, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. In addition, for this purpose, the program can be run on a programmed application-specific integrated circuit. In addition, the operations of the process described in the present invention can be performed in any suitable order, unless otherwise indicated by the present invention or otherwise clearly contradicted by the context. The process described in the present invention (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed collectively on one or more processors, by hardware or a combination thereof. The computer program includes multiple instructions that can be executed by one or more processors.

[0088] Furthermore, the methods can be implemented in any type of computing platform that is operably connected to a suitable computer, including but not limited to a personal computer, a minicomputer, a mainframe, a workstation, a network or distributed computing environment, a separate or integrated computer platform, or in communication with a charged particle tool or other imaging device, etc. Various aspects of the present invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, an optical read and / or write storage medium, RAM, ROM, etc., so that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. In addition, the machine-readable code, or portions thereof, can be transmitted over a wired or wireless network. When such media includes instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor, the invention described herein includes these and other different types of non-transitory computer-readable storage media. When programmed according to the methods and techniques of the present invention, the present invention also includes the computer itself.

[0089] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A virtual disk file encryption device, characterized in that: The device is located in the fast emulator QEMU, which includes: The virtual disk file driver module is used to receive read or write requests for encrypted virtual disk files sent by the virtual machine, read the requested data from the encrypted virtual disk file, or write the requested data to the encrypted virtual disk file; during the process of reading or writing data, the LUKS driver module is called to decrypt or encrypt the requested data, and the processing result is fed back to the requester; The LUKS driver module is used to determine whether software encryption or hardware encryption is used based on the encryption parameters of the encrypted virtual disk file, and to actually perform the corresponding decryption or encryption process based on the judgment result; The encryption card driver interface module is called by the LUKS driver module and is used to perform hardware decryption or encryption on the requested read or write data through the encryption card driver interface.

2. The device according to claim 1, characterized in that The LUKS driver module includes one or more LUKS sub-driver modules, and different LUKS sub-driver modules correspond to different hardware encryption algorithms and encryption modes; The LUKS driver module calls the corresponding LUKS sub-driver module according to the encryption algorithm parameters and encryption mode in the encryption parameters of the encrypted virtual disk file, and then the LUKS sub-driver module calls the encryption card driver interface module to perform hardware decryption or encryption.

3. The device according to claim 1, characterized in that The encryption card driver interface module performs hardware decryption or encryption of the requested read or write data by calling the application programming interface API and API static library of the hardware encryption card driver. The hardware encryption card driver is connected to the hardware encryption card installed on the host machine where the QEMU is located.

4. The device according to claim 1, characterized in that The virtual disk file driver module is further configured to receive a virtual disk file creation request and determine whether encryption parameters carried in the creation request are supported; the encryption parameters include: encryption algorithm name, encryption algorithm length, encryption mode, key index, and whether hardware encryption is used; The LUKS driver module is further configured to determine whether hardware encryption is used based on encryption parameters carried in the creation request; when hardware encryption is used, create an encryption metadata object for the virtual disk file based on the encryption parameters and initialize the encryption card driver interface module; The LUKS driver module is further used to create a virtual disk file and store the encrypted metadata object content in the header of the created virtual disk file.

5. The device according to claim 4, characterized in that The virtual disk file driver module is further configured to receive a virtual disk file opening request, determine whether the key index carried in the opening request is the same as the key index stored in the virtual disk file header, and if so, successfully open the virtual disk file.

6. A virtual disk file encryption method, characterized in that: The method is applied to a fast emulator QEMU in a host machine where a virtual machine is located, and the method includes: Receive read or write requests from virtual machines for encrypted virtual disk files, read the requested data from the encrypted virtual disk files, or write the requested data to the encrypted virtual disk files; during the data reading or writing process, call the LUKS driver to decrypt or encrypt the requested data, and feedback the processing results to the requester; When performing the decryption or encryption process, the LUKS driver determines whether software encryption or hardware encryption is used based on the encryption parameters of the encrypted virtual disk file, and actually executes the corresponding decryption or encryption process according to the determination result; The LUKS driver performs hardware decryption or encryption on the requested read or write data by calling the encryption card driver interface.

7. The method according to claim 6, characterized in that The LUKS driver performs hardware decryption or encryption on the requested read or write data by calling the encryption card driver interface, including: The LUKS driver includes one or more LUKS sub-drivers, and different LUKS sub-drivers correspond to different hardware encryption algorithms and encryption modes; The LUKS driver calls the corresponding LUKS sub-driver according to the encryption algorithm parameters and encryption mode in the encryption parameters of the encrypted virtual disk file, and then the LUKS sub-driver calls the encryption card driver interface module to perform hardware decryption or encryption on the requested read or write data; The encryption card driver interface module performs hardware decryption or encryption of the requested read or write data by calling the application programming interface API and API static library of the hardware encryption card driver.

8. The method according to claim 6, characterized in that The method further comprises: The virtual disk file driver receives the virtual disk file creation request and determines whether the encryption parameters carried in the creation request are supported; the encryption parameters include: encryption algorithm name, encryption algorithm length, encryption mode, key index, and whether hardware encryption is used; The LUKS driver determines whether hardware encryption is used based on the encryption parameters carried in the creation request. If hardware encryption is used, it creates an encryption metadata object for the virtual disk file based on the encryption parameters and initializes the encryption card driver interface module. The LUKS driver creates a virtual disk file and stores the encrypted metadata object content in the header of the created virtual disk file.

9. The method according to claim 8, characterized in that The method further comprises: The virtual disk file driver receives the virtual disk file opening request and determines whether the key index carried in the opening request is the same as the key index stored in the virtual disk file header. If they are the same, the virtual disk file is opened successfully.

10. An electronic device, characterized in that: It includes a processor, a communication interface, a storage medium and a communication bus, wherein the processor, the communication interface and the storage medium communicate with each other via the communication bus; Storage medium for storing computer programs; A processor, configured to implement the method according to any one of claims 6 to 9 when executing a computer program stored on a storage medium.

Images