Container image construction method and apparatus

Abstract

The present specification provides a container image construction method and device, which comprises the following steps: obtaining an image file used for creating a container image; cutting the image file into a plurality of file blocks; generating a corresponding random symmetric key for each of the plurality of file blocks; and encrypting each of the plurality of file blocks based on the generated random symmetric key to generate an encrypted container image.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of computer technology, and more particularly to a container image construction method and device. BACKGROUND

[0002] With the rapid development of Internet technology and cloud computing technology, container technology has become a widely recognized and applied server resource sharing method. Developers can deploy applications to any container-enabled device through container technology. A container image is a special file system obtained by standardizing the encapsulation of the code of an application and its running environment. The container image can be directly run in any operating system with a container installed. SUMMARY

[0003] Therefore, one or more embodiments of the present specification provide a password acceleration method and device based on password acceleration hardware to solve the problems in the related art.

[0004] To achieve the above-mentioned purpose, one or more embodiments of the present specification provide technical solutions as follows:

[0005] According to a first aspect of one or more embodiments of the present specification, a container image construction method is provided, and the method comprises:

[0006] obtaining an image file used to create a container image;

[0007] cutting the image file into a plurality of file blocks;

[0008] generating a corresponding random symmetric key for each of the plurality of file blocks;

[0009] encrypting each of the plurality of file blocks based on the generated random symmetric key to generate an encrypted container image.

[0010] According to a second aspect of one or more embodiments of the present specification, a container image construction method is provided, and the method comprises:

[0011] obtaining an image file used to create a container image;

[0012] cutting the image file into a plurality of file blocks;

[0013] calculating a hash value corresponding to the plurality of file blocks; and generating a fourth symmetric key based on the hash value and a third symmetric key specified by a user;

[0014] encrypting each of the plurality of file blocks based on the generated fourth symmetric key to generate an encrypted container image.

[0015] According to a third aspect of one or more embodiments of the present specification, a container image building apparatus is provided, the method comprising:

[0016] a file obtaining unit configured to obtain an image file used for creating a container image;

[0017] a file cutting unit configured to cut the image file into a plurality of file blocks;

[0018] a key generating unit configured to generate a corresponding random symmetric key for each of the plurality of file blocks;

[0019] an image generating unit configured to encrypt each of the plurality of file blocks based on the generated random symmetric key to generate an encrypted container image.

[0020] According to a fourth aspect of one or more embodiments of the present specification, a container image building apparatus is provided, the method comprising:

[0021] a file obtaining unit configured to obtain an image file used for creating a container image;

[0022] a file cutting unit configured to cut the image file into a plurality of file blocks;

[0023] a key generating unit configured to calculate a hash value corresponding to the plurality of file blocks, and generate a fourth symmetric key based on the hash value and a third symmetric key specified by a user;

[0024] an image generating unit configured to encrypt each of the plurality of file blocks based on the generated fourth symmetric key to generate an encrypted container image.

[0025] According to a fifth aspect of one or more embodiments of the present specification, a cryptographic co-processor is provided, comprising:

[0026] a processor;

[0027] a memory for storing processor executable instructions;

[0028] wherein the processor implements the method of the first aspect by running the executable instructions.

[0029] According to a sixth aspect of one or more embodiments of the present specification, a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of the first aspect.

[0030] The beneficial effects of the present application are:

[0031] This application divides the image file used to create a container image into several file blocks and generates corresponding random symmetric keys for each file block. The file blocks are then encrypted using these random symmetric keys to generate an encrypted container image. Since the symmetric keys used for encryption are completely randomly generated, they can completely resist offline dictionary attacks, thus improving the security of the container image. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the system architecture of a container image building method provided in an exemplary embodiment.

[0033] Figure 2 This is a flowchart of a container image building method provided in an exemplary embodiment.

[0034] Figure 3 This is an exemplary embodiment of a metadata file structure diagram.

[0035] Figure 4 This is a schematic diagram of a container image building process provided in an exemplary embodiment.

[0036] Figure 5 This is a schematic diagram of another container image building process provided in an exemplary embodiment.

[0037] Figure 6 This is a schematic diagram of a container image deployment process provided in an exemplary embodiment.

[0038] Figure 7 This is a schematic diagram of the structure of an electronic device for container construction, provided as an exemplary embodiment.

[0039] Figure 8 This is a block diagram of a container image building apparatus provided in an exemplary embodiment.

[0040] Figure 9 This is a flowchart of a container image building method provided in an exemplary embodiment.

[0041] Figure 10 This is an exemplary embodiment of a metadata file structure diagram.

[0042] Figure 11 This is a schematic diagram of another container image building process provided in an exemplary embodiment.

[0043] Figure 12 This is a schematic diagram of a container image deployment process provided in an exemplary embodiment.

[0044] Figure 13 This is a schematic diagram of the structure of an electronic device for container construction, provided as an exemplary embodiment.

[0045] Figure 14 This is a block diagram of a container image building apparatus provided in an exemplary embodiment. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

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

[0048] In related technologies, encrypting container image files to generate encrypted container image files typically uses convergent encryption (CE). The convergent encryption key is calculated from the original container image file. Therefore, an attacker can encrypt the container image based on a guess of its plaintext and compare it to the original file, potentially guessing the original file. Furthermore, since any user with access to the original file can calculate the convergent key from its content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks.

[0049] In view of this, this specification proposes a container image building method, which generates a completely random symmetric key during image building and then uses the random symmetric key for encryption.

[0050] In implementation, the image file used to create the container image is obtained and split into several file blocks. A corresponding random symmetric key is generated for each file block, and then each file block is encrypted based on the generated random symmetric key, finally generating an encrypted container image.

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

[0052] In one embodiment, terminals 102, 106, 108, and 110 are all computers. A user can use terminal 102 to create an encrypted container image based on the container building method provided in this specification and upload the container image to the network. Users on other terminals can obtain the container image via the network through terminals 106, 108, 110, etc., and deploy the container image to their own terminals for use.

[0053] The container image building scheme described in this manual will be explained in detail below with reference to the accompanying drawings.

[0054] Please see Figure 2 , Figure 2 This is a flowchart illustrating a container image building method as provided in an exemplary embodiment. For example... Figure 2 As shown, the method may include the following execution steps:

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

[0056] In this embodiment, the image file used to create the container image can be generated from local data files, or a new image file can be generated by adding data files to an existing image file. Users can directly obtain the image file used to create the image via the network, for example, by pulling it directly from an image repository; users can also obtain the container image via the network and then add data files locally to generate the image file. It should be noted that the image file used to create the container image can be a collection of files, for example, a directory of image files pulled from an image repository. In one embodiment, the collection of image files can also be preprocessed, serializing the image files used to create the container image into a single file, which facilitates subsequent splitting processing.

[0057] Step 204: Divide the image file into several file blocks;

[0058] In related technologies, container images are typically managed in layers. The smallest unit that can be shared between different images is a layer within the image. There may be a lot of duplicate data between layers, but even minor differences will be treated as distinct layers. Therefore, to facilitate deduplication of image files, the files can be divided into chunks.

[0059] Since splitting all image files may result in file blocks with identical data, deduplication can be performed on these file blocks. In this embodiment, a hash value can be calculated for each file block using a corresponding hash algorithm, and deduplication can be performed based on the calculated hash value. The hash algorithm can specifically be MD5, SHA, etc., and this invention does not limit this to a specific algorithm.

[0060] In one implementation, the hash value of each file block can be calculated locally, and deduplication 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 file block is retained for data sharing. It should be noted that users can freely set the range of the shared domain; for example, users can choose to retain multiple file blocks with the same hash value, or only one. This invention does not limit this. In one case, users can also set one or more encrypted file blocks as the shared domain. During local deduplication, since the related data and hash values ​​of these file blocks cannot be accessed, file blocks with the same hash value as these encrypted file blocks may appear.

[0061] In another implementation, deduplication can also be performed by a deduplication server based on calculated hash values. Specifically, the hash value of each file block can be calculated locally and sent to the deduplication server via an encrypted connection. The deduplication server matches the hash values ​​of each file block; if the hash values ​​are the same, only one file block is retained for sharing. It should be noted that users can also pre-define the scope of the shared domain. For example, users can set the deduplication server to retain multiple file blocks with the same hash value, or only one; this invention does not limit this. In one case, users can also set one or more encrypted file blocks as the shared domain. The deduplication server does not have permission to obtain the hash values ​​of these file blocks, therefore the deduplication server does not perform deduplication on these hash values, thus file blocks with the same hash values ​​as these encrypted multiple file blocks can appear.

[0062] Users can also send file chunks directly to the deduplication server via an encrypted connection, so that the deduplication server can calculate the hash value of each file chunk and then perform deduplication based on the hash value of the file chunks.

[0063] To further reduce the storage overhead of image files, after the image file is divided into several file blocks, each file block can be compressed, and then the compressed file blocks can be further processed.

[0064] Step 206: Divide the files into blocks and generate corresponding random symmetric keys for each block;

[0065] In related technologies, encrypting container image files to generate encrypted container image files typically uses convergent encryption (CE). The convergent encryption key is calculated from the original container image file. Therefore, an attacker can encrypt the container image based on a guess of its plaintext and compare it to the original file, potentially guessing the original file. Furthermore, since any user with access to the original file can calculate the convergent key from its content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks.

[0066] To resist potential offline dictionary attacks, container images can be encrypted using completely random symmetric keys. In this embodiment, for each file block generated after the image file is split, a corresponding random symmetric key is generated to encrypt the file blocks. Specifically, the random symmetric key can be a parameter used to convert plaintext data into ciphertext. Users can freely choose any random algorithm to generate completely random symmetric keys. Because the symmetric keys are generated completely randomly, attackers cannot crack them using a ciphertext dictionary.

[0067] In one embodiment, completely random symmetric keys can be generated for each deduplicated file block; if deduplication is performed locally, corresponding random symmetric keys can be generated locally for each of the deduplicated file blocks. If deduplication is performed using a deduplication server, the server can generate corresponding random symmetric keys for each deduplicated file block.

[0068] Step 208: Based on the generated random symmetric key, encrypt the file blocks in the plurality of file blocks respectively to generate an encrypted container image.

[0069] In this embodiment, each file block can be encrypted using the randomly generated symmetric key, and then an encrypted container image can be constructed based on the encrypted file blocks. It should be noted that the file blocks can be organized in any way according to user needs to construct the encrypted container image; this invention does not limit this. Because the file blocks are pre-divided and deduplication is performed based on their hash values, the local storage cost of the container image is reduced; and because each file block is encrypted using a completely random symmetric key, it can resist potential offline dictionary attacks, improving the security of the container image.

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

[0071] Metadata files are used to record the metadata corresponding to data files; the metadata indicates the specific storage location of each data file in the container image, and at least one metadata record corresponding to at least one data file can be generated based on the description information corresponding to at least one data file.

[0072] After generating the above-mentioned file blocks, at least one data file can be generated based on at least one file block; and at least one metadata record can be generated based on the description information corresponding to at least one data file. Then, a metadata file can be generated based on at least one metadata record. After generating the above-mentioned 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.

[0073] Please see Figure 3 , Figure 3 This is an exemplary embodiment providing a metadata file structure diagram. For example... Figure 3 As shown, the metadata file can consist of multiple metadata entries; the metadata can consist of multiple descriptive information entries; each descriptive information entry can include the storage locations of multiple file blocks and the random symmetric keys corresponding to the file blocks. In another embodiment, the data format corresponding to the container image can also include a hash database file, which is used to manage the hash values ​​of the file blocks and the random symmetric keys corresponding to the generated file blocks. It should be noted that in the above-mentioned local deduplication-based technical solution, a hash database file is usually required; while in the deduplication-based server-based deduplication solution, the user can freely choose to generate a hash database file or not, and this invention does not limit this.

[0074] After calculating the hash value corresponding to each file block and generating a random symmetric key for that file block, a correspondence between the hash value and the random symmetric key can be established, and this correspondence can be saved to the hash database file. It should be noted that since the random symmetric key is generated completely randomly, the same random symmetric key may correspond to the hash values ​​of multiple file blocks. Therefore, the correspondence between the hash value and the random symmetric key can be multiple hash values ​​corresponding to the same random symmetric key.

[0075] The aforementioned hash database file can be used to deduplicate the hash values ​​of each file block locally when building a container image. During container image building, since local deduplication may be necessary, a symmetric relationship between the hash values ​​of file blocks and random symmetric keys is established and saved to the hash database based on the user-defined shared domain range. The actual hash value of the file block is matched against the hash value stored in the hash database. If the match is consistent, and the user has not pre-defined that the file block does not require deduplication, deduplication is performed accordingly. If the match is inconsistent, a new mapping between the hash values ​​of the file blocks and random symmetric keys is established and saved to the hash database file.

[0076] When building a new container image by adding data files to an existing container image, or when reorganizing and generating new metafiles based on existing container image data files to build a new container image, deduplication using a hash database file is also required. The deduplication method is similar to the local deduplication described above. The system can retrieve the newly added data files corresponding to the encrypted container image; serialize the new data files; and divide the image file into several file blocks of the same size according to the user-preset file block size using a file splitting algorithm. For each file block, a corresponding hash value can be calculated using the appropriate hash algorithm. Based on the hash value corresponding to the file block, it can be matched with the hash value stored in the hash database according to the user-defined shared domain range. If the matching result matches, deduplication is performed accordingly; if the matching result does not match, a new mapping relationship between the hash value of the file block and a random symmetric key is established and saved to the hash database file.

[0077] In another embodiment, to further ensure the security of the container image, the generated metadata file and hash database can be further encrypted, wherein the encryption method can be either symmetric encryption or asymmetric encryption.

[0078] In symmetric encryption, the hash database can be encrypted based on a user-specified first symmetric key, and the metadata file can be encrypted based on a user-specified second symmetric key. It should be noted that the user-specified first symmetric key and the second symmetric key can be the same or different, and this invention does not limit this.

[0079] In asymmetric encryption, the hash database can be encrypted based on the public key of a user-specified first asymmetric key, and the metadata file can be encrypted based on the public key of a user-specified second asymmetric key. It should be noted that the user-specified first asymmetric key and second asymmetric key can be the same or different, and this invention does not limit this.

[0080] Using the methods described above, 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.

[0081] Users can obtain the container image constructed using the above method in any way, such as by downloading it over a network or transmitting it via a secure connection; this invention does not limit this. After obtaining the encrypted container image, the metadata file and at least one data file can be obtained from the container image. The data file includes at least one encrypted file block; the metadata file records at least one piece of metadata, which also stores a random symmetric key corresponding to the encrypted file block. The encrypted file block can be decrypted based on this random symmetric key, and then a file system tree can be constructed based on the metadata file and several file blocks to complete the deployment of the container image.

[0082] In one implementation, to ensure the security of the container image, its metadata files are also encrypted. Therefore, during deployment, a user-provided symmetric or asymmetric key is needed to decrypt the metadata files; specifically, only after decrypting the metadata can the random symmetric key for each file block be obtained, allowing for the decryption of each file block and subsequent deployment operations. In practical applications, the hash database within the container image is also encrypted. Therefore, during deployment, when the hash database is needed, a user-provided symmetric or asymmetric key is required to decrypt the hash database for subsequent deployment operations.

[0083] The above container image building method will be further explained below with reference to the figure and a specific embodiment.

[0084] like Figure 4 As shown, an encrypted container image can include a metadata file, several data files, and a hash database file. Figure 4 The file chunks shown are those generated by cutting the aforementioned image file using a specific file splitting algorithm. After generating the file chunks, a corresponding random symmetric key can be generated for each chunk, and the hash value of each chunk can be calculated. Then, a mapping between the random symmetric key and the hash value of the file chunk is created, and a hash database file is generated based on this mapping. Users can specify either a symmetric key or an asymmetric key to encrypt the hash database file.

[0085] During the generation of the hash database file, the hash values ​​of file blocks can be matched with the hash values ​​stored in the hash database for local deduplication. After the file blocks are deduplicated locally, the file blocks can be selectively compressed, and each file block can be encrypted using the generated random symmetric key. Then, based on the encrypted file blocks, several container image data files can be assembled.

[0086] The descriptive information of the data files and the random symmetric keys corresponding to the aforementioned file blocks can form metadata, which is then used to generate a metadata file. Users can specify either a symmetric or asymmetric key to encrypt the metadata file. After generating the metadata file and several data files, the encrypted container image is built.

[0087] The following is combined Figure 5 The above container image building method will be further explained through another specific embodiment.

[0088] like Figure 5 As shown, an encrypted container image can include metadata files and several data files. Figure 5 The file chunks shown are those generated by cutting the aforementioned image file using a specific file splitting algorithm. After generating the file chunks, a hash value is calculated for each chunk. The hash values ​​of the file chunks are then sent to a deduplication server for deduplication. Once the deduplication server has deduplicated the file chunks, it generates a corresponding random symmetric key. After deduplication by the server, the file chunks can be selectively compressed, and each chunk is encrypted using the generated random symmetric key. These encrypted file chunks can then be used to assemble several container image data files.

[0089] The descriptive information of the data files and the random symmetric keys corresponding to the aforementioned file blocks can form metadata, which is then used to generate a metadata file. Users can specify either a symmetric or asymmetric key to encrypt the metadata file. After generating the metadata file and several data files, the encrypted container image is built.

[0090] It should be noted that in this embodiment, since the hash values ​​of the file blocks are sent to the deduplication server for deduplication, there is no need to perform deduplication locally. Therefore, it is unnecessary to record the correspondence between the hash values ​​of the file blocks and the random symmetric keys, and thus there is no need to generate a hash database file. Users can choose whether to generate a hash database file; this invention does not limit this choice.

[0091] The following is combined Figure 6 The above container image deployment process will be further explained through another specific embodiment.

[0092] like Figure 6As shown, an encrypted container image can include a metadata file and several data files. After obtaining the encrypted container image, the user can decrypt the metadata file using a user-specified symmetric or asymmetric key. The metadata file records multiple metadata entries, including descriptive information describing the specific storage location of the data files within the image, and a random symmetric key for decrypting file blocks. The data files contain several file blocks, which are decrypted using the aforementioned random symmetric key. After decrypting the file blocks, if the file blocks are compressed, they can be decompressed to obtain the original file blocks. Based on the descriptive information in the metadata file and the several file blocks, a file system tree can be constructed to complete the deployment of the container image.

[0093] Figure 7 This is a schematic diagram of an electronic device for container construction, provided as 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, memory 708, and non-volatile memory 710, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into memory 708 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0094] Please refer to Figure 8 , Figure 8 This is a block diagram of a cryptographic acceleration device based on cryptographic acceleration hardware, provided in an exemplary embodiment.

[0095] File acquisition unit 802: Used to acquire the image file used to create the container image;

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

[0097] Key generation unit 806: used to divide the plurality of files into blocks and generate corresponding random symmetric keys for each block;

[0098] Image generation unit 808: used to encrypt the file blocks in the plurality of file blocks based on the generated random symmetric key, so as to generate an encrypted container image.

[0099] 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 is specifically used to encrypt the file blocks in the plurality of file blocks based on the generated random symmetric key, and generate the at least one data file based on the encrypted plurality of file blocks;

[0100] At least one metadata record corresponding to the at least one data file is generated based on the description information corresponding to the at least one data file, and the metadata file is further generated based on the at least one metadata record; wherein, the description information includes the random symmetric key;

[0101] An encrypted container image is generated based on the at least one data file and the metadata file.

[0102] Optionally, the key generation unit 806: specifically calculates the hash value corresponding to the plurality of file blocks; and performs deduplication processing on the plurality of file blocks based on the calculated hash value.

[0103] Optionally, the data format corresponding to the image file further includes a hash database file; the image generation unit 808 is further used to generate at least one hash database file corresponding to the several file blocks based on the correspondence between the hash values ​​of the several file blocks and the random symmetric keys generated for the several file blocks.

[0104] Optionally, the container image building apparatus further includes: a data encryption unit: encrypting the hash database file based on a user-specified first symmetric key; or, encrypting the hash database file based on the public key in a user's first asymmetric key pair.

[0105] Optionally, the container image building apparatus further includes: a data encryption unit: used to encrypt the metadata file based on a second symmetric key specified by the user; or, to encrypt the metadata file based on the public key in a second asymmetric key pair of the user.

[0106] 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.

[0107] Optionally, the container image building apparatus further includes: an image deployment unit: which acquires the generated encrypted container image;

[0108] Obtain the random symmetric key from the metadata file of the encrypted container image;

[0109] Based on the random symmetric key, several file blocks of the encrypted container image's data file are decrypted respectively;

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

[0111] Optionally, the container image device further includes: an incremental deduplication unit: for acquiring newly added data files corresponding to the encrypted container image;

[0112] The newly added data file is divided into several file blocks, and the hash values ​​corresponding to the several file blocks are calculated;

[0113] The hash values ​​corresponding to the file blocks are matched with the hash values ​​stored in the hash database file to remove duplicates.

[0114] Please see Figure 9 , Figure 9 This is a flowchart illustrating a container image building method as provided in an exemplary embodiment. For example... Figure 8 As shown, the method may include the following execution steps:

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

[0116] In this embodiment, the image file used to create the container image can be generated by a virtual machine based on the original operating system, or a new image file can be generated by adding data files to an existing image file. Users can directly obtain the image file used to create the image via the network; for example, they can pull it directly from an image repository, or they can generate the image file locally using a virtual machine. Users can also obtain the container image via the network and add data files locally to generate the image file. It should be noted that the image file used to create the container image can be a collection of files, for example, a directory of image files pulled from an image repository. In one embodiment, the collection of image files can also be preprocessed, serializing the image files used to create the container image into a single file, which facilitates subsequent splitting processing.

[0117] Step 904: Cut the image file into several file blocks;

[0118] In related technologies, container images are typically managed in layers. The smallest unit that can be shared between different images is a layer within the image. There may be a lot of duplicate data between layers, but even minor differences will be treated as distinct layers. Therefore, to facilitate deduplication of image files, the files can be divided into chunks.

[0119] In this embodiment, the image file used to create the container image can be serialized. Based on the file block size preset by the user, the image file is divided into several file blocks of the same size using a file splitting algorithm. File blocks typically store less data, occupy less storage space, are easy to manage, and are easy to deduplicatize.

[0120] Since splitting all image files may result in file blocks with identical data, deduplication can be performed on these file blocks. In this embodiment, a hash value can be calculated for each file block using a corresponding hash algorithm, and deduplication can be performed based on the calculated hash value. The hash algorithm can specifically be MD5, SHA, etc., and this invention does not limit this to a specific algorithm.

[0121] In one implementation, the hash value of each file block can be calculated locally, and deduplication 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 file block is retained for data sharing. It should be noted that users can freely set the range of the shared domain; for example, users can choose to retain multiple file blocks with the same hash value, or only one. This invention does not limit this. In one case, users can also set one or more encrypted file blocks as the shared domain. During local deduplication, since the related data and hash values ​​of these file blocks cannot be accessed, file blocks with the same hash value as these encrypted file blocks may appear.

[0122] To further reduce the storage overhead of image files, after the image file is divided into several file blocks, each file block can be compressed, and then the compressed file blocks can be further processed.

[0123] Step 906: Calculate the hash values ​​corresponding to the file blocks; generate a fourth symmetric key based on the hash values ​​and the third symmetric key specified by the user;

[0124] In related technologies, encrypting container image files to generate encrypted container image files typically uses convergent encryption (CE). The convergent encryption key is calculated from the original container image file. Therefore, an attacker can encrypt the container image based on a guess of its plaintext and compare it to the original file, potentially guessing the original file. Furthermore, since any user with access to the original file can calculate the convergent key from its content and then encrypt the image file, this makes the image file vulnerable to offline dictionary attacks.

[0125] To resist potential offline dictionary attacks, a fourth symmetric key can be generated by calculating the hash value of the file blocks and a user-specified third symmetric key. This fourth symmetric key is then used to encrypt the container image. Since the third symmetric key can be any key specified by the user, it cannot be cracked by brute force or by using a ciphertext dictionary after being calculated with the hash value of the file blocks themselves.

[0126] In this embodiment, for the several file blocks generated after the image file is split, a fourth symmetric key is generated by calculating the hash value of the file block and a third symmetric key specified by the user, and this fourth symmetric key is used to encrypt the several file blocks. Specifically, the fourth symmetric key can be a parameter used to convert plaintext data into ciphertext data. The calculation can be performed in various ways to calculate the fourth symmetric key from the hash value and the third symmetric key specified by the user; this invention does not limit this method. For example, the calculation can specifically be an XOR operation.

[0127] In one embodiment, a fourth symmetric key can be generated by calculating the hash value of the deduplicated file blocks and the third symmetric key specified by the user; if deduplication is performed locally, a corresponding fourth symmetric key can be generated locally for each of the deduplicated file blocks.

[0128] Step 908: Based on the generated fourth symmetric key, encrypt the file blocks in the plurality of file blocks respectively to generate an encrypted container image.

[0129] In this embodiment, each file block can be encrypted using the generated fourth symmetric key, and then an encrypted container image can be constructed based on the encrypted file blocks. It should be noted that the file blocks can be organized in any way according to user needs to construct the encrypted container image; this invention does not limit this. Because the file blocks are pre-divided and deduplication is performed based on their hash values, the local storage cost of the container image is reduced. Since each file block is encrypted using the fourth symmetric key, which is calculated from the hash value of the file block itself and the user-specified third symmetric key, it can resist potential offline dictionary attacks, thus improving the security of the container image.

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

[0131] Metadata files are used to record the metadata corresponding to data files; the metadata indicates the specific storage location of each data file in the container image, and at least one metadata record corresponding to at least one data file can be generated based on the description information corresponding to at least one data file.

[0132] Please see Figure 10 , Figure 10 This is an exemplary embodiment providing a metadata file structure diagram. For example... Figure 10 As shown, the metadata file can consist of multiple metadata entries; the metadata can consist of multiple descriptive information entries; each descriptive information entry can include the storage location of multiple file blocks and the hash value corresponding to the file block.

[0133] After generating the aforementioned file blocks, at least one data file can be generated based on at least one file block; and at least one metadata record can be generated based on the description information corresponding to the at least one data file. Then, a metadata file is generated based on the at least one metadata record. After generating the at least one data file and the metadata file, an encrypted container image can be generated based on the at least one data file and the metadata file. In another embodiment, to further ensure the security of the container image, the generated metadata file can be further encrypted, wherein the encryption method can be either symmetric encryption or asymmetric encryption.

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

[0135] Using the methods described above, 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.

[0136] Users can obtain the container image constructed using the above method in any way, such as by downloading from the network, transmitting via a secure connection, etc., and this invention does not limit this. After obtaining the encrypted container image, the metadata file and at least one data file in the container image can be obtained. The data file includes at least one encrypted file block. The metadata file records at least one piece of metadata, which also stores the hash value corresponding to the encrypted file block. A fourth symmetric key can be calculated based on the hash value and a third symmetric key specified by the user. Then, the encrypted file block is decrypted based on the fourth symmetric key. Finally, a file system tree is constructed based on the metadata file and several file blocks to complete the deployment of the container image.

[0137] In one implementation, to ensure the security of the container image, its metadata files and hash database files are also encrypted. Therefore, during deployment, a symmetric key or asymmetric key provided by the user is needed to decrypt the metadata files. Only after decrypting the metadata files can the hash value of each file block be obtained. Then, a fourth symmetric key can be calculated based on the hash value and a third symmetric key specified by the user, and subsequently, the file blocks can be decrypted for subsequent deployment operations.

[0138] The following is combined Figure 11 The above container image building method will be further explained through another specific embodiment.

[0139] like Figure 11 As shown, an encrypted container image can include metadata files and several data files. Figure 11 The file chunks shown are those generated by cutting the aforementioned image file using a specific file splitting algorithm. After generating the file chunks, a hash value is calculated for each chunk. A symmetric key for encrypting the file chunks is calculated based on the hash value of each chunk and a user-specified random symmetric key. Then, the chunks can be deduplicated based on the hash values. Deduplication can be performed locally. After deduplication, the file chunks can be selectively compressed, and each chunk is encrypted using the generated symmetric key. The encrypted file chunks can then be used to assemble several container image data files.

[0140] The descriptive information of the data files and the hash values ​​corresponding to the aforementioned file blocks can form metadata, which is then used to generate a metadata file. Users 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.

[0141] The following is combined Figure 12 The above container image deployment process will be further explained through another specific embodiment.

[0142] like Figure 12As shown, an encrypted container image can include a metadata file and several data files. After obtaining the encrypted container image, the user can decrypt the metadata file using a user-specified symmetric or asymmetric key. The metadata file records multiple metadata entries, including descriptive information describing the specific storage location of the data files within the image, and hash values ​​of the file blocks. The user can use the specified symmetric key and the hash values ​​of the file blocks to generate a symmetric key for decryption. The data files include several file blocks, which are decrypted using the generated symmetric key. After decrypting the file blocks, if the file blocks are compressed, they can be decompressed to obtain the original file blocks. Based on the descriptive information of the metadata file and the several file blocks, a file system tree can be constructed to complete the deployment of the container image.

[0143] Figure 13 This is a schematic diagram of an electronic device for container construction, provided as 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, memory 1308, and non-volatile memory 1310, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in 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 implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0144] Please refer to Figure 14 , Figure 14 This is a block diagram of a cryptographic acceleration device based on cryptographic acceleration hardware, provided in an exemplary embodiment.

[0145] File acquisition unit 1402: Used to acquire the image file used to create the container image;

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

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

[0148] Image generation unit 1408: used to encrypt the file blocks in the plurality of file blocks based on the generated random symmetric key, so as to generate an encrypted container image.

[0149] 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 is specifically used to encrypt the file blocks in the plurality of file blocks based on the generated fourth symmetric key to generate an encrypted container image.

[0150] At least one metadata record corresponding to the at least one data file is generated based on the description information corresponding to the at least one data file, and the metadata file is further generated based on the at least one metadata record; wherein, the description information includes the hash value of the file block.

[0151] An encrypted container image is generated based on the at least one data file and the metadata file.

[0152] Optionally, the key generation unit 1406 performs deduplication processing on the plurality of file blocks based on the calculated hash value.

[0153] Optionally, the container image building apparatus further includes: a data encryption unit: encrypting the metadata file based on a user-specified fifth symmetric key; or,

[0154] The metadata file is encrypted using the public key from the user's third asymmetric key pair.

[0155] Optionally, the container image building apparatus further includes: an image deployment unit: which acquires the generated encrypted container image;

[0156] Retrieve the generated encrypted container image;

[0157] Obtain the hash value from the metadata file of the encrypted container image;

[0158] A fourth symmetric key is generated based on the hash value and the third symmetric key specified by the user.

[0159] Based on the fourth symmetric key, several file blocks of the encrypted container image's data file are decrypted respectively;

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

[0161] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

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

[0163] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0164] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0165] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0166] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0167] 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 scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

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

[0169] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for building a container image, the method comprising: Obtain the image file used to create the container image; The image file is cut into several file blocks; The files are divided into blocks, and corresponding random symmetric keys are generated for each block. The random symmetric keys are symmetric keys that are generated by any random algorithm selected by the user and are independent of the content of the file blocks and are completely random. Based on the generated random symmetric key, the file blocks in the plurality of file blocks are encrypted respectively to generate an encrypted container image.

2. The method according to claim 1, wherein 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 within the plurality of file blocks based on the generated random symmetric key to generate an encrypted container image includes: Based on the generated random symmetric key, the file blocks in the plurality of file blocks are encrypted respectively, and the at least one data file is generated based on the encrypted file blocks; At least one metadata record corresponding to the at least one data file is generated based on the description information corresponding to the at least one data file, and the metadata file is further generated based on the at least one metadata record; wherein, the description information includes the random symmetric key; An encrypted container image is generated based on the at least one data file and the metadata file.

3. The method according to claim 1, wherein 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 aforementioned file blocks; Based on the calculated hash value, deduplication is performed on the several file blocks.

4. The method according to claim 3, wherein the deduplication process for the plurality of file blocks based on the calculated hash value includes: Based on the calculated hash value, the several file blocks are deduplicated locally; or, The hash value is sent to a deduplication server, which then performs deduplication processing on the hash value based on the calculated hash value.

5. The method according to claim 3, wherein 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 file blocks and the random symmetric keys generated for the file blocks; Generate at least one hash database file corresponding to the aforementioned file blocks.

6. The method of claim 5, further comprising any of the following: The hash database file is encrypted based on a user-specified first symmetric key; or... The hash database file is encrypted using the public key from the user's first asymmetric key pair.

7. The method of claim 2, further comprising any of the following: The metadata file is encrypted using a second symmetric key specified by the user; or... The metadata file is encrypted using the public key from the user's second asymmetric key pair.

8. The method according to claim 2, further comprising: Retrieve the generated encrypted container image; Obtain the random symmetric key from the metadata file of the encrypted container image; Based on the random symmetric key, several file blocks of the encrypted container image's data file are decrypted respectively; A file system tree is constructed based on the metadata file and the decrypted files to complete the deployment of the container image.

9. The method according to claim 5, further comprising: Obtain the newly added data file corresponding to the encrypted container image; The newly added data file is divided into several file blocks, and the hash values ​​corresponding to the several file blocks are calculated; The hash values ​​corresponding to the file blocks are matched with the hash values ​​stored in the hash database file to remove duplicates.

10. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-9 by executing the executable instructions.

11. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-9.

Images