WO2023216987A1 - Container image construction method and apparatus - Google Patents

Abstract

A container image construction method, comprising: obtaining a mirror file used for creating a container image; cutting the mirror file into a plurality of file blocks; respectively generating corresponding random symmetric keys for the plurality of file blocks; on the basis of the generated random symmetric keys, encrypting each file block in the plurality of file blocks to generate an encrypted container image.

Description

Container image construction method and device

This application claims priority to the Chinese patent application submitted to the China Patent Office on May 13, 2022, with application number 202210524707.7 and the application name "Container Image Construction Method and Device", the entire content of which is incorporated into this application by reference.

Technical field

One or more embodiments of this specification relate to the field of computer technology, and in particular, to a container image construction method and device.

Background technique

With the rapid development of Internet technology and cloud computing technology, container technology has become a widely recognized and applied method of sharing server resources. Developers can use container technology to deploy applications to any device that supports containers. A container image is a special file system that standardizes and encapsulates the application code and its running environment. Container images can run directly on any operating system that has containers installed.

Contents of the invention

In view of this, one or more embodiments of this specification provide a password acceleration method and device based on password acceleration hardware to solve problems existing in related technologies.

To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

According to a first aspect of one or more embodiments of this specification, a container image construction method is proposed, which method includes:

Obtain the image file used to create the container image;

Cut the image file into several file blocks;

Divide the several files into blocks and generate corresponding random symmetric keys respectively;

The file blocks among the several file blocks are respectively encrypted based on the generated random symmetric key to generate an encrypted container image.

According to the second aspect of one or more embodiments of this specification, a container image construction method is proposed, which method includes:

Obtain the image file used to create the container image;

Cut the image file into several file blocks;

Calculate hash values corresponding to the plurality of file blocks; calculate and generate a fourth symmetric key based on the hash value and the third symmetric key specified by the user;

The file blocks among the several file blocks are respectively encrypted based on the generated fourth symmetric key to generate an encrypted container image.

According to a third aspect of one or more embodiments of this specification, a container image building device is proposed, and the method includes:

File acquisition unit: obtains the image file used to create a container image;

File cutting unit: cuts the image file into several file blocks;

Key generation unit: divide the several files into blocks and generate corresponding random symmetric keys respectively;

Image generation unit: respectively encrypts the file blocks in the several file blocks based on the generated random symmetric key to generate an encrypted container image.

According to a fourth aspect of one or more embodiments of this specification, a container image building device is proposed, and the method includes:

File acquisition unit: obtains the image file used to create a container image;

File cutting unit: cuts the image file into several file blocks;

Key generation unit: calculates hash values corresponding to the plurality of file blocks; calculates and generates a fourth symmetric key based on the hash value and the third symmetric key specified by the user;

Image generation unit: respectively encrypts the file blocks among the several file blocks based on the generated fourth symmetric key to generate an encrypted container image.

According to the fifth aspect of one or more embodiments of this specification, a cryptographic co-processing is proposed, including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor implements the method described in the first aspect by running the executable instructions.

According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is proposed, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

Beneficial effects of this application:

This application cuts the image file used to create the container image into several file blocks, generates corresponding random symmetric keys for the several file blocks, encrypts the file blocks with the random symmetric key, and generates an encrypted container image. The symmetric key used for encryption is completely randomly generated, so it can completely resist offline dictionary attacks and improve the security of container images.

Description of the drawings

Figure 1 is a schematic system architecture diagram of a container image building method provided by an exemplary embodiment.

Figure 2 is a flow chart of a container image building method provided by an exemplary embodiment.

Figure 3 is a metadata file structure diagram provided by an exemplary embodiment.

Figure 4 is a schematic diagram of a container image building process provided by an exemplary embodiment.

Figure 5 is a schematic diagram of another container image building process provided by an exemplary embodiment.

Figure 6 is a schematic diagram of a container image deployment process provided by an exemplary embodiment.

FIG. 7 is a schematic structural diagram of an electronic device for container construction provided in an exemplary embodiment.

Figure 8 is a block diagram of a container image building apparatus provided by an exemplary embodiment.

Figure 9 is a flow chart of a container image building method provided by an exemplary embodiment.

Figure 10 is a metadata file structure diagram provided by an exemplary embodiment.

Figure 11 is a schematic diagram of another container image building process provided by an exemplary embodiment.

Figure 12 is a schematic diagram of a container image deployment process provided by an exemplary embodiment.

Figure 13 is a schematic structural diagram of an electronic device for container construction provided in an exemplary embodiment.

Figure 14 is a block diagram of a container image building device provided in an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, methods may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.

In related technologies, container image files are encrypted to generate encrypted container image files, and convergent encryption (CE, Convergent encryption) is usually used. Among them, the convergent encryption key is calculated from the original file of the container image. Therefore, an attacker can encrypt the plaintext of the guessed container image and compare it with it, possibly guessing the original file. Moreover, since any user with access to the original file can calculate the convergence key based on the original file content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks. .

In view of this, this manual proposes a container image construction method. When building the image, a completely random symmetric key is generated, and then the random symmetric key is used for encryption.

During implementation, the image file used to create the container image is obtained, and the image file is cut into several file blocks. Generate corresponding random symmetric keys for several file blocks, then encrypt each file block based on the generated random symmetric key, and finally generate an encrypted container image.

Figure 1 is a schematic system architecture diagram of a container image building method provided by an exemplary embodiment. As shown in Figure 1, the system may include multiple different forms of terminals 102, 106, 108, 110, and a network for connecting different terminals. 104. The terminals 102, 106, 108, and 110 may include electronic devices such as laptops, mobile phones, and tablet devices, as well as virtual terminals such as cloud computers and cloud servers. The network 104 may include multiple types of wired or wireless networks.

In one embodiment, it is assumed that the terminals 102, 106, 108, and 110 are all computers. The user can create an encrypted container image through the terminal 102 based on the container construction method provided in this manual, and upload the container image to the network. Users of other terminals can obtain the container image through the network through terminals 106, 108, 110, etc., and deploy the container image to their own terminals for use.

The container image construction scheme of this manual will be described in detail below with reference to the accompanying drawings.

Please refer to Figure 2. Figure 2 is a flow chart of a container image building method provided by an exemplary embodiment. As shown in Figure 2, the method may include the following execution steps:

Step 202: Obtain the image file used to create the container image;

In this embodiment, the image file used to create the container image can be generated from a local data file, or a new image file can be generated based on an existing image file by adding a data file. Users can directly obtain the image file used to create the image through the network, for example, they can pull it directly from the image warehouse; users can also obtain the container image through the network and add data files locally to generate the image file. It should be noted that the image file used to create a container image can be a collection of files, for example, it can be a directory of image files pulled from the image warehouse. In one embodiment, the file collection of image files can also be preprocessed, and the image files used to create the container image can be serialized into one file, which can facilitate subsequent cutting processing.

Step 204: Cut the image file into several file blocks;

In related technologies, container images are usually managed in layers. The smallest unit that can be shared between different images is the layer in the image. There may be a large amount of duplicate data between layers, but even if there are minor differences, are treated as different layers. Therefore, in order to facilitate the deduplication of image files, the files can be processed into blocks.

Since cutting all image files may produce file blocks with the same data, the file blocks generated after cutting can be deduplicated. In this embodiment, the corresponding hash value can be calculated for each file block according to the corresponding hash algorithm, and deduplication processing can be performed based on the calculated hash value. Specifically, the hash algorithm may be MD5 algorithm, SHA algorithm, etc., which is not limited in the present invention.

In one implementation, the hash value of each file block can be calculated locally, and deduplication processing is performed on the hash value of each file block. Specifically, each hash value can be matched locally. If the hash values are the same, only one of the file blocks is reserved for data sharing. It should be noted that the user can freely set the scope of the shared domain. For example, the user can choose to retain multiple file blocks with the same hash value, or only retain one. The present invention does not limit this. In one case, the user can also set one or more encrypted file blocks as a shared domain. During local deduplication, since the relevant data and hash values of these file blocks cannot be accessed, problems related to these file blocks may appear. Encrypted multiple file chunks file chunks with the same hash value.

In another implementation, the deduplication process can also be performed by a deduplication server based on the calculated hash value. Specifically, the hash value of each file block can be calculated locally and the hash value is sent to the deduplication server through an encrypted connection. The deduplication server matches the hash value of each file chunk. If the hash values are the same, only one is retained. Files are chunked for sharing. It should be noted that the user can also preset the scope of the shared domain. For example, the user can set the deduplication server to retain multiple file blocks with the same hash value, or only one, which is not limited by the present invention. In one case, the user can also set one or more encrypted file blocks as a shared domain. The deduplication server does not have permission to obtain the hash values of these file blocks, so the deduplication server does not target these hash values. Deduplication is performed so that file chunks can appear that have the same hash as these encrypted multiple file chunks.

Users can also send file blocks directly to the deduplication server through an encrypted connection, so that the deduplication server can calculate the hash value of each file block, and then deduplicate the hash value of the file block.

In order to further reduce the storage overhead of the image file, after cutting the image file into several file blocks, each file block can also be compressed, and then the compressed file blocks can be further processed.

Step 206: Divide the several files into blocks and generate corresponding random symmetric keys respectively;

In related technologies, container image files are encrypted to generate encrypted container image files, and convergent encryption (CE, Convergent encryption) is usually used. Among them, the convergent encryption key is calculated from the original file of the container image. Therefore, an attacker can encrypt the plaintext of the guessed container image and compare it with it, possibly guessing the original file. Moreover, since any user with access to the original file can calculate the convergence key based on the original file content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks.

To resist possible offline dictionary attacks, the container image can be encrypted with a completely random symmetric key. In this embodiment, corresponding random symmetric keys are generated for several file blocks generated after cutting the image file, and are used to encrypt the several file blocks. The above-mentioned random symmetric key may specifically be a parameter used to convert data plaintext into data ciphertext. Users are free to choose any random algorithm to generate completely random symmetric keys. Since the above symmetric key is generated completely randomly, the attacker cannot crack it based on the password dictionary.

In one embodiment, a completely random symmetric key can be generated for the deduplicated file blocks; if deduplication is performed locally, corresponding random symmetric keys can be generated locally for several deduplicated file blocks. . If you use a deduplication server to remove duplication, the deduplication server can generate corresponding random symmetric keys for the deduplicated file blocks.

Step 208: Encrypt the file blocks among the several file blocks based on the generated random symmetric key respectively to generate an encrypted container image.

In this embodiment, each file block can be encrypted separately based on the above-mentioned randomly generated symmetric key, and then an encrypted container image can be constructed based on the encrypted file blocks. It should be noted that according to user needs, files can be organized into blocks in any form to build an encrypted container image, which is not limited by the present invention. Because the files are segmented in advance and deduplicated based on the hash values of the file segments, the local storage cost of the container image is reduced; because each file segment is encrypted with a completely random symmetric key, it can resist Possible offline dictionary attacks improve the security of container images.

In one embodiment, the data format corresponding to the container image may also include a metadata file and at least one data file; wherein the data file is composed of at least one file block and is used to record the data in the container image; the data file also has Description information can be used to indicate the specific storage location of each file block in the data file. The description information may also include a random symmetric key corresponding to each file block generated above.

The metadata file is used to record the metadata corresponding to the data file; where the metadata indicates the specific storage location of each data file in the container image, and the at least one data file corresponding to the description information corresponding to the above-mentioned at least one data file can be generated. A piece of metadata.

After generating the above-mentioned several file segments, at least one data file can be generated based on at least one file segment; at least one piece of metadata is generated based on the description information corresponding to the at least one data file, and then a metadata file is generated based on the at least one piece of metadata. After generating the above at least one data file and metadata file, an encrypted container image can be generated based on at least one data file and metadata file.

Please refer to Figure 3, which is a metadata file structure diagram provided by an exemplary embodiment. As shown in Figure 3, the metadata file may be composed of multiple pieces of metadata; the metadata may be composed of multiple pieces of description information; each piece of description information may include the storage location of multiple file blocks and the random number corresponding to the file block. Symmetric key. In another embodiment, the data format corresponding to the above-mentioned container image may also include a hash database file. The hash database file is used to manage the hash values of the above-mentioned file blocks and the random symmetric keys corresponding to the above-generated file blocks. . It should be noted that in the above technical solution based on local deduplication, a hash database file is usually required; in the technical solution based on deduplication server for deduplication, the user can freely choose to generate a hash database file or not to generate a hash database file. database file, which is not limited by the present invention.

After calculating the hash value corresponding to each file block and generating the random symmetric key corresponding to the file block, the corresponding relationship between the hash value and the random symmetric key can be established based on the hash value and the random symmetric key. And save the corresponding relationship to the above hash database file. It should be noted that since the above random symmetric key is completely randomly generated, the same random symmetric key may correspond to the hash values of multiple file blocks, so the corresponding relationship between the above hash value and the random symmetric key can be Multiple hash values correspond to the same random symmetric key.

The above hash database file can be used to deduplicate the hash value of each file block locally when building a container image. When building a container image, since local deduplication may be required, the symmetric relationship between the hash value of the file block and the random symmetric key can be established and saved to the hash database according to the shared domain range set by the above user. The actual hash value of the block is matched against the hash value stored in the hash database. If the matching results are consistent, and the user has not preset that the file block does not require deduplication, the deduplication process will be performed accordingly. If the matching results are inconsistent, a new hash value of the file block and the random symmetric key will be established. The corresponding relationship is saved to the hash database file.

When building a new container image by adding data files to an existing container image; or when reorganizing and generating new meta files based on the data files of an existing container image to build a new container image; you also need to use Ha. The database file is required to be deduplicated in a similar manner to the local deduplication described above. You can obtain new data files corresponding to the encrypted container image; you can serialize the new data files, and use the file cutting algorithm to cut the image files into the same size according to the file block size preset by the user. Several file blocks; the corresponding hash value can be calculated for each file block according to the corresponding hash algorithm; based on the hash value corresponding to the file block, the corresponding hash value can be calculated based on the shared domain range set by the above user. Match the hash values stored in the hash database. If the matching results are consistent, deduplication processing will be performed accordingly. If the matching results are inconsistent, a new correspondence between the hash values of the file blocks and the random symmetric key will be established and saved to Hash database file.

In another embodiment, in order to further ensure the security of the container image, the metadata file and hash database generated above can be further encrypted, where the encryption method can be a symmetric encryption method or an asymmetric encryption method.

In the symmetric encryption method, the hash database can be encrypted based on the first symmetric key specified by the user, and the metadata file can be encrypted based on the second symmetric key specified by the user. It should be noted that the third symmetric key specified by the user The one symmetric key and the second symmetric key may be the same or different, and the present invention does not limit this.

In the asymmetric encryption method, the hash database can be encrypted based on the public key of the first asymmetric key specified by the user, and the metadata file can be encrypted based on the public key of the second asymmetric key specified by the user. It should be noted that the first asymmetric key and the second asymmetric key specified by the user may be the same or different, and the present invention does not limit this.

Through the above methods described in this manual, a lightweight encrypted container image can be built. Corresponding to the construction of the container image, the user can also selectively deploy the container image.

The user can obtain the container image constructed by the above method in any form, such as downloading through the network, transmitting through a secure connection, etc., which is not limited by the present invention. After obtaining the encrypted container image, you can obtain the metadata file and at least one data file in the container image, where the data file includes at least one encrypted file block; the metadata file records at least one piece of metadata, where the metadata also The random symmetric key corresponding to the encrypted file block is stored. The encrypted file block can be decrypted based on the random symmetric key, and then a file system tree is built based on the metadata file and several file blocks to complete the container image. deployment.

In one implementation, in order to ensure the security of the container image, the metadata file in the container image is also encrypted. Therefore, during the deployment process, it is necessary to obtain the symmetric key or asymmetric key provided by the user, and pair the metadata file. Only after decrypting the metadata can the random symmetric key of each file block be obtained, and then the file can be Decrypt in chunks for subsequent deployment operations. In practical applications, the hash database in the container image is also encrypted. Therefore, during the deployment process, when the hash database needs to be used, it is also necessary to obtain the symmetric key or asymmetric key provided by the user, decrypt the hash database, and perform subsequent deployment operations.

The above container image construction method will be further explained through a specific embodiment in conjunction with the figure below.

As shown in Figure 4, the encrypted container image can include metadata files, several data files, and hash database files. The file blocks shown in Figure 4 are file blocks generated after being cut according to the above-mentioned image file through a specific file cutting algorithm. After generating file chunks, a corresponding random symmetric key can be generated for each file chunk, and the hash value of each file chunk can be calculated based on the file chunks. Then create a corresponding relationship between the random symmetric key and the hash value of the file block, and generate a hash database file based on the corresponding relationship between the random symmetric key and the hash value of the file block. The user can specify a symmetric key or an asymmetric key to encrypt the hash database file.

During the process of generating a hash database file, the hash values of the file blocks and the hash values stored in the hash database can be matched to perform deduplication locally. After the file blocks are deduplicated locally, the file blocks can be selectively compressed, and each file block can be encrypted using the random symmetric key generated above. Then several data files of container images can be composed according to the encrypted file blocks.

The description information of the data file and the random symmetric keys corresponding to the above-mentioned file blocks can form metadata, and a metadata file is generated based on the metadata. The user can specify a symmetric key or an asymmetric key to encrypt the metadata file. After generating the metadata file and several data files, the encrypted container image is built.

The above container image construction method will be further explained through another specific embodiment with reference to Figure 5.

As shown in Figure 5, the encrypted container image can include metadata files and several data files. The file blocks shown in Figure 5 are file blocks generated after being cut according to the above-mentioned image file through a specific file cutting algorithm. After the file chunks are generated, the hash value of each file chunk is calculated based on the file chunks. The hash values of the file chunks are then sent to the deduplication server, which performs deduplication. After the deduplication server deduplicates the file into chunks, it can generate a random symmetric key corresponding to the file chunks. After the file chunks are deduplicated by the deduplication server, the file chunks can be selectively compressed, and each file chunk can be encrypted using the random symmetric key generated above. Then the data of several container images can be composed according to the encrypted file chunks. document.

The description information of the data file and the random symmetric keys corresponding to the above-mentioned file blocks can form metadata, and a metadata file is generated based on the metadata. The user can specify a symmetric key or an asymmetric key to encrypt the metadata file. After generating the metadata file and several data files, the encrypted container image is built.

It should be noted that in this embodiment, since the hash values of the file blocks are sent to the deduplication server, and the deduplication is deduplicated by the deduplication server, there is no need to perform deduplication locally, and there is no need to record the hashes of the file blocks. The corresponding relationship between the value and the random symmetric key, so there is no need to generate a hash database file. The user can choose whether to generate a hash database file, and the present invention does not limit this.

The above container image deployment process will be further explained through another specific embodiment in conjunction with Figure 6 below.

As shown in Figure 6, the encrypted container image can include metadata files and several data files. After the user obtains the encrypted container image, the metadata file can be decrypted based on the symmetric key or asymmetric key specified by the user. The metadata file records multiple pieces of metadata, which contains description information to describe the specific storage location of the data file in the image, and a random symmetric key for decrypting file blocks. The data file includes several file blocks, and the file blocks are decrypted using the above random symmetric key. After decrypting the file blocks, if the file blocks are compressed file blocks, the file blocks can be decompressed to obtain the original file blocks. Based on the description information of the metadata file and several file blocks, a file system tree can be constructed to complete the deployment of the container image.

FIG. 7 is a schematic structural diagram of an electronic device for container construction provided in an exemplary embodiment. Please refer to Figure 7. At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710. Of course, it may also include other hardware required for services. One or more embodiments of this specification may be implemented based on software. For example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.

Please refer to FIG. 8 , which is a block diagram of a cryptographic acceleration device based on cryptographic acceleration hardware provided in an exemplary embodiment.

File acquisition unit 802: used to acquire image files used to create container images;

File cutting unit 804: used to cut the image file into several file blocks;

Key generation unit 806: used to divide the several files into blocks and generate corresponding random symmetric keys respectively;

Image generation unit 808: configured to respectively encrypt the file blocks among the several file blocks based on the generated random symmetric key to generate an encrypted container image.

Optionally, the data format corresponding to the container image includes a metadata file and at least one data file; the metadata file is used to record metadata corresponding to the data file; the image generation unit 808: specifically used to generate based on The random symmetric key respectively encrypts the file blocks in the several file blocks, and generates the at least one data file based on the encrypted several file blocks;

Generate at least one piece of metadata corresponding to the at least one data file based on the description information corresponding to the at least one data file, and further generate the metadata file based on the at least one piece of metadata; wherein the description information includes the The random symmetric key;

Generate an encrypted container image based on the at least one data file and the metadata file.

Optionally, the key generation unit 806: specifically calculates hash values corresponding to the several file blocks; and performs deduplication processing on the several file blocks based on the calculated hash values.

Optionally, the data format corresponding to the image file also includes a hash database file; the image generation unit 808 is further configured to be based on the hash values of the several file blocks and all the generated files for the several file blocks. Correspondence between the random symmetric keys; generate at least one hash database file corresponding to the several file blocks.

Optionally, the container image building device further includes: a data encryption unit: encrypts the hash database file based on the first symmetric key specified by the user; or, based on the first asymmetric key pair of the user The public key encrypts the hash database file.

Optionally, the container image building device further includes: a data encryption unit: configured to encrypt the metadata file based on a second symmetric key specified by the user; or, based on the user's second asymmetric key pair The metadata file is encrypted with the public key.

Optionally, the first symmetric key and the second symmetric key are the same; the first asymmetric key and the second asymmetric key are the same.

Optionally, the container image building device further includes: an image deployment unit: obtaining the generated encrypted container image;

Obtain the random symmetric key in the metadata file of the encrypted container image;

Decrypt several file blocks of the data file of the encrypted container image based on the random symmetric key respectively;

A file system tree is constructed in blocks based on the metadata file and the decrypted files to complete the deployment of the container image.

Optionally, the container image device further includes: an incremental deduplication unit: obtaining a new data file corresponding to the encrypted container image;

Cut the newly added data file into several file blocks, and calculate the hash values corresponding to the several file blocks;

Match the hash values corresponding to the several file blocks with the hash values stored in the hash database file to perform deduplication.

Please refer to Figure 9. Figure 9 is a flow chart of a container image building method provided by an exemplary embodiment. As shown in Figure 8, the method may include the following execution steps:

Step 902: Obtain the image file used to create the container image;

In this embodiment, the image file used to create the container image can be generated by the virtual machine based on the original operating system, or a new image file can be generated based on the existing image file by adding a data file. Users can directly obtain the image file used to create an image through the network. For example, they can directly pull it from the image warehouse, or they can generate the image file used for creation locally through a virtual machine. Users can also obtain the container image through the network and upload it to Add data files locally to generate image files. It should be noted that the image file used to create a container image can be a collection of files, for example, it can be a directory of image files pulled from the image warehouse. In one embodiment, the file collection of image files can also be preprocessed, and the image files used to create the container image can be serialized into one file, which can facilitate subsequent cutting processing.

Step 904: Cut the image file into several file blocks;

In related technologies, container images are usually managed in layers. The smallest unit that can be shared between different images is the layer in the image. There may be a large amount of duplicate data between layers, but even if there are minor differences, are treated as different layers. Therefore, in order to facilitate the deduplication of image files, the files can be processed into blocks.

In this embodiment, the image file used to create the container image can be serialized, and the image file is cut into several file blocks of the same size through a file cutting algorithm according to the file block size preset by the user. File chunking usually stores less data, takes up less storage space, is easier to manage, and is easier to deduplicate.

Since cutting all image files may produce file blocks with the same data, the file blocks generated after cutting can be deduplicated. In this embodiment, the corresponding hash value can be calculated for each file block according to the corresponding hash algorithm, and deduplication processing can be performed based on the calculated hash value. Specifically, the hash algorithm may be MD5 algorithm, SHA algorithm, etc., which is not limited in the present invention.

In one implementation, the hash value of each file block can be calculated locally, and deduplication processing is performed on the hash value of each file block. Specifically, each hash value can be matched locally. If the hash values are the same, only one of the file blocks is reserved for data sharing. It should be noted that the user can freely set the scope of the shared domain. For example, the user can choose to retain multiple file blocks with the same hash value, or only retain one. The present invention does not limit this. In one case, the user can also set one or more encrypted file blocks as a shared domain. During local deduplication, since the relevant data and hash values of these file blocks cannot be accessed, problems related to these file blocks may appear. Encrypted multiple file chunks file chunks with the same hash value.

In order to further reduce the storage overhead of the image file, after cutting the image file into several file blocks, each file block can also be compressed, and then the compressed file blocks can be further processed.

Step 906: Calculate hash values corresponding to the several file blocks; calculate and generate a fourth symmetric key based on the hash value and the third symmetric key specified by the user;

In related technologies, container image files are encrypted to generate encrypted container image files, and convergent encryption (CE, Convergent encryption) is usually used. Among them, the convergent encryption key is calculated from the original file of the container image. Therefore, an attacker can encrypt the plaintext of the guessed container image and compare it with it, possibly guessing the original file. Moreover, since any user with access to the original file can calculate the convergence key based on the original file content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks.

In order to resist possible offline dictionary attacks, a fourth symmetric key can be generated based on the hash value of the file block and the third symmetric key specified by the user, and the container image can be encrypted with the fourth symmetric key. Since the third symmetric key is an arbitrary key specified by the user, after calculating the hash value of the file block itself, the attacker cannot crack it with brute force, nor can it crack it based on the ciphertext dictionary.

In this embodiment, for several file blocks generated after cutting the image file, a fourth symmetric key is calculated based on the hash value of the file blocks and the third symmetric key specified by the user, which is used to encrypt the several file blocks. File chunking. The above-mentioned fourth symmetric key may specifically be a parameter used to convert data plaintext into data ciphertext. The above calculation can be performed in various ways, and is used to calculate the fourth symmetric key from the hash value and the third symmetric key specified by the user, which is not limited by the present invention. For example, the above calculation may specifically be an XOR operation.

In one embodiment, the deduplicated file can be divided into blocks, and a fourth symmetric key can be generated based on the hash value of the file blocks and the third symmetric key specified by the user; if deduplication is performed locally, the fourth symmetric key can be generated. Corresponding fourth symmetric keys are generated locally for several file blocks after deduplication.

Step 908: Encrypt the file blocks among the several file blocks based on the generated fourth symmetric key respectively to generate an encrypted container image.

In this embodiment, each file block can be encrypted separately according to the fourth symmetric key generated above, and then an encrypted container image can be constructed based on the encrypted file blocks. It should be noted that according to user needs, files can be organized into blocks in any form to build an encrypted container image, which is not limited by the present invention. Since the file is divided into blocks in advance and deduplication is performed based on the hash value of the file block, the local storage cost of the container image is reduced; because each file block is encrypted using the fourth symmetric key, and the fourth The symmetric key is calculated from the hash value of the file block itself and the third symmetric key specified by the user, so it can resist possible offline dictionary attacks and improve the security of the container image.

In one embodiment, the data format corresponding to the container image may also include a metadata file and at least one data file; wherein the data file is composed of at least one file block and is used to record the data in the container image; the data file also has Description information can be used to indicate the specific storage location of each file block in the data file. The description information may also include a hash value corresponding to each file block generated above.

The metadata file is used to record the metadata corresponding to the data file; where the metadata indicates the specific storage location of each data file in the container image, and the at least one data file corresponding to the description information corresponding to the above-mentioned at least one data file can be generated. A piece of metadata.

Please refer to Figure 10, which is a metadata file structure diagram provided by an exemplary embodiment. As shown in Figure 10, the metadata file may be composed of multiple pieces of metadata; the metadata may be composed of multiple pieces of description information; each piece of description information It can include the storage locations of multiple file chunks and the hash values corresponding to the file chunks.

After generating the above-mentioned several file segments, at least one data file can be generated based on at least one file segment; at least one piece of metadata is generated based on the description information corresponding to the at least one data file, and then a metadata file is generated based on the at least one piece of metadata. After generating the above at least one data file and metadata file, an encrypted container image can be generated based on at least one data file and metadata file. In another embodiment, in order to further ensure the security of the container image, the metadata file generated above can be further encrypted, where the encryption method can be a symmetric encryption method or an asymmetric encryption method.

In the symmetric encryption method, the metadata file can be encrypted based on the fifth symmetric key specified by the user; in the asymmetric encryption method, the metadata file can be encrypted based on the public key of the third asymmetric key specified by the user. Encrypt.

Through the above methods described in this manual, a lightweight encrypted container image can be built. Corresponding to the construction of the container image, the user can also selectively deploy the container image.

The user can obtain the container image constructed by the above method in any form, such as downloading through the network, transmitting through a secure connection, etc., which is not limited by the present invention. After obtaining the encrypted container image, you can obtain the metadata file and at least one data file in the container image, where the data file includes at least one encrypted file block; the metadata file records at least one piece of metadata, where the metadata also The hash value corresponding to the encrypted file block is stored. The fourth symmetric key can be calculated based on the hash value and the third symmetric key specified by the user, and then the encrypted file block is processed based on the fourth symmetric key. Decrypt, and finally build a file system tree based on the metadata file and several file blocks to complete the deployment of the container image.

In one implementation, in order to ensure the security of the container image, the metadata files and hash database files in the container image are also encrypted. Therefore, during the deployment process, it is necessary to obtain the symmetric key or asymmetric key provided by the user to decrypt the metadata file; only after decrypting the metadata file can the hash value of each file block be obtained. Calculate the fourth symmetric key based on the hash value and the third symmetric key specified by the user, and then decrypt the file blocks for subsequent deployment operations.

The above container image construction method will be further explained through another specific embodiment with reference to Figure 11.

As shown in Figure 11, the encrypted container image can include metadata files and several data files. The file blocks shown in Figure 11 are file blocks generated by cutting the above image file through a specific file cutting algorithm. After the file chunks are generated, the hash value of each file chunk is calculated based on the file chunks. Calculate the symmetric key used to encrypt the file chunks based on the hash value of each file chunk and a user-specified random symmetric key; the chunks can then be deduplicated based on the hash value, which can be done directly locally Deduplication processing. When the file blocks pass the deduplication process, the file blocks can be selectively compressed, and each file block can be encrypted using the symmetric key generated above. Then the data of several container images can be composed according to the encrypted file blocks. document.

The description information of the data file and the hash values corresponding to the above-mentioned file blocks can form metadata, and a metadata file is generated based on the metadata. The user can specify a symmetric key or an asymmetric key to encrypt the metadata file. After generating the metadata file and several data files, the encrypted container image is built.

The above container image deployment process will be further explained through another specific embodiment with reference to Figure 12.

As shown in Figure 12, the encrypted container image can include metadata files and several data files. After the user obtains the encrypted container image, the metadata file can be decrypted based on the symmetric key or asymmetric key specified by the user. The metadata file records multiple pieces of metadata, which contains description information to describe the specific storage location of the data file in the image, and also has hash values of the file blocks. Users can use the specified symmetric key to calculate the hash value of the file block to generate a symmetric key for decryption. The data file includes several file blocks, and the file blocks are decrypted using the symmetric key generated above for decryption. After decrypting the file blocks, if the file blocks are compressed file blocks, the file blocks can be decompressed to obtain the original file blocks. Based on the description information of the metadata file and several file blocks, a file system tree can be constructed to complete the deployment of the container image.

Figure 13 is a schematic structural diagram of an electronic device for container construction provided in an exemplary embodiment. Please refer to Figure 13. At the hardware level, the device includes a processor 1302, an internal bus 1304, a network interface 1306, a memory 1308, and a non-volatile memory 1310. Of course, it may also include other hardware required by the business. One or more embodiments of this specification can be implemented based on software. For example, the processor 1302 reads the corresponding computer program from the non-volatile memory 1310 into the memory 1308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.

Please refer to FIG. 14 , which is a block diagram of a cryptographic acceleration device based on cryptographic acceleration hardware provided in an exemplary embodiment.

File acquisition unit 1402: used to acquire image files used to create container images;

File cutting unit 1404: used to cut the image file into several file blocks;

Key generation unit 1406: used to calculate hash values corresponding to the plurality of file blocks; calculate and generate a fourth symmetric key based on the hash value and the third symmetric key specified by the user;

Image generation unit 1408: configured to respectively encrypt the file blocks among the several file blocks based on the generated random symmetric key to generate an encrypted container image.

Optionally, the data format corresponding to the container image includes a metadata file and at least one data file; the metadata file is used to record metadata corresponding to the data file; the image generation unit 1408: specifically used to generate based on The fourth symmetric key respectively encrypts the file blocks in the plurality of file blocks to generate an encrypted container image.

Generate at least one piece of metadata corresponding to the at least one data file based on the description information corresponding to the at least one data file, and further generate the metadata file based on the at least one piece of metadata; wherein the description information includes the The hash value of the file chunks

Generate an encrypted container image based on the at least one data file and the metadata file.

Optionally, the key generation unit 1406: performs deduplication processing on the several file blocks based on the calculated hash value.

Optionally, the container image building device further includes: a data encryption unit: encrypts the metadata file based on a fifth symmetric key specified by the user; or,

The metadata file is encrypted based on the public key in the user's third asymmetric key pair.

Optionally, the container image building device further includes: an image deployment unit: obtaining the generated encrypted container image;

Get the generated encrypted container image;

Obtain the hash value in the metadata file of the encrypted container image;

Calculate and generate a fourth symmetric key based on the hash value and the third symmetric key specified by the user;

Decrypt several file blocks of the data file of the encrypted container image based on the fourth symmetric key respectively;

A file system tree is constructed in blocks based on the metadata file and the decrypted files to complete the deployment of the container image.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, or a game controller. desktop, tablet, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. exist In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain implementations.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of this specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a," "the" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although one or more embodiments of this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent substitutions, improvements, etc. shall be included in the scope of protection of one or more embodiments of this specification.

Claims (14)

A container image building method, characterized in that the method includes: Obtain the image file used to create the container image; Cut the image file into several file blocks; Divide the several files into blocks and generate corresponding random symmetric keys respectively; The file blocks among the several file blocks are respectively encrypted based on the generated random symmetric key to generate an encrypted container image. The method according to claim 1, the data format corresponding to the container image includes a metadata file and at least one data file; the metadata file is used to record metadata corresponding to the data file; The step of encrypting file blocks among the several file blocks based on the generated random symmetric key to generate an encrypted container image includes: Encrypt file blocks in the plurality of file blocks based on the generated random symmetric key respectively, and generate the at least one data file based on the encrypted file blocks; Generate at least one piece of metadata corresponding to the at least one data file based on the description information corresponding to the at least one data file, and further generate the metadata file based on the at least one piece of metadata; wherein the description information includes the The random symmetric key; Generate an encrypted container image based on the at least one data file and the metadata file. The method according to claim 1, before encrypting the file blocks in the plurality of file blocks based on the generated random symmetric key, the method includes: Calculate the hash values corresponding to the several file blocks; Deduplication processing is performed on the several file blocks based on the calculated hash value. The method according to claim 3, performing deduplication processing on the several file blocks based on the calculated hash value, including: Perform deduplication processing on the several file blocks locally based on the calculated hash value; or, The hash value is sent to a deduplication server, so that the deduplication server performs deduplication processing on the hash value based on the calculated hash value. According to the method of claim 3, the data format corresponding to the image file further includes a hash database file; the method further includes: Based on the correspondence between the hash values of the several file blocks and the random symmetric keys generated for the several file blocks; generating at least one hash database file corresponding to the several file blocks. The method of claim 5, further comprising any of the following: Encrypt the hash database file based on a user-specified first symmetric key; or, The hash database file is encrypted based on the public key in the user's first asymmetric key pair. The method of claim 2, further comprising any of the following: Encrypt the metadata file based on a user-specified second symmetric key; or, The metadata file is encrypted based on the public key in the user's second asymmetric key pair. The method of claim 2, further comprising: Get the generated encrypted container image; Obtain the random symmetric key in the metadata file of the encrypted container image; Decrypt several file blocks of the data file of the encrypted container image based on the random symmetric key respectively; A file system tree is constructed in blocks based on the metadata file and the decrypted files to complete the deployment of the container image. The method of claim 5, further comprising: Obtain the newly added data file corresponding to the encrypted container image; Cut the newly added data file into several file blocks, and calculate the hash values corresponding to the several file blocks; Match the hash values corresponding to the several file blocks with the hash values stored in the hash database file to perform deduplication. A container image building method, characterized in that the method includes: Obtain the image file used to create the container image; Cut the image file into several file blocks; Calculate hash values corresponding to the plurality of file blocks; calculate and generate a fourth symmetric key based on the hash value and the third symmetric key specified by the user; The file blocks among the several file blocks are respectively encrypted based on the generated fourth symmetric key to generate an encrypted container image. The method according to claim 10, the data format corresponding to the container image includes a metadata file and at least one data file; the metadata file is used to record metadata corresponding to the data file; The step of encrypting file blocks among the several file blocks based on the generated random symmetric key to generate an encrypted container image includes: Encrypt file blocks in the plurality of file blocks based on the generated random symmetric key respectively, and generate the at least one data file based on the encrypted file blocks; Generate at least one piece of metadata corresponding to the at least one data file based on the description information corresponding to the at least one data file, and further generate the metadata file based on the at least one piece of metadata; wherein the description information includes the The hash value of the file block; Generate an encrypted container image based on the at least one data file and the metadata file. The method according to claim 11, before encrypting the file blocks in the plurality of file blocks based on the generated fourth symmetric key, the method includes: Deduplication processing is performed on the several file blocks based on the hash value. An electronic device, characterized by including: processor; Memory used to store instructions executable by the processor; Wherein, the processor implements the method according to any one of claims 1-12 by running the executable instructions. A computer-readable storage medium, characterized in that computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-12 are implemented.