Method and apparatus for encryption key management for optimal information-theoretic security

Abstract

A method, apparatus, and computer program product for managing multiple encryption keys using a key vault seed that defines a set of seed bits. A key management process defines a key mapping between the set of seed bits and the multiple encryption keys. The key management process enables each encryption key to be generated from the set of seed bits using corresponding key material values and the key mapping. The key mapping specifies generating an encryption key by splitting the seed bits into multiple seed bit partitions, determining a key value from the key material value, determining a key sequence using the multiple seed bit partitions and the key value, and determining the encryption key from the key sequence. Indirect management through the key vault seed and the key management process simplifies the management of a large number of encryption keys.

Description

[0001] Cross - Reference to Related Applications

[0002] This patent application claims the priority of U.S. Provisional Patent Application 62 / 853,081, filed on May 27, 2019, the entire content of which is incorporated herein by reference.

[0003] Field

[0004] Embodiments of the present invention generally relate to data protection and encryption, and more particularly, to methods and computer program products for generating and managing encryption keys.

[0005] Preamble

[0006] The following does not admit that any of the content discussed below is part of the prior art or part of the common general knowledge of a person skilled in the art.

[0007] As people become more and more dependent on computing and Internet technologies, data security has become more important than ever. With the popularity of Internet connectivity, it has become relatively easy to widely access and distribute data. To enjoy the benefits of cloud computing, people and companies upload their data to cloud servers, which often includes private or confidential data, or any data that users may need to protect, which increases the chance of private and important data being unnecessarily exposed without protection.

[0008] Cloud storage may have many associated security vulnerabilities. For example, security threats in cloud computing may include data leakage, data loss, malicious insiders, and shared technology issues. One way to mitigate data security problems is through encryption. For example, files can be encrypted before being saved and stored, uploaded, and / or transmitted. Without the corresponding decryption key, getting the encrypted file is meaningless.

[0009] Key management (the management of encryption and decryption keys) plays a fundamental role in cryptographic systems. Appropriate key management is the basis for ensuring the security of cryptographic technologies to provide confidentiality, authentication, data source authentication, data integrity, and digital signatures (see, for example, A.J. Menezes, P.C. van Oorschot, and S.A. Vanstone, Handbook of Applied Cryptography. CRC Press, 1996). A secure key management process should provide techniques and procedures to support the establishment and maintenance of the confidentiality of key material and keys among authorized parties.

[0010] Data on the public cloud needs to be stored for a long time, and a large number of legitimate users will also access the stored data frequently. To protect confidentiality, the data can be encrypted before being uploaded to the cloud. For example, a secure symmetric cipher such as the Advanced Encryption Standard (AES) (see, e.g., Advanced Encryption Standard (AES). Federal Information Processing Standards (FIPS) Publication 197, United States National Institute of Standards and Technology (NIST), 2001) can be used to encrypt and decrypt the data. Due to the long-term storage of the data and the frequent access, it is best to use a separate random key for each file to encrypt it, which provides higher security against various attacks such as ciphertext attacks and known / selected plaintext attacks (see, e.g., A.J. Menezes, P.C. van Oorschot, and S.A. Vanstone, Handbook of Applied Cryptography. CRC Press, 1996).

[0011] However, as the number of encrypted files increases, the list of random keys also increases accordingly. Since the encrypted files stored in the cloud usually need to support access by legitimate users at any time in the future, the keys and key materials need to be securely maintained to ensure the security and accessibility of the data, especially any keys and key materials cannot be deleted. Similarly, these encrypted files usually need to be accessed by different legitimate users through different devices. However, the list of random keys may grow to contain millions or hundreds of millions of keys. Therefore, it becomes increasingly difficult to securely generate, distribute, and maintain such a list of random keys. This problem can be loosely referred to as the key management problem. Compared with traditional secure communication encryption applications, cloud data security makes the key management problem more challenging. Summary of the Invention

[0012] The following introduction is provided to introduce the reader to the more detailed discussion that follows. It is introduced for the purpose of not limiting or defining any invention claimed or not yet claimed. One or more inventions may exist in any combination or sub-combination of the elements or process steps disclosed in any part of this document, including its claims and diagrams.

[0013] The present disclosure provides methods, apparatuses, and computer program products that can be used to manage multiple cryptographic keys. A large number of random encryption / decryption keys can be securely generated, distributed, and maintained while managing a relatively small number of shared secret bits (referred to as a key store seed). A key management process can be defined to provide a key mapping between the key store seed and the multiple cryptographic keys. The key store seed defines a set of seed bits, which are secret bits that can be shared between devices. The key mapping can be defined to easily determine each cryptographic key from the set of seed bits and a key value corresponding to the cryptographic key. The key management process can be defined to provide a particular level of data security. Using the key management process described herein, a large number of cryptographic keys can be managed by managing a single key store seed, thereby simplifying the key management process while maintaining a high level of data security.

[0014] In accordance with this broad aspect, a method for managing multiple encryption keys using at least one computing device is provided, each computing device having a processor and a non-transitory memory. The method includes storing a key vault seed in the non-transitory memory of a particular computing device among the at least one computing device, generating each of the multiple encryption keys using the key vault seed, wherein the key vault seed defines a set of seed bits having a plurality of seed bits, the plurality of seed bits in the set of seed bits being independently and identically distributed, wherein each encryption key is defined by a plurality of key bits, the encryption key having a specified key length, the specified key length being the same for each encryption key, the specified key length defining the number of key bits in the plurality of key bits, wherein the set of seed bits has a set bit length, and the set bit length specifies the number of seed bits in the set of seed bits, the set bit length being at least twice the specified key length; determining, by a processor of the particular computing device, a key management process that defines a key mapping between the set of seed bits and the multiple encryption keys, wherein the processor of the particular computing device can use the key management process to generate each of the multiple encryption keys from the set of seed bits and a key material value corresponding to the encryption key through the key mapping; storing key management instructions corresponding to the key management process in the particular computing device memory, wherein the key management instructions are executable by the processor of the particular computing device to generate any particular one of the multiple encryption keys by: dividing the set of seed bits into a plurality of seed bit partitions, wherein the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on a ratio between the number of seed bits in the set of seed bits and the number of key bits, wherein the partition value is an integer and is at least equal to the ratio between the number of seed bits in the set of seed bits and the number of key bits; determining a key value from a key material value corresponding to the specified encryption key; using the plurality of seed bit partitions and the key value to determine a key sequence, wherein the key sequence includes a plurality of sets of key sequence bits, each set of key sequence bits corresponding to a seed bit partition; and determining an encryption key from the key sequence, wherein the encryption key can be used by at least one processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

[0015] In some examples, the key sequence can be determined by multiplying each seed bit partition by a corresponding exponent of the key value, and each set of key sequence bits may correspond to a product of a seed bit partition and a different exponent of the key value.

[0016] In some examples, the encryption key can be determined by bitwise addition of multiple sets of key sequence bits in the key sequence.

[0017] In some examples, the partition length of each seed bit partition may be equal to the specified key length, so that the number of seed bits in each seed bit partition is equal to the number of key bits.

[0018] In some examples, the key management process may specify that the key value is defined as the key material value.

[0019] In some examples, the key management process may specify determining the encryption key from the key sequence, including: determining a key sequence output from the key sequence, where the key sequence output is determined by bitwise addition of the multiple sets of key sequence bits in the key sequence; inputting the key sequence output into a symmetric encryption cipher to determine the encryption key, where the symmetric encryption cipher is configured and the ciphertext key sequence is generated using the key sequence output; and determining the encryption key as the ciphertext key sequence.

[0020] In some examples, the key management process may specify that the key value is determined as follows: inputting the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate the ciphertext key material using the key material value; and determining the key value as the ciphertext key material value.

[0021] In some examples, the method may include identifying a file to be encrypted; generating a file encryption key by randomly selecting a specific key material value; using the key management process to determine a specific key value from the specific key material value; using the key management process to determine a specific key sequence from the multiple seed bit partitions and the specific key value; using the key management process to determine the file encryption key from the specific key sequence; generating an encrypted file by: applying an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cryptographic key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cryptographic key of the encryption cipher; and generating the encrypted file from the ciphertext file.

[0022] In some examples, the encrypted file may include the ciphertext file and the file key material corresponding to the specific key material value.

[0023] In some examples, the method may include identifying a given encrypted file to be decrypted; determining a given key material value corresponding to the given encrypted file; using the key management process to determine a given key value from the given key material value; using the key management process to determine a given key sequence from the plurality of seed bit partitions and the given key value; using the key management process to generate a file decryption key from the given key sequence; generating a decrypted file by applying a decryption cipher to the given encrypted file to generate a plaintext file, wherein the decryption cipher uses a decryption cipher key to generate the plaintext file, and when the decryption cipher is applied to the given encrypted file, the file decryption key is used as the decryption cipher key for the decryption cipher.

[0024] In some examples, determining the given key material value corresponding to the given encrypted file may include extracting the given key material value from the encrypted file.

[0025] In some examples, the length of the set of seed bits may be at least three times the specified key length, and the length of the set of seed bits may be an integer multiple of the specified key length.

[0026] In some examples, the key store seed defines an initial set of initial seed bits, wherein the initial set of initial seed bits has a length less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of initial seed bits such that the combined length of the initial set of initial seed bits and the appended zeros is equal to the length of the set of seed bits.

[0027] In some examples, the method may include securely transmitting the key management instructions and the key store seed to a plurality of different computing devices, wherein the key management instructions and the key store seed enable each different computing device to generate each encryption key of the plurality of encryption keys.

[0028] In accordance with this broad aspect, a computer program product for managing multiple encryption keys is also provided. The computer program product includes a computer-readable medium storing computer-executable instructions for configuring a processor of a computing device to perform the following: Store a key vault seed in the non-transitory memory of the computing device, where the key vault seed can be used to generate each of the multiple encryption keys. The key vault seed defines a set of seed bits having a plurality of seed bits, and the plurality of seed bits in the set of seed bits are independently and identically distributed. Each encryption key is defined by a plurality of key bits, and the encryption key has a specified key length, which is the same for each encryption key. The specified key length defines the number of key bits in the plurality of key bits. The set of seed bits has a seed bit set length that specifies the number of seed bits in the set of seed bits, and the seed bit set length is at least twice the specified key length. Determine a key management process that defines a key mapping between the set of seed bits and the multiple encryption keys. The key management process is used by the processor to generate each of the multiple encryption keys from the set of seed bits by using the key mapping and a key material value corresponding to the encryption key. Store key management instructions corresponding to the key management process in a specific computing device memory, where the key management instructions are executable by a processor of the specific computing device to generate any specific one of the multiple encryption keys by the following method: Divide the set of seed bits into a plurality of seed bit partitions, where the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on the ratio between the number of seed bits and the number of key bits in the set of seed bits. The partition value is an integer and is at least equal to the ratio between the number of seed bits and the number of key bits in the set of seed bits. Determine a key value from the key material value corresponding to the specific encryption key. Use the plurality of seed bit partitions and the key value to determine a key sequence, where the key sequence includes a plurality of sets of key sequence bits, and each set of key sequence bits corresponds to a seed bit partition. Determine an encryption key from the key sequence, where the encryption key can be used by the processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

[0029] In some examples, the key management instructions can be defined to configure the processor to determine the key sequence by multiplying each seed bit partition by a corresponding exponent of the key value, where each set of key sequence bits corresponds to the product of a seed bit partition and a different exponent of the key value.

[0030] In some examples, the key management instruction may be defined to configure the processor to determine the encryption key according to the bitwise addition of the multiple key sequence bit sets in the key sequence.

[0031] In some examples, the key management instruction may be defined to configure the processor to define each seed bit partition, where each seed bit partition has a partition length equal to the specified key length, such that the number of seed bits in each seed bit partition is equal to the number of key bits.

[0032] In some examples, the key management process may specify that the key value is defined as the key material value.

[0033] In some examples, the key management instruction may be defined to configure the processor to determine the encryption key from the key sequence in the following manner: determine a key sequence output from the key sequence, where the key sequence output is determined by the bitwise addition of the multiple key sequence bit sets in the key sequence; determine the encryption key by: inputting the key sequence output into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key sequence using the key sequence output; and determine the encryption key as the ciphertext key sequence.

[0034] In some examples, the key management instruction is defined to configure the processor to determine the key value in the following manner: input the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key material value using the key material value; and determine the key value as the ciphertext key material value.

[0035] In some examples, a computer program product may further include instructions to configure the processor to identify a file to be encrypted; the key management instruction is defined to configure the processor to generate a file encryption key by randomly selecting a specific key material value; use the key management process to determine a specific key value from the specific key material value; use the key management process to determine a specific key sequence from multiple seed bit partitions and the specific key value; use the key management process to determine the file encryption key from the specific key sequence; generate an encrypted file by: applying an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cryptographic key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cryptographic key of the encryption cipher; and generate the encrypted file from the ciphertext file.

[0036] In some examples, the encrypted file may include the ciphertext file and the file key material corresponding to the specific key material value.

[0037] In some examples, the computer program product may further include instructions for configuring the processor to identify a given encrypted file to be decrypted; the key management instructions may be defined to configure the processor to determine a given key material value corresponding to the given encrypted file; using the key management process, determine a given key value from the given key material value; using the key management process, determine a given key sequence with the plurality of seed bit partitions and the given key value; using the key management process, generate a file decryption key from the given key sequence; generate a decrypted file by applying a decryption cipher to the given encrypted file to generate a plaintext file, wherein the decryption cipher uses a decryption cipher key to generate the plaintext file, and when the decryption cipher is applied to the given encrypted file, the file decryption key is used as the decryption cipher key of the decryption cipher.

[0038] In some examples of the computer program product, determining the given key material value corresponding to the given encrypted file may include extracting the given key material value from the encrypted file.

[0039] In some examples of the computer program product, the length of the set of seed bits may be at least three times the specified key length, and the length of the set of seed bits may be an integer multiple of the specified key length.

[0040] In some examples of the computer program product, the key store seed may define an initial set of seed bits, wherein the initial set of seed bits has an initial set length less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of seed bits such that the combined length of the initial set of seed bits and the appended zeros is equal to the length of the set of seed bits.

[0041] In some examples, the computer program product may further include instructions for configuring the processor to securely transmit the key management instructions and the key store seed to a plurality of different computing devices, wherein the key management instructions and the key store seed enable each different computing device to generate each encryption key of the plurality of encryption keys.

[0042] In accordance with this broad aspect, there is also provided an apparatus for managing a plurality of encryption keys, the apparatus comprising: a processor; and a non-transitory apparatus memory having stored thereon instructions that configure the processor to perform the following: Store a key vault seed in the non-transitory apparatus memory, the key vault seed being usable to generate each of the plurality of encryption keys, wherein the key vault seed defines a set of seed bits having a plurality of seed bits, the plurality of seed bits in the set of seed bits being independently and identically distributed, wherein each encryption key is defined by a plurality of key bits, the encryption key having a specified key length, the specified key length being the same for each encryption key, the specified key length defining the number of key bits in the plurality of key bits, wherein the set of seed bits has a set of seed bit length, the set of seed bit length specifying the number of seed bits in the set of seed bits, the set of seed bit length being at least twice the specified key length; Determine a key management process that defines a key mapping between the set of seed bits and the plurality of encryption keys, wherein the key management process is usable by the processor to generate each of the plurality of encryption keys from the set of seed bits by using the key mapping and a key material value corresponding to the encryption key; Store key management instructions corresponding to the key management process in the non-transitory apparatus memory, wherein the key management instructions are executable by the processor to generate any particular one of the plurality of encryption keys by: Partitioning the set of seed bits into a plurality of seed bit partitions, wherein the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on a ratio between the number of seed bits in the set of seed bits and the number of key bits, wherein the partition value is an integer and is at least equal to the ratio between the number of seed bits in the set of seed bits and the number of key bits; Determining a key value from the key material value corresponding to the particular encryption key; Using the plurality of seed bit partitions and the key value to determine a key sequence, wherein the key sequence comprises a plurality of sets of key sequence bits, each set of key sequence bits corresponding to a seed bit partition; Determining an encryption key from the key sequence, wherein the encryption key is usable by the processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

[0043] In some examples, the key management instructions stored in the non-transitory apparatus memory are defined to configure the processor to determine the key sequence by multiplying each seed bit partition by a respective exponent of the key value, wherein each set of key sequence bits corresponds to a product of a seed bit partition and a different exponent of the key value.

[0044] In some examples, the key management instructions stored in the non-transitory device memory are defined to configure the processor to determine the encryption key based on the bitwise addition of the plurality of key sequence bit sets in the key sequence.

[0045] In some examples, the key management instructions stored in the non-transitory device memory are defined to configure the processor to define each seed bit partition, where each seed bit partition has a partition length equal to the specified key length, such that the number of seed bits in each seed bit partition is equal to the number of key bits.

[0046] In some examples, the key management process may specify that the key value is defined as the key material value.

[0047] In some examples, the key management instructions stored in the non-transitory device memory are defined to configure the processor to determine the encryption key from the key sequence in the following manner: determine a key sequence output from the key sequence, where the key sequence output is determined by the bitwise addition of the plurality of key sequence bit sets in the key sequence; determine the encryption key by: inputting the key sequence output into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key sequence using the key sequence output; and determine the encryption key as the ciphertext key sequence.

[0048] In some examples, the key management instructions stored in the non-transitory device memory are defined to configure the processor to determine the key value in the following manner: input the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key material value using the key material value; and determine the key value as the ciphertext key material value.

[0049] In some examples, the instructions stored in the non-transitory device memory are defined to configure the processor to identify a file to be encrypted; the key management instructions stored in the non-transitory device memory are defined to configure the processor to generate a file encryption key by randomly selecting a specific key material value; use the key management process to determine a specific key value from the specific key material value; use the key management process to determine a specific key sequence from the multiple seed bit partitions and the specific key value; use the key management process to determine the file encryption key from the specific key sequence; and generate an encrypted file by: applying an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cryptographic key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cryptographic key of the encryption cipher; generating the encrypted file from the ciphertext file.

[0050] In some examples, the encrypted file may include the ciphertext file and the file key material corresponding to the specific key material value.

[0051] In some examples, the instructions stored in the non-transitory device memory are defined to configure the processor to identify a given encrypted file to be decrypted; the key management instructions stored in the non-transitory device memory are defined to configure the processor to determine a given key material value corresponding to the given encrypted file; use the key management process to determine a given key value from the given key material value; use the key management process to determine a given key sequence using the multiple seed bit partitions and the given key value; use the key management process to generate a file decryption key from the given key sequence; generate a decrypted file by applying a decryption cipher to the given encrypted file to generate a plaintext file, where the decryption cipher uses a decryption cryptographic key to generate the plaintext file, and when the decryption cipher is applied to the given encrypted file, the file decryption key is used as the decryption cryptographic key of the decryption cipher.

[0052] In some examples of the device for managing the multiple encryption keys, determining the given key material value corresponding to the given encrypted file includes extracting the given key material value from the encrypted file.

[0053] In certain examples of the device for managing multiple encryption keys, the length of the set of seed bits may be at least three times the specified key length, and the length of the set of seed bits may be an integer multiple of the specified key length.

[0054] In some examples of a device that manages multiple encryption keys, the key vault seed defines an initial set of seed bits, where the initial set of seed bits has an initial set length that is less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of seed bits such that the combined length of the initial set of seed bits and the appended zeros is equal to the length of the set of seed bits.

[0055] In some examples, the instructions stored in the non-transitory device memory are defined to configure the processor to securely transmit the key management instructions and the key vault seed to a plurality of different computing devices, where the key management instructions and the key vault seed enable each different computing device to generate each of the plurality of encryption keys.

[0056] Those skilled in the art will understand that the devices, methods, or computer program products disclosed herein may include any one or more functions, and these functions can be used in any specific combination or sub-combination.

[0057] These and other aspects and features of the various embodiments will be described in more detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The accompanying drawings included herein are used to illustrate various examples of the systems, methods, and devices described herein and are not intended to limit the scope of the subject matter in any way.

[0059] Figure 1 is a block diagram illustrating an example computer system that, according to one embodiment, can be used to provide encryption key generation and management for one or more computing devices.

[0060] Figure 2 is a block diagram illustrating an example computing device that, according to one embodiment, can be used with Figure 1 the example system.

[0061] Figure 3 is a flowchart illustrating an example key management process according to one embodiment.

[0062] DESCRIPTION OF EXAMPLE EMBODIMENTS

[0063] The purpose of providing the accompanying drawings is to illustrate, rather than limit, the aspects and features of the various examples of the embodiments described herein. For simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. For clarity, the dimensions of some elements may be exaggerated relative to other elements. It is to be understood that, for simplicity and clarity of illustration, reference numerals of the drawings may be repeated in the drawings where considered appropriate to indicate corresponding or similar elements or steps.

[0064] In addition, many specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it is to be understood that the embodiments described herein may be practiced even without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Further, the description is not to be regarded as limiting the scope of the embodiments described herein.

[0065] The following presents various systems or methods to provide examples of embodiments of the claimed subject matter. The embodiments described below do not limit any of the claimed subject matter, and any claimed subject matter may cover methods or systems different from those described below. The claimed subject matter is not limited to systems or methods having all of the features of any one of the systems or methods described below, nor to features common to multiple or all of the described devices or methods. It is possible that the systems or methods described below are not the embodiments recited in any of the claimed subject matter. Any subject matter disclosed in the systems or methods described below but not claimed in this document may be the subject of another protective instrument, such as a continuing patent application, and by disclosing any such subject matter in this document, the applicant, inventor, or owner does not intend to abandon, disclaim, or dedicate them to the public.

[0066] Terms such as "an embodiment", "embodiment", "multiple embodiments", "this embodiment", "these embodiments", "one or more embodiments", "some embodiments", and "an embodiment" mean "one or more (but not all) embodiments of the present invention" unless otherwise expressly stated.

[0067] It should be noted that degree terms such as "substantially", "approximately", and "about" used herein mean a reasonable deviation of the modified term, such that the end result will not vary significantly. If such a deviation does not negate the meaning of the modified term, these degree terms may also be construed to include the deviation of the modified term.

[0068] In addition, any numerical range recited by endpoints includes all integers and fractions within that range (e.g., 1 to 5 includes 1, 1.5, 2, 2.75, 3, 3.90, 4, and 5). It is also to be understood that all integers and fractions are assumed to be modified by the term "substantially", which means that the recited numbers may vary by a certain amount if the end result does not vary significantly.

[0069] Example embodiments of the systems and methods described herein may be implemented by a combination of hardware and software. In some cases, implementing the example embodiments described herein is at least partially accomplished by using one or more computer programs, executed on one or more programmable devices that include at least one processing unit, and using data storage elements (including volatile memory, non-transitory memory, storage elements, or any combination thereof). These devices may also have at least one input device (such as a button keyboard, mouse, touch screen, etc.) and at least one output device (such as a display screen, printer, radio device, etc.), depending on the nature of the device.

[0070] It should also be noted that some elements may be used to implement at least some of the embodiments described herein, and these embodiments may be implemented by software written in a high-level computer programming language (such as object-oriented programming). Thus, the program code may be written in C, C++, or any other suitable programming language, and may include modules or classes, which are well known to those skilled in object-oriented programming. In addition, some elements implemented by software may also be written in assembly language, machine language, or firmware as needed. In either case, the program language may be a compiled or interpreted language.

[0071] At least some software programs may be stored on a storage medium (such as a computer-readable medium, such as but not limited to, ROM, disk, optical disc) or a device readable by a general or special-purpose programmable device. When the software program code is read on the programmable device, the programmable device may be configured to operate in a new, specific, and predefined manner to perform at least one of the methods described herein.

[0072] In addition, at least some programs related to the systems and methods of the embodiments described herein may be capable of being distributed in a computer program product that includes a computer-readable medium containing computer instructions available on one or more processors. The medium may be provided in various forms, including non-transitory forms, such as but not limited to, one or more disks, optical discs, magnetic tapes, chips, and magnetic and electronic memories.

[0073] A computer program is a set of instructions that can be executed by a computer (i.e., a processor). A process is an instance of a program, i.e., a copy of the program in a computer's memory that is ready to be executed by the computer's central processing unit (CPU). In the following discussion, reference will be made to the processor of a computer system and the operations performed by the computer system processor. It should be understood that such references include one or more processing units and the use of one or more processing units to perform operations, such as one or more processing cores in one or more CPUs.

[0074] In a computer or computer system, data files are used to store information. When information is stored in a directly readable / understandable manner (i.e., not scrambled or otherwise encoded to prevent direct understanding of the information), the data file can be referred to as plaintext (e.g., a plaintext file). In some cases, the data file may be modified (i.e., encrypted) to prevent unauthorized access to the plaintext information stored in the data file.

[0075] Encryption is a process of using a secret (encryption key) to convert information (i.e., plaintext) into a scrambled format (which can be referred to as ciphertext). A file storing information in encrypted form can be called a ciphertext file. Decryption is the reverse process of encryption, using a secret (such as the encryption key or a different decryption key, depending on the encryption method used) to convert the ciphertext into plaintext.

[0076] The embodiments described herein are generally related to the management of multiple encryption / decryption keys. In particular, the embodiments described herein relate to the management of multiple encryption keys that can be used for secure symmetric encryption ciphers. The embodiments described herein may provide systems, methods, devices, and computer program products that enable a large number of encryption keys to be securely generated, distributed, and maintained while only managing a limited number of secret bits. The embodiments described herein are conducive to the long-term storage of data while maintaining a high level of data security.

[0077] The embodiments described herein can provide encryption key management for symmetric encryption ciphers. A symmetric cipher can be configured to receive a plaintext data file and use an encryption key to generate a corresponding ciphertext file. The symmetric cipher can also be used to receive a ciphertext file and use the same encryption key to generate a corresponding plaintext data file (the encryption key in this operation can be referred to as a decryption key).

[0078] The embodiments described herein can be configured to manage multiple encryption keys. These encryption keys can be referred to herein as a key vault and / or a set of keys and / or a set of random keys. The key vault can be represented herein by the symbol Ψ, and an individual key is represented by the symbol k (also referred to as an encryption key and / or a decryption key).

[0079] An encryption cipher can be defined to operate using an encryption key with a specified key length. The specified key length (also referred to herein as the key length and / or the number of key bits) is represented herein by the symbol l, and each of the multiple encryption keys can be defined as having the same specified key length.

[0080] In a key store (i.e., multiple encryption keys), an individual encryption key can be identified based on a key index value and / or a key material value. For example, in this case, the key material value can also be referred to as the index of a specific key in the key store. The key material value can be used to determine a key derivation value or a key value that can be used to generate the corresponding encryption key. In some cases, the key material value may even be the key value itself. The key material value is represented herein by the symbol w. Given the i-th file, its specific key material value is represented herein by X i . The set of all key indices of the key store (also referred to as the set of key material values of the key store) is represented by the symbol Ω.

[0081] The multiple encryption keys can include a large number of encryption keys. The number of encryption keys in the multiple encryption keys is represented by the symbol Λ. The number of encryption keys in the multiple encryption keys (and the symbol Λ) can be referred to herein as the size of the key store and / or the number of keys in the key store and / or the number of key index values in the key store and / or the number of independent key material values.

[0082] The embodiments described herein can facilitate the management of multiple encryption keys by managing a key store seed, which defines a set of secret bits that can be referred to herein as the set of seed bits. The multiple seed bits in the set of seed bits are independent and identically distributed (IID) (i.e., uniformly randomly distributed). The set of seed bits can be used to generate each key in the multiple encryption keys (in other words, the key store seed can be used to generate each key in the key store). The key store seed is represented herein by the symbol K.

[0083] The size of the key store seed may be much smaller than the number of encryption keys in the multiple encryption keys. That is, the size of the set of seed bits (i.e., the number of seed bits in the set of seed bits) may be less than the size of the key store (i.e., the number of keys in the key store). The size of the key store seed is represented herein by the symbol L. The size of the key store seed can also be referred to as the number of shared secret bits and / or the number of bits of the key store seed and / or the number of seed bits of the set of seed bits.

[0084] A key management process can be determined to manage the multiple encryption keys. The key management process can define a function and / or a sequence of operations to generate the multiple encryption keys. The key management process is represented herein by the symbol G.

[0085] A key management process may specify a key mapping between a set of seed bits and a plurality of encryption keys. The key mapping can be used to generate any (i.e., each) of the plurality of encryption keys from the set of seed bits. For a particular encryption key of the plurality of encryption keys, the key mapping can specify how to generate this particular encryption key from the set of seed bits using a key material value corresponding to the encryption key. By using the key management process and the set of seed bits, a large number of encryption keys can be securely managed and distributed in a concise manner.

[0086] The embodiments described herein provide an encryption key management process, wherein for any key material value, the corresponding encryption key has a set of randomly and uniformly distributed key bits, and thus, the information leakage of the corresponding encryption key for a randomly selected key material value is zero.

[0087] The embodiments described herein provide an encryption key management process, wherein for any pair of different key material values, the difference between the corresponding pair of encryption keys is randomly and uniformly distributed.

[0088] The embodiments described herein provide an encryption key management process, wherein the conversion from a key store seed to a corresponding key store preserves the same amount of secret information.

[0089] The embodiments described herein provide an encryption key management process, wherein for any pair of different key material values, knowing the encryption key corresponding to the first key material value does not significantly reduce the uncertainty of the encryption key corresponding to the second key material value.

[0090] The embodiments described herein also provide an example of a key management process that can be defined to prevent a reconstruction attack.

[0091] Now refer to Figure 1 , which shows an example of a system 100 that, according to one embodiment, can be used to generate and manage encryption keys. In some embodiments, the system 100 forms part of a security system that can implement automatic encryption and decryption of data files on various authorized computing devices 105A - 105N.

[0092] The devices 105 within the system 100 can be configured to operate according to a specified key management process. The key management process can enable each device 105 to generate an encryption key using a stored key vault seed. The key vault seed can be stored by each device 105 as a set of secret bits. For example, on each device 105, the key vault seed can be stored in an encrypted manner. The encryption key can be used for symmetric encryption to encrypt and decrypt data files, which allows the device 105 to create, access, and share encrypted data files, and / or store and access encrypted data files stored on the remote storage device 115, while preventing unauthorized devices 120 from accessing the plaintext data.

[0093] Generally, the computing device 105 includes a processor, volatile and non-transitory memory, at least one network interface, and input / output devices. The computing device 105 may include a server computer, a desktop computer, a laptop computer, a tablet computer, a PDA, a smartphone, or other programmable computers. The computing device 105 may also include any device or "smart" device capable of making a data communication connection, such as a thermostat, an air quality sensor, an industrial device, etc. As more and more devices are connected to the Internet of Things, the computing devices include an increasing variety of devices. Examples of the computing device 105 will be described in further detail with reference to Figure 2 be described in further detail.

[0094] The computing device 105 may include a connection to the network 110, such as a wired or wireless connection to the Internet. The network 110 can be constructed by one or more computer network technologies, such as IEEE 802.3 (Ethernet), IEEE 802.11, and similar technologies.

[0095] Through the network 110, the computing device 105 can be connected to the remote storage device 115, such as a cloud server. The remote storage device 115 may include one or more server computers that are connected to the computing device 105 using a network such as the Internet. The remote storage device 115 generally includes a processor, volatile and non-transitory memory, and at least one network interface, and can provide data storage services for authorized computing devices 105. The data stored on the remote storage device 115 can be accessed by the computing device 105 using the network 110.

[0096] Existing key management technology precedents include PGP-like solutions (see P. Zimmermann, PGP Source Code and Internals, MIT Press, 1995), where keys are distributed in ciphertext form together with the encrypted file (i.e., the key is encrypted with the recipient's public key), and key derivation-like solutions, where keys are derived from a secret value (such as a master key, password, etc.) and a random value (see M. Bezzi, et al., Data privacy, in J. Camenisch, editor, Privacy and Identity Management for Life, Springer, 2011). In the former case, although the keys for different files can be independent in theory, from an information-theoretic perspective, distributing keys in the form of public-key encryption discloses all information about them (since the attacker can also access the public key). In the latter case, the keys derived for different files may be highly correlated, and each derived key may also be related to the corresponding random value, so disclosing the random value also discloses information about the key. To improve data security, these deficiencies force users to adopt a private key with a shorter lifespan and a secret value for generating encryption keys. Therefore, these technologies are not particularly suitable for large-scale key management and / or applications that require long-term data protection.

[0097] The embodiments described herein can provide systems and methods for key generation and management, solving some key management problems from an information-theoretic perspective. In the embodiments described herein, systems and methods can be defined to operate a shared secret K of L random bits between legitimate parties (such as authorized device 105). The systems and methods described herein can be defined to operate under the condition that an adversary (such as unauthorized device 120) can observe the same information as each legitimate recipient (such as authorized device 105) except for the shared secret K (the shared secret is unknown to the adversary). The systems and methods described herein can be defined to operate using an underlying secure symmetric cipher (such as AES), where the secure symmetric cipher uses a key of key length l.

[0098] The systems and methods for key generation and management described herein can be defined as a process of securely (from an information-theoretic perspective) generating, distributing, and maintaining Λ (Λ is a large number) random encryption keys of key length l using a secure symmetric cipher. The embodiments described herein can be configured to operate under the practical limitation that a user can manage a relatively small number L of bits of the shared secret bit K, where the number of shared secret bits is much lower than the number of random encryption keys (e.g., L << Λ ≤ 2 l )

[0099] Define a set of key indices Ω corresponding to the shared secret bits, whose cardinality is equal to the number of random encryption keys Λ. The elements of the set of key indices Ω can serve as the key indices (also referred to as key material values) of the encryption keys for multiple encryption keys. Determine a key management process G that defines a mapping between the shared secret bits (i.e., the set of seed bits) and multiple encryption keys (e.g., G: {0,1} L ×Ω → {0,1} l ). Define a key management process such that for each key index value in the set of key indices (i.e., each ω ∈ Ω), the corresponding encryption key can be simply calculated from the set of seed bits K and the key index value ω (i.e., k(ω) = G(K, ω)). Thus, by distributing the key index value ω, the corresponding encryption key k(ω) is implicitly distributed, and thus, maintaining a large set of keys Ψ = {k(ω): ω ∈ Ω} can be reduced to maintaining the shared secret K.

[0100] The systems and methods described herein can be defined without making any assumptions about the computational resources of an adversary. The embodiments described herein can be configured to provide a key management process that uses a key management concept referred to herein as information-theoretic β-security, which is designed to address the challenges associated with the secure generation, distribution, and maintenance of a large and growing list of random keys. This application also provides a key management framework in which information-theoretic β-secure key management processes can be designed, analyzed, and compared.

[0101] In the embodiments described herein, information-theoretic β-security can be used to measure the security of the key management process G, and the key management process G described herein can be defined as information-theoretically β-secure. As used herein, a key management process can be considered information-theoretically β-secure if:

[0102] · For any key index value ω ∈ Ω, the key bits in the corresponding encryption key k(ω) are random and uniformly distributed over {0,1} l . Thus, distributing a randomly selected key index value ω results in zero information leakage about the corresponding key k(ω);

[0103] · For any pair of distinct key index values ω1, ω2 ∈ Ω, the difference between the corresponding encryption keys (i.e., the difference between k(ω1) and k(ω2)) is random and uniformly distributed over {0,1} l ;

[0104] · The transformation from the key bank seed to the key bank (i.e., the transformation K → Ψ) preserves the same total amount of secret information;

[0105] · For any independent key index values knowing the first encryption key corresponding to the first key index value will not significantly reduce the uncertainty of the second encryption key k(X n+1 ) corresponding to the second key index value. In other words, the conditional Shannon entropy of the second encryption key given the second key index value and the first encryption key is at most greater than the conditional Shannon entropy of the second encryption key given only the second key index value by a minimum value β n , that is, where H(X|Y) is the conditional Shannon entropy of X given Y, and for small n, β n is close to 1.

[0106] The embodiments described herein can define an information-theoretic β-secure method to increase the strength against attacks. A specific example of a key management process (referred to herein as G * ) is described here, a practical information-theoretic β-secure key management, and in addition, different instances of key management processes that can prevent reconstruction attacks are introduced.

[0107] As Figure 3 shown, the key management process 200 (i.e., G) defined herein can be configured to generate a plurality of encryption keys, including a large number Λ of random keys. Each encryption key has a specified key length l. The plurality of encryption keys together constitute a set Ψ called a key repository. A shared secret K (also referred to as a key repository seed) can be provided to any authorized user. The shared secret can define a set of seed bits, including a specified number L of seed bits. The key material index Ω can be defined as a set of key indices or a set of key materials, and the set cardinality is equal to the number of keys Λ in the plurality of encryption keys. The number of seed bits can be much smaller than the number of keys Λ in the plurality of encryption keys (i.e., L << Λ ≤ 2 l ). Each key material value in the set of key materials Ω can be used as the key material for the corresponding encryption key, and each key material value is represented by bits.

[0108] Given any key material value ω ∈ Ω, the corresponding (random) encryption key k(ω) can be generated from the shared secret K (i.e., the set of seed bits) using the key management process G, denoted as k(ω) = G(K, ω). Accordingly, the key repository generated by the key management process G from the key repository seed K can be defined as

[0109] Ψ = {k(ω): ω ∈ Ω}

[0110] where the key material value ω can also be referred to as a key index value.

[0111] When an unencrypted file (e.g., a plaintext file) is encrypted at 204, a key material value ω can be selected from the set of key materials Ω. Then, the key mapping defined by the key management process G can be used to generate a corresponding encryption key k(ω) from the set of seed bits K and the key material value at 202a. This operation is equivalent to randomly selecting an encryption key k(ω) from the key store Ψ. Then, the generated k(ω) can be used as the encryption key to encrypt the file at 204 through the underlying symmetric cipher (i.e., generate ciphertext data).

[0112] The key material value (or key index value) ω can be included in the encrypted file together with the ciphertext. The key material value ω and the ciphertext together define the encrypted file. For example, the key material value can be inserted into the header of the ciphertext. After receiving the encrypted file at 206, the legitimate recipient (e.g., the authorized device 105) can determine the key material value based on the received encrypted file. The authorized device 105 can use the key mapping at 202b to extract the key k(ω) from the set of seed bits K and the key material value ω. Then, the derived key k(ω) can be used to decrypt the ciphertext at 206. Generally speaking, as described herein, the term "file" can be understood to represent "message", "plaintext", or more generally a piece of information / data, unless otherwise specified (e.g., when a file is specified as encrypted or ciphertext).

[0113] Now refer to Figure 2 , which shows an example of a computing device 105X that can be used to generate and manage encryption keys according to an embodiment. Generally speaking, the computing device 105X illustrates more details of the computing device 105 related to the authorized users of the system 100. The details of the example computing device 105X can generally be extended to Figure 1 the other computing devices 105 shown in. Examples of the computing device 105 may include programmable general-purpose computers, audio / video encoding and playback devices, set-top TV boxes, television broadcast devices, and mobile devices, etc.

[0114] The computing device 105X generally includes a processor 104, a memory 106, a display device 108, a database 116, and a communication interface 112. Although the database 116 is shown as a separate element, it can be understood to be stored in the memory 106.

[0115] The processor 104 is a computer processor, such as a general-purpose microprocessor. In other cases, the processor 104 can be a programmable gate array, an application-specific integrated circuit, a microcontroller, or other suitable computer processors.

[0116] Processor 104 is connected to memory 106 via a computer data bus. Memory 106 may include volatile memory and non-transitory storage devices. The non-transitory memory stores a computer program consisting of computer-executable instructions, which may be loaded into the volatile memory for execution by processor 104 as needed. Those skilled in the art will understand that when it is mentioned that computing device 105 performs a function or operates in a specific manner, it means that processor 104 is executing instructions (such as a software program) stored in memory 106 and may transmit or receive inputs and outputs through one or more interfaces. Memory 106 may also store data inputs or outputs in processor 104 during the execution of computer-executable instructions. As described above, memory 106 may also store database 116.

[0117] Processor 104 is also connected to display device 108 and can output information and data according to the needs of various computer programs. In particular, display 108 can display a graphical user interface (GUI). In some cases, display device 108 may be omitted from computing device 105, for example, when computing device 105 is a sensor or other intelligent device configured to operate autonomously. Computing device 105 can run an operating system such as Microsoft Windows, GNU / Linux, or other suitable operating systems.

[0118] In some example embodiments, database 116 is a relational database. In other embodiments, database 116 may be a non-relational database, such as a key-value database, a NoSQL database, etc.

[0119] Communication interface 112 is one or more data network interfaces, such as IEEE 802.3 or IEEE 802.11 interfaces, for network communication.

[0120] Processor 104 can operate according to instructions provided in an application program stored in memory 106. As used herein, the term "software application" or "application program" refers to computer-executable instructions, particularly computer-executable instructions stored in a non-transitory medium (such as non-transitory memory) and executed by a computer processor. When the computer processor executes the instructions, it may receive inputs and transmit outputs to various input or output devices to which it is connected.

[0121] Computing device 105X may store a software application called encryption application 114. Although shown separately, encryption application 114 can also be understood to be stored in storage device 106.

[0122] Each computing device 105 (or at least each authorized computing device) may have an encryption application 114 installed thereon. The encryption application 114 installed on each device 105 may be responsible for encryption and decryption operations on the device 105. The encryption application 114 may be configured to determine a key management process for generating and managing encryption keys.

[0123] For example, the encryption application 114 may be configured to generate encryption / decryption keys according to the determined key management process. The encryption application 114 may be defined to protect the generated keys. The encryption application 114 may also store one or more key vault seeds and / or generate one or more key vault seeds on each device 105, and these key vault seeds may be stored on each device 105. According to the key management process, the encryption application 114 may use the key vault seeds to generate one or more encryption / decryption keys.

[0124] The encryption application 114 may be used to generate key vault seeds, which, as will be described in detail below, are used to derive keys according to the key management process. For example, the key vault seeds used on device 105 may be shared and / or synchronized with other authorized devices 105, as described in U.S. Patent No. 9,619,667 (titled "METHODS, SYSTEMS AND COMPUTER PROGRAM PRODUCT FOR PROVIDING ENCRYPTION ON A PLURALITY OF DEVICES"). Synchronizing the key vault seeds between different devices 105 may enable different devices to communicate in ciphertext between the devices 105 in a secure manner while still facilitating the decryption of encrypted and ciphertext files. The encryption application 114 may be configured to securely transfer the key vault seeds to a plurality of different computing devices 105. The encryption application 114 may also be configured to securely transfer key management instructions to a plurality of different computing devices 105. The key management instructions and the key vault seeds may enable each different computing device 105 to generate each of the plurality of encryption keys.

[0125] In some cases, a user may wish to move encrypted files / ciphertext from a first device 105A to a second device 105B and / or to a remote storage device 115. The user may use a cloud service, a telecommunications network, or other file transfer mechanisms (such as a USB or Firewire key) to transfer one or more encrypted files / ciphertext from the first device 105A to the second device 105B. Once the second device 105B receives the encrypted files, it may be necessary to decrypt these files on the second device 105B.

[0126] To allow an encrypted file / ciphertext encrypted by the encryption application 114 on the first device 105A to be decrypted by the encryption application 114 on the second device 105B, the keystore seeds used by the encryption application 114 on the first device 105A and the second device 105B need to be synchronized manually or automatically. Thus, the encryption application 114 on the second device 105B can use the keystore seed and key information (such as key material values) transmitted together with the received file to determine the encryption key required for decrypting the received file according to a determined key management process. In addition, since the amount of interaction information between the key information and the encryption key is zero, the key information and the encryption key are statistically independent, so the data is secure from the perspective of anti-cracking during transmission, that is, an attacker can be prevented from determining the encryption key only from the transmitted ciphertext and key information.

[0127] In some cases, the encryption application 114 can be configured to generate a large number of encryption keys from the keystore seed, that is, an encryption key store. However, as described above, it may be undesirable or cumbersome for the computing device 105 to generate and store a large number of encryption keys (for example, the storage capacity of the device 105 is limited). Therefore, the device 105 can only store the keystore seed and then derive the encryption key from the keystore seed as needed using the key management process.

[0128] The encryption key and / or the keystore seed can be stored in the non-transitory storage device 106 in an encrypted format, and the encryption key and / or the keystore seed can be protected by a user-defined verification code. In some embodiments, only the user knows the verification code, and local authentication information can be generated based on the verification code and stored on the device 105. The authentication information can be used to authenticate a user who attempts to access or modify the encrypted file. In some cases, the verification code may not be determinable from any stored authentication information. For more details on securely storing the encryption key and the keystore seed using the verification code, see U.S. Patent No. 9,619,667, titled "METHODS, SYSTEMS AND COMPUTER PROGRAM PRODUCT FOR PROVIDING ENCRYPTION ON A PLURALITY OF DEVICES".

[0129] When the data managed by the example systems described herein is stored in non-transitory memory, it may always remain encrypted, whether on the authorized device 105 or on other devices such as the remote storage device 115. In some examples, the encryption application 114 may be configured to generate encryption / decryption keys as needed. For example, the encryption application 114 does not store any encryption keys in the non-transitory memory of the device 105. In this case, the encryption keys may be temporarily stored in the volatile memory of the device 105 and then discarded after the encryption and / or decryption process is complete.

[0130] Figure 3 Illustrates an example of a key management process 200 that the encryption application 114 may use. Figure 3 The key management process 200 shown in may be an example of the key management process G briefly described above.

[0131] In the key management process G, the symbol X i is used to represent the random key material value selected for encrypting the i-th file. The set of key material values may be defined as a series of independent and identically distributed (IID) random key material variables, and each individual key material value X i is uniformly distributed over the set of key material values Ω.

[0132] As the number of encrypted files increases, the list of random keys required to individually encrypt all these files is k(X1), k(X2), …, k(X n ), where n represents the total number of files encrypted. Using the key management process G, for each encryption key k(X i ), 1 ≤ i ≤ n, it can be implicitly distributed by distributing its corresponding key material value or key index value X i .

[0133] The key management process G can be defined such that each key material value X i and the corresponding encryption key k(X i ) are statistically independent, so that the mutual information I(X i ; k(X i )) between each key material value X i and the corresponding encryption key k(X i ) is zero. Therefore, the information leakage of the key material value X i to the actual key k(X i ) is zero.

[0134] In addition, the key management process G can be defined such that it is required that the key bits of each encryption key are in {0,1} lUniformly distributed, all key bits of all encryption keys must be significantly different from the key bits of all other encryption keys among multiple encryption keys. Accidentally leaking one or more encryption keys does not provide an advantage for unauthorized users to attack other encryption keys. These properties can be defined as the requirements that the key management process providing information-theoretic β-security to be further described below needs to satisfy.

[0135] Using the key management process G described herein, each encryption key k(X i ) can be calculated according to the set of seed bits defined by the key store seed K and the key derivation value (also called the key value) corresponding to the key material value / key index value X i . Accordingly, device 105 actually does not need to store the key store Ψ (that is, it does not need to store all encryption keys among multiple encryption keys). Therefore, using the information-theoretic β-secure key management process G described herein, it is possible to manage a large and growing list of random keys by managing the set of seed bits of a single key store seed K, which greatly reduces or alleviates the challenges brought by key management for long-term data protection.

[0136] Given the key length l of each encryption key, the number L of specified seed bits in the set of seed bits satisfies L≥2l, and the number Λ of encryption keys among multiple encryption keys (satisfying L << Λ ≤ 2 l ), many different implementation schemes of the information-theoretic β-secure key management process can be defined. The following details an example of the key management process that can provide optimal information-theoretic β-security.

[0137] Define the key store seed entropy value f as the lower limit of the ratio of the number of specified seed bits to the specified key length (i.e., ), it can be proved that the information-theoretic β-secure key management process G is optimal if and only if for any different key material values ω1, ω2, …, ω f , ω f+1 in the set of key material values Ω, the corresponding multiple encryption key sets k(ω1), k(ω2), …, k(ω f ) are independently and identically distributed (IID), and the joint entropy of the corresponding multiple encryption key sets k(ω1), k(ω2), …, k(ω f+1 ) is equal to the key store seed length L. A specific example G of an optimal information-theoretic β-security is described herein * , and an example process variant that can further prevent reconstruction attacks is further described.

[0138] Since Shannon's work on perfect secrecy (see C. Shannon, "Communication theory of secrecy systems," Bell System Technical Journal, 28(4): 656–715, 1949), information-theoretic methods have been mainly applied to ensuring communication security under various often unrealistic assumptions (see U. Maurer, "Conditionally-perfect secrecy and a provably-secure randomised cipher," Journal of Cryptology, 5(1): 53-66, 1992; U. Maurer, "Secret key agreement by public discussion from common information," IEEE Trans. Inform. Theory, 39(3): 733–742, 1993; R. Ahlswede and I. Csiszár, "Common randomness in information theory and cryptography–Part I: secret sharing," IEEE Trans. Inform. Theory, 39(4): 1121–1132, 1993; A. D. Wyner, "The wire-tap channel," Bell Syst. Tech. J., 54(8): 1355–1387, 1975; C. Fragouli, V. M. Prabhakaran, L. Czap, and S. N. Diggavi, "Wireless network security: building on erasures," Proceedings of the IEEE, 103(10): 1826–1840, 2015; and their references). Shannon has shown that perfect secrecy can be achieved only when the entropy of the cryptographic key is greater than or equal to the entropy of the plaintext, which implies the perfect secrecy of the one-time pad (see C. Shannon, "Communication theory of secrecy systems," Bell System Technical Journal, 28(4): 656–715, 1949).When an adversary is restricted to certain types of attacks, it has been shown that, if designed properly, a random cipher can achieve perfect secrecy with high probability using a key that is much shorter than the plaintext (see U. Maurer, “Conditionally-perfect secrecy and a provably-secure randomised cipher,” Journal of Cryptology, 5(1):53-66, 1992). However, a random cipher implies the existence of a very long publicly accessible random bit string, which is much longer than the plaintext bit string. Secret sharing has been studied from an information-theoretic perspective, with an emphasis on determining the key capacity, assuming that the sender and receiver each observe different but correlated sources (see U. Maurer, “Secret key agreement by public discussion from common information,” IEEE Trans. Inform. Theory, 39(3):733–742, 1993; and R. Ahlswede and I. Csiszár, “Common randomness in information theory and cryptography–Part I: secret sharing,” IEEE Trans. Inform. Theory, 39(4):1121–1132, 1993). On the other hand, in the wiretap channel model (see A. D. Wyner, “The wire-tap channel,” Bell Syst. Tech. J., 54(8):1355–1387, 1975), the adversary is assumed to observe information different from that of the legitimate receiver through a different channel, and these models often focus on determining the secrecy capacity. Some recent approaches to wireless network security also make similar assumptions (see C. Fragouli, V. M. Prabhakaran, L. Czap, and S. N. Diggavi, “Wireless network security: building on erasures,” Proceedings of the IEEE, 103(10):1826–1840, 2015), but none of these approaches can address the challenge of maintaining the secrecy of a large number of random keys even after these keys have been securely distributed to legitimate parties (such as authorized device 105).

[0139] In contrast, the embodiments described herein provide systems and methods for addressing key management challenges using information theoretic approaches. In particular, the embodiments described herein can be configured to operate in situations where a user or device can only handle a limited number of secrets (i.e., a limited number of secret bits), which is of course the case in practical applications compared to theoretical applications that may allow for an unbounded number of secrets. Thus, the embodiments described herein can be configured to solve the method of securely generating, distributing, and maintaining a growing list of random keys in practical applications. The inventors have previously described some examples of information-theoretically secure key management processes (see E.-H. Yang and X.-W. Wu, “Information-Theoretically Secure Key Generation and Management,” in Proc. of the 2017 IEEE International Symposium on Information Theory (ISIT 2017), Aachen, Germany, June 25 - 30, 2017, pp. 1529 - 1533; and E.-H. Yang, “Methods and computer program products for encryption key generation and management,” US Patent No 9,703,979, July 11, 2017).

[0140] In the following description, Section 2 formally defines the concept of information-theoretic β-secure key management, defines how to determine an optimal information-theoretic β-secure key management process, and establishes some general bounds on information-theoretic β-secure key management. Section 3 describes examples of optimal information-theoretic β-secure key management processes and explains in detail a particular optimal information-theoretic β-secure key management process G * . Section 4 describes example variants of G * and secure symmetric ciphers that can be used to protect the key vault seed from so-called reconstruction attacks.

[0141] Section 2 – Information-Theoretic β-Secure Key Management

[0142] As described above, the embodiments described herein can be defined as operating using an encryption key of key length l, where each encryption key is defined by a plurality of key bits. The encryption keys have a specified key length l, and the key length of each encryption key is the same. The specified key length defines the number of key bits in the key bits for each encryption key.

[0143] The embodiments described herein may use a key vault seed that defines a set of seed bits. The set of seed bits may be defined with a set-of-seed-bits length L that specifies the number of seed bits in the set of seed bits. The set-of-seed-bits length may be defined as at least twice the specified key length (i.e., L ≥ 2l). The embodiments described herein may be configured to use an encryption key (Λ keys) among a plurality of encryption keys, where Λ is much larger than the set-of-seed-bits length but not more than 2 to the l (l being the key length) power (i.e., L << Λ ≤ 2 l )

[0144] As described above, the set of key indices Ω may be defined as a set consisting of a number of key material values equal to the number of encryption keys Λ, where each key material value represents or corresponds to a key index value or a key derivation value / key value.

[0145] K is a shared secret (or key vault seed) that may be stored in the non-transitory memory 106 of one or more computing devices 105 (e.g., via the encryption application 114). The key vault seed is used to generate each of the plurality of encryption keys. The key vault seed defines a set of seed bits having a large number of seed bits, e.g., a set of seed bits having L random bits. The key vault seed K defines the set of seed bits as a sequence of seed bits:

[0146] K = K(0)K(1)…K(L - 1)

[0147] where the seed bits K(i) in the set of seed bits, i = 0, 1, …, L - 1, are independently and identically distributed over {0, 1}, and each seed bit has an equal probability of being 0 or 1, i.e.,

[0148] Pr{K(i) = 0} = Pr{K(i) = 1} = 1 / 2

[0149] Accordingly, the seed bits in the set of seed bits will be described herein as uniformly random.

[0150] Definition 1

[0151] Referring to Figure 3 , the computing device 105 may be configured to determine a key management process G (e.g., using the encryption application 114). The key management process may define a key mapping between the set of seed bits and the plurality of encryption keys (i.e., {0, 1} L × Ω to {0, 1} l )

[0152] The processor 104 of the computing device 105 can generate each of a plurality of encryption keys using a key management process. The key management process can specify how to generate each encryption key from a set of seed bits using a key mapping and a key material value corresponding to the encryption key.

[0153] The key management process G can be used for key management in different ways. The key management process can be used to generate each encryption key among a plurality of encryption keys. The key management process can specify how to generate each encryption key from a set of seed bits using a key mapping and a key material value corresponding to the encryption key.

[0154] For example, the key management process can be used to provide encryption for one or more plaintext files, as shown in 204. The encryption application 114 can identify the plaintext file to be encrypted, and then, the encryption application 114 can generate an encryption key for the identified file, as shown in 202a.

[0155] The encryption application 114 can randomly select a key material value, and then, the encryption application 114 can use the key management process G to determine a key value from the specific key material value. The key value can be used to generate an encryption key from the seed bits stored in the device 105. For example, the key value can be the key material value itself and / or another value derived or determined from the key material value.

[0156] For example, when a file is to be encrypted, a key material value ω can be randomly selected from the set of key material values Ω, and then, a corresponding key can be generated from the selected key material value. For example, the key indexed by ω can be generated as k(ω) = G(K, ω).

[0157] The encryption application 114 can be used to generate an encrypted file by applying an encryption cipher to the identified file to generate a ciphertext file. The encryption cipher can be a symmetric cipher defined as using a cipher key to generate the ciphertext file. The generated encryption key k(ω) can be used as the cipher key. When the encryption cipher is applied to the file, the ciphertext file is generated from the plaintext file through its underlying symmetric cipher, and then, the encrypted file can be generated using the ciphertext file. For example, the encrypted file may include the ciphertext file and the file key material (key information) corresponding to the specific key material value used to generate the encryption key k(ω).

[0158] As another example, the key management process can be used to provide key distribution to multiple devices. The encryption key k(ω) can be implicitly distributed to all legitimate parties (authorized devices 105) using the corresponding key material value. The key material value (such as the key index ω) can be included in the ciphertext file to form the encrypted file together. For example, the key material value can be inserted into the header of the ciphertext, and the file key material corresponding to the key material value and the ciphertext file together constitute the encrypted file.

[0159] The key management process can also be used to provide decryption, as shown at 206. The encryption application 114 can identify the encrypted file to be decrypted. The encrypted file can come from different places, such as stored on the device 105, received from another device 105, and / or stored on a remote storage device 115.

[0160] The encryption application 114 can determine the key material value corresponding to the encrypted file. In some cases, the key material value can be extracted from the encrypted file. For example, the encrypted file is formed by the key material value together with the ciphertext file.

[0161] Using the key management process, the key value can be determined with the key material value. For example, the key value can be the key material value and / or a value derived or determined from the key material value.

[0162] The encryption application 114 can determine the decryption key at 202b according to the key value and the set of seed bits stored on the device 105. The encryption application 114 can extract or derive the key k(ω) from the key vault seed K using the key value corresponding to the key material value ω. Then, the key k(ω) can be used to decrypt the ciphertext of the encrypted file.

[0163] The encryption application 114 can be configured to generate a decrypted file by applying a decryption password to the encrypted file to obtain a plaintext file. The decryption password can operate using the same symmetric encryption password as used for the encrypted file. The decryption password can use a decryption password key to generate the plaintext file. When the decryption password is applied to the encrypted file, the encryption application can use the key k(ω) as the key of the decryption password.

[0164] As another example, the key management process can be used to provide the maintenance of encryption keys. The list of available random keys is defined as the key vault Ψ:

[0165] Ψ = {k(ω) = G(K, ω): ω ∈ Ω}.

[0166] The key vault defines a set of encryption keys with multiple encryption keys. Maintaining the confidentiality of this large list of keys can be simplified to maintaining the confidentiality of a single key vault seed K (i.e., maintaining the confidentiality of the set of seed bits).

[0167] As described above, in the embodiments described herein, the cardinality Λ of the set of key indices Ω is no more than 2 to the power of l (i.e., 2 1 , where l is the specified key length). Since each key has a specified key length l, given the key vault seed K, the maximum number of different keys can be defined as no more than 2 l . In addition, each key material value can be defined with a key bit length that is at least the logarithm of the number of encryption keys (i.e., it is required bits are required to represent each element ω ∈ Ω in Ω).

[0168] In the embodiments described herein, the key material value ω can be distributed to legitimate parties (i.e., authorized devices 105). Correspondingly, an unnecessarily large cardinality Λ of the key index set will increase the resulting transmission overhead. Taking the underlying symmetric cipher AES256 as an example, depending on the specific application, the typical value of the key index set size Λ (i.e., the number of encryption keys among multiple encryption keys) can be defined as 2 53 to 2 256 , while the size L of the seed bit set can be as small as 2 12 , that is to say, the size of the seed bit set may be much smaller than the number of encryption keys that can be generated from this seed bit set (e.g., at least 2 41 times in some examples).

[0169] Denote the specific key material value ω ∈ Ω selected for encrypting the i-th file by X i . As described above, multiple key material values are independently and identically distributed, and thus are independently and identically distributed. The process evaluation value can be defined as a series of non-increasing numbers, satisfying 0 ≤ β n ≤ 1, n = 1, 2, … and

[0170]

[0171] For small values of n, β n can be defined as close to 1. To make the key management process embodiments described herein (key management processes conforming to Definition 1) both practical and secure, each key k(ω) needs to be simply calculated based on the key repository seed K and the corresponding key material value ω, and G needs to be information-theoretically β-secure, as defined below.

[0172] Definition 2

[0173] In the embodiments described herein, when the following four properties are satisfied, a key management process G is information-theoretically β-secure:

[0174] Property 1 of Definition 2: For each key material value, the key bits in the corresponding encryption key are random and uniformly distributed. In other words, for any ω ∈ Ω, k(ω) is random and uniformly distributed over {0, 1} l , and correspondingly, the mutual information between a randomly selected key material value and the corresponding encryption key is zero.

[0175] Property 2 of Definition 2: For any pair of distinct key material values, the bitwise subtraction of the keys in the corresponding encryption key pair is random and uniformly distributed. In other words, for any two distinct ω1, ω2 ∈ Ω, is random and in {0, 1} l and is uniformly distributed over it, where represents bitwise binary subtraction.

[0176] Property 3 of Definition 2: The Shannon entropy of the key repository seed is equal to the Shannon entropy of multiple encryption keys. In other words, the transformation K → Ψ preserves the total amount of secret information, i.e.,

[0177] H(Ψ) = H(K) = L

[0178] where H(X) represents the Shannon entropy of the random variable or vector X.

[0179] Property 4 of Definition 2: Given the second encryption key and the corresponding second key material value, the conditional Shannon entropy of the first encryption key is not less than the specified key length l multiplied by the process evaluation value (i.e., β n × l), where the first encryption key corresponds to the first key material value and the second encryption key corresponds to any other key material value. In other words, for any n and any distinct positive integers i1, i2, …, i n , i n+1 ,

[0180]

[0181] where H(X|Y) represents the conditional Shannon entropy of the random variable X given the random variable Y.

[0182] Property 1 implies that each key k(ω) in the key repository Ψ is a strong key, and the mutual information I(k(X i ); X i ) between each encryption key k(X i ) and the corresponding key material value X i is zero. Therefore, without knowing the key repository seed, distributing the key material value X i does not disclose any information about the key k(X i ) itself. Property 2 implies that when the number of encrypted files is much lower than the total number Λ of encryption keys (a very large Λ can be defined in practical applications to ensure), the probability that all encryption keys used to encrypt data files are very different is extremely high. In particular, for any i ≠ j,

[0183] Pr{k(X i ) = k(X j )}

[0184] = Pr{k(X i) = k(X j ), X i = X j} + Pr{k(X i ) = k(X j ), X i ≠ X j}

[0185] = 1 / Λ + (1 - 1 / Λ)2 -l (1)

[0186] This basically means a collision-free key.

[0187] According to Property 3 and the law of large numbers, it can be seen that

[0188]

[0189] This in turn means that as the number of encrypted files increases, the total amount of secret information is distributed over all the keys used, without any waste.

[0190] Property 4 means that the disclosure (accidental or otherwise) of one or more of the keys used does not significantly reduce the uncertainty of the other keys. Taking all these factors together, a small n with β n close to 1 and information-theoretically β-secure G provides an ideal solution for key management, especially for long-term data protection.

[0191] The following theorem defines some bounds on β n , l, L, and Λ

[0192] Theorem 1

[0193] For the information-theoretically β-secure key management process G described here, each process evaluation value is at most (1 - 1 / Λ) n , that is

[0194] β n ≤ (1 - 1 / Λ) n (3)

[0195] And the sum of all process evaluation values is at most equal to the ratio between the length of the set of seed bits and the specified key length, that is

[0196]

[0197] where β0 = 1.

[0198] According to this doctrine, many different information-theoretic β-secure key management processes can be developed. Given two information-theoretic β-secure key management processes G1 and G2 (possibly different βs), it is desirable to be able to compare the two processes and determine whether G1 is superior to G2 and vice versa. To this end, the evaluation can be considered from the perspective of an adversary (i.e., an unauthorized user / device 120 attempting to access encrypted data). If the adversary only wants to attack a single encrypted file or its corresponding key, it can be seen from Property 1 that all information-theoretic β-secure key management processes are the same, providing the adversary with the same level of difficulty. However, when the adversary attacks multiple encrypted files or keys, the level of difficulty may vary. For example, regardless of how many encrypted files the adversary wants to attack, if the first key management process G1 always provides the adversary with a level of difficulty no lower than that of the second key management process G2, then it can be said that the first key management process G1 is superior to the second key management process G2 (i.e., from the perspective of the adversary, attacking files encrypted with the first key management process G1 is always at least as difficult as attacking files encrypted with the second key management process G2), and accordingly, the optimal key management process can be defined according to Definition 3.

[0199] Definition 3

[0200] For any other information-theoretic β-secure key management process G and possibly different β, given the same key material value, if the key management process G * generates any encryption key with an entropy equal to or greater than the entropy of the encryption key generated by the process G * then it can be defined as the optimal key management process. In other words, G * can be defined as optimal if for any other information-theoretic β-secure key management process G and possibly different β

[0201]

[0202] for any n and any different positive integers i1, i2, …, i n all hold, where

[0203]

[0204] In Section 3 below, an example implementation of the optimal key management process will be described. As shown below, the optimal key management process can be defined as maximizing β n under the restricted equations (3) and (4) to satisfy as many consecutive integers n as possible, starting from n = 1.

[0205] Section 3 – Construction and Properties of an Example of an Optimal Key Management Process

[0206] As described above, the key vault seed entropy value f can be defined as the lower bound of the ratio between the number of seed bits of a specified quantity and the specified key length, and the key vault seed entropy value can be defined as at least 2 (i.e., ).

[0207] A partition value f can be determined based on the ratio of the number of seed bits in the seed bit set to the number of key bits. The partition value can be defined as an integer value that is at least equal to the ratio of the number of seed bits in the seed bit set to the number of key bits. For example, the partition value can be defined as the upper bound of the ratio between the number of specified seed bits and the specified key length (i.e., + ). )

[0208] To generate any of the plurality of encryption keys, the partition value can be used to divide the seed bit set into a plurality of seed bit partitions, and the number of seed bit partitions is defined by the partition value. The encryption application 114 can be configured to determine a key value (i.e., a key material value or other resulting derived value) corresponding to a specific encryption key. The seed bit partitions and the key value are used to determine a key sequence, and the key sequence can include a plurality of key sequence bit sets, each key sequence bit set corresponding to a seed bit partition. Then, the encryption application 114 can determine the encryption key from the key sequence.

[0209] In some examples, the length of the seed bit set can be defined as at least three times the specified key length. For ease of key generation, the length of the seed bit set can be defined as an integer multiple of the specified key length.

[0210] For example, whenever the partition value is only 1 greater than the key vault seed entropy value (i.e., f + = f + 1), the seed bit set can be defined by extending the initial set of seed bits specified by the key vault seed. That is, an initial set of initial seed bits is defined using the key vault seed, and the length of the initial set of initial seed bits can be less than the length of the seed bit set defined by the key management process. The seed bit set can be defined by appending bits (such as appended zeros) to the initial set of initial seed bits such that the combined length of the initial set of initial seed bits and the appended zeros is equal to the length of the seed bit set. For example, the length of the seed bit set can be specified as an integer multiple of the specified key length and the partition value, and zeros can be appended to the end of the initial set K of initial seed bits so that the total length is f + l.

[0211] The partition value f + can be used to divide the seed bit set (such as the possibly extended K) into a plurality of seed bit partitions. For example, the seed bit set can be divided into a plurality of seed bit partitions, and the number of partitions is equal to the partition value f +, the partition length of each seed bit partition is equal to the specified key length l, so that the number of seed bits in each seed bit partition is equal to the number of key bits, which can simplify the generation of an encryption key of the specified key length from multiple seed bit partitions.

[0212] For example, multiple seed bit partitions may include i = 0, 1, …, f + - 1 partitions, denoted by a i to represent the i-th seed bit partition. In particular, each seed bit partition can be defined as including a segment in the set of seed bits. For example, a0 = (K(0), K(1), …, K(l - 1)), a1 = (K(l), K(l + 1), …, K(2l - 1))

[0213] For example, using a key management process, a key sequence can be determined from multiple seed bit partitions and key values. This key sequence can be used to generate an encryption key corresponding to a given key value using the operations defined by the key management process. The generated key can be used to perform various encryption and / or decryption operations, such as encrypting a plaintext file and / or decrypting a ciphertext file.

[0214] A finite field can be defined for the key management process. The finite field contains a number of elements equal to 2 to the power of the specified key length (e.g., GF(2 l ))). The finite field can be defined to contain a number of elements equal to or greater than the number of encryption keys in the multiple encryption keys.

[0215] The key multiplier root ξ can be defined as the root of an l-th degree binary primitive polynomial. Each element α in the finite field GF(2 l ) can be uniquely represented by a bit sequence. For example, α = α0 + α1ξ + … + α l-1 ξ l-1

[0216] A single element α in the finite field can be represented by a binary vector (α0, α1, …, α l-1 ). Each element in the finite field GF(2 l ) can be represented as an l-dimensional binary vector. The seed bit partitions defined above (e.g., random vectors ) can be identified using their corresponding random elements in GF(2 l ).

[0217] Define the set of key indices as a subset of the finite field for the key management process (e.g., Each key material value in the key material set corresponds to an element in the finite field.

[0218] An example of a key management process can define a key mapping from a key store seed to multiple encryption keys by multiplying a seed bit partition by a value determined according to a key value corresponding to a determined key material value. For example, a key sequence can be determined by multiplying each seed bit partition by an exponent of a corresponding key value. The key sequence can include multiple sets of key sequence bits, where each set of key sequence bits corresponds to a product of a seed bit partition and a different exponent of a key value.

[0219] Then, multiple sets of key sequence bits can be used to determine an encryption key. For example, the encryption key can be determined by a bitwise addition of multiple sets of key sequence bits in the key sequence.

[0220] An example of a key management process G * can define a key mapping G between a set of seed bits and multiple encryption keys * :{0,1} L ×Ω→{0,1} l , and this key mapping can specify that each encryption key can be generated from the set of seed bits and the corresponding key material value using linear operations. For example, this key mapping can specify that each encryption key can be generated from the set of seed bits according to the following formula using the corresponding key material value, for all key indices ω∈Ω

[0221]

[0222] The addition and multiplication in the key mapping defined by Equation (6) can be performed in the corresponding finite field GF(2 l ). In some cases, the key management process can specify that the key material value corresponding to the encryption key can be directly used as the key index in the above G * example, or the key index can be derived from the key material value.

[0223] The results of this example key management process can be illustrated by Theorems 2 and 3.

[0224] Theorem 2

[0225] The key management process G that defines the key mapping according to Equation (6) * is information-theoretically β-secure, where

[0226]

[0227] in the case of n > f

[0228]

[0229] and

[0230]

[0231] The following theorem implies that the example of the key management process G defined in (6) * is also optimal.

[0232] Theorem 3

[0233] Suppose G: {0, 1} L × Ω → {0, 1} l is an information - theoretic β - secure key management process, where

[0234]

[0235] The following descriptions are equivalent:

[0236] (1) G is optimal.

[0237] (2) For any distinct key index values ω1, ω2, …, ω in the set of key indices Ω f+1 , the corresponding keys k(ω i ), i = 1, 2, …, f are independent and identically distributed, each key is uniformly distributed over {0, 1} l , and the Shannon entropy of k(ω i ), i = 1, 2, …, f is equal to the length of the set of seed bits, i.e.:

[0238]

[0239] (3) For n = 1, …, f - 1,

[0240]

[0241] Theorem 3 implies that for any optimal key management process G, once the distinct key index values of several keys corresponding to the partition value f + are disclosed, the key - store seed K can be determined theoretically. However, in practice, users can only handle and manage a limited amount of secret information. Therefore, in terms of the confidentiality of secret information, the systems and methods described herein can be configured to provide an optimal way of using a limited amount of secret information in key management. If the amount of disclosed information is equal to the original amount of secret information, no secret is left. In addition, since disclosing the key index value ω does not disclose any information about the corresponding key k(ω), an adversary must still attack the underlying symmetric cipher or its implementation (including its corresponding encryption engine and / or memory) to determine the key k(ω). For an optimal key management process G, even if an adversary successfully determines a key f - 1 times, this does not provide any advantage in attacking other keys. Therefore, a symmetric cipher equipped with the optimal key management process G can be considered at least f times stronger than a symmetric cipher with only a single random key.

[0242] Section 4 – Ways to Prevent Seed Reconstruction

[0243] In the above description, the optimal information-theoretic β-secure key management process G * is described, and the key management process G * The implementation example generates an encryption key from multiple seed bit partitions using linear operations, as shown in formula (6). From an information-theoretic perspective, whether key generation is a linear or non-linear operation is not important. However, from a computational perspective, linear key generation may be vulnerable to reconstruction attacks. If an attacker manages to obtain multiple keys through a memory attack on an actual encryption engine or other means, the attacker can "reconstruct" the key bank seed K by solving a system of linear equations with the corresponding key indices as coefficients in GF(2 l ).

[0244] The key management process example described below can prevent reconstruction attacks by generating an encryption key from a set of seed bits using non-linear operations. The key management process example described below is implemented as a variant of G * The variant example of G discussed below can be implemented by combining a linear key generation method (such as the linear method defined in (6)) with an underlying secure symmetric cipher (or other symmetric encryption cipher) to protect the key bank seed K from reconstruction attacks. *

[0245] 4.1 Variant 1 Example

[0246] Let E denote the encryption cipher. For example, E may correspond to an underlying secure symmetric cipher (such as the AES algorithm) for encrypting a plaintext file using the encryption key described here, or E may correspond to a different symmetric encryption cipher for encrypting a data file.

[0247] Generally, an encryption cipher E with a key length of l can be configured to take a plaintext of a given length l as input and generate a ciphertext of length l. Combining the encryption cipher E with the linear key management process G * described above can define a non-linear key management process The key management process can define a key mapping which stipulates that to determine the encryption key from the key sequence, it is first necessary to determine the key sequence output from multiple seed bit partitions. For example, the key sequence output can be determined by the bitwise addition of multiple key sequence bit sets in the key sequence.

[0248] ​A key mapping can specify that each encryption key is generated from a set of seed bits and corresponding key material values using a non - linear operation. For example, the key mapping can specify that an encryption key is determined from the output of a key sequence using an encryption cipher E. For example, the output of the key sequence can be used as an input to a symmetric encryption cipher. The symmetric encryption cipher can be configured to generate a ciphertext key sequence using the output of the key sequence. Then, the encryption key can be defined as the output of the ciphertext key sequence by the symmetric encryption cipher.

[0249] Key mapping An example of can be expressed as:

[0250]

[0251] which holds for all key index values ω ∈ Ω.

[0252] Key management process (e.g., the operation in (8)) is highly non - linear, and the encryption key used in the key management process can be regarded as an additional l - bit shared key. Thus, the shared secret between the information sender and receiver (such as the authorized device 105) includes a key - store seed K with a seed - bit length of L and an encryption key with a specified key length of l used by the encryption cipher E in (8). With the additional l - bit secret, it can be shown that the non - linear key management process is at least as secure as the linear key management process G in the sense of Definition 3 * as secure.

[0253] Furthermore, the non - linear key management process is secure against reconstruction attacks. In the non - linear key management process given a key index value ω and the corresponding key k(ω), determining multiple seed - bit partitions from the key - store seed used to generate the key is as difficult as breaking the underlying secure symmetric cipher.

[0254] 4.2 Variant 2 Example

[0255] Combining the encryption cipher E with the linear key management process G described above * in a different way can define another example of a non - linear key management process Non - linear key management process can specify that the key value of a given encryption key is determined by inputting the corresponding key material value (such as a key index) into a symmetric encryption cipher. The symmetric encryption cipher can be configured to generate a ciphertext key material value using the key material value, and then, the key value can be defined as the ciphertext key material value.

[0256] As an example, the key management process A key mapping can be defined as

[0257]

[0258] which holds for all key indices ω ∈ Ω.

[0259] Similarly, with an additional l-bit secret, it can be shown that the non-linear key management process is at least as secure as the linear key management process G in the sense of Definition 3 * . Furthermore, the non-linear key management process is also secure against reconstruction attacks.

[0260] For an underlying secure symmetric cipher with key length l, this application describes, from an information-theoretic perspective, several examples of processes for securely generating, distributing, and maintaining a large number Λ of random encryption keys under the practical condition of being able to manage only a relatively small number L of shared secret bits K, where L << Λ ≤ 2 l . This disclosure defines the concept of key management, herein referred to as information-theoretic β-secure, and a framework within which information-theoretic β-secure key management processes can be defined, analyzed, and compared. The optimal process in terms of resistance to adversary attacks is also described. The application also provides examples of specific optimal information-theoretic β-secure processes (e.g., G * ), including non-linear key management processes configured to provide security against reconstruction attacks.

[0261] It is to be understood that the encryption key management processes for key generation, distribution, and maintenance according to the current application can be implemented in several computing devices, including servers, general-purpose computers with associated programming, audio / video encoding and playback devices, set-top television boxes, television broadcast devices, and mobile devices. The encryption key management scheme can be implemented by means of software and / or hardware including instructions configuring a processor to perform the functions described herein. The software instructions can be stored on any suitable non-transitory computer-readable memory, including CDs, RAMs, ROMs, flash memories, etc.

[0262] It is to be understood that the encryption key management processes described herein, as well as the modules, routines, processes, threads, or other software components implementing the methods / processes, can be implemented using standard computer programming techniques and languages. The current application is not limited to specific processors, computer languages, computer programming conventions, data structures, and other implementation details. Those skilled in the art will recognize that the described methods / processes can be implemented as part of computer-executable code stored in volatile or non-transitory memory, or as part of an application-specific integrated circuit (ASIC).

[0263] Those skilled in the art may make certain adjustments and modifications to the method, and the embodiments of the key management process discussed above should be regarded as illustrative rather than restrictive.

[0264] Although the above description depicts the features of the embodiment examples, it is to be understood that certain features and / or functions of the embodiments are susceptible to modification without departing from the spirit and operating principles of the embodiments. For example, the various features described by the represented embodiments or examples can be selectively combined with each other. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the description of the embodiments. Accordingly, the foregoing is intended to illustrate the concepts claimed rather than to limit. Those skilled in the art will understand that other variations and modifications can be made without departing from the scope of the invention defined by the claims. The scope of the claims should not be limited by the preferred embodiments and examples, but should be given the broadest interpretation consistent with the entire description.

Claims

1. A method for managing multiple encryption keys using at least one computing device, each computing device having a processor and a non-transitory device memory, the method comprising: a) storing a key vault seed in the non-transitory memory of a particular computing device among the at least one computing device, the key vault seed being usable to generate each of the multiple encryption keys, wherein the key vault seed defines a set of seed bits having a plurality of seed bits, the plurality of seed bits in the set of seed bits being independently and identically distributed, wherein each encryption key is defined by a plurality of key bits, the encryption key having a specified key length, the specified key length being the same for each encryption key, the specified key length defining the number of key bits in the plurality of key bits, wherein the set of seed bits has a set length of seed bits, the set length of seed bits specifying the number of seed bits in the set of seed bits, the set length of seed bits being at least twice the specified key length; b) determining, by the processor of the particular computing device, a key management process that defines a key mapping between the set of seed bits and the multiple encryption keys, wherein the key management process is usable by the processor of the particular computing device to generate each of the multiple encryption keys from the set of seed bits by using the key mapping and a key material value corresponding to the encryption key; and c) storing key management instructions corresponding to the key management process in the non-transitory memory of the particular computing device, wherein the key management instructions are executable by the processor of the particular computing device to generate any particular one of the multiple encryption keys by: i) dividing the set of seed bits into a plurality of seed bit partitions, wherein, for all of the multiple encryption keys, the plurality of seed bit partitions are the same seed bit partitions, wherein the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on a ratio between the number of seed bits in the set of seed bits and the number of key bits, wherein the partition value is an integer and is at least equal to the ratio between the number of seed bits in the set of seed bits and the number of key bits; ii) determining a key value from the key material value corresponding to the particular encryption key; iii) using the plurality of seed bit partitions and the key value to determine a key sequence, wherein the key sequence includes a plurality of sets of key sequence bits, each set of key sequence bits corresponding to a seed bit partition, wherein the key sequence is determined by multiplying each seed bit partition by a corresponding exponent of the key value, and each set of key sequence bits corresponds to a product of a seed bit partition and a different exponent of the key value; and iv) Determine an encryption key from the key sequence, where the encryption key can be used by the processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

2. The method according to claim 1, wherein the encryption key is determined based on a bitwise addition of the multiple key sequence bit sets in the key sequence.

3. The method according to claim 1, wherein each seed bit partition has a partition length equal to the specified key length, such that the number of seed bits in each seed bit partition is equal to the number of key bits.

4. The method according to claim 1, wherein the key management process specifies that the key value is defined as the key material value.

5. The method according to claim 1, wherein the key management process specifies that determining the encryption key from the key sequence includes: a) Determine a key sequence output from the key sequence, where the key sequence output is determined based on a bitwise addition of the multiple key sequence bit sets in the key sequence; and b) Determine the encryption key by: i) Inputting the key sequence output into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key sequence using the key sequence output; ii) Determining the encryption key as the ciphertext key sequence.

6. The method according to claim 1, wherein the key management process specifies that the key value is determined as follows: a) Inputting the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key material value using the key material value; b) Determining the key value as the ciphertext key material value.

7. The method according to claim 1, further comprising: a) Identifying a file to be encrypted; b) Generating a file encryption key by: i) Randomly selecting a specific key material value; ii) Using the key management process to determine a specific key value from the specific key material value; iii) Using the key management process to determine a specific key sequence from the multiple seed bit partitions and the specific key value; iv) Using the key management process to determine the file encryption key from the specific key sequence; c) Generating an encrypted file by: i) Applying an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cryptographic key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cryptographic key of the encryption cipher; ii) Generating the encrypted file from the ciphertext file.

8. The method according to claim 7, wherein the encrypted file includes the ciphertext file and the file key material corresponding to the specific key material value.

9. The method according to claim 1, further comprising: a) Identifying a given encrypted file to be decrypted; b) Determining a given key material value corresponding to the given encrypted file; c) Using the said key management process, determine a given key value from the said given key material value; d) Using the said key management process, determine a given key sequence with the said multiple seed bit partitions and the said given key value; e) Using the said key management process, generate a file decryption key from the said given key sequence; f) Generate a decrypted file by applying a decryption cipher to the said given encrypted file to generate a plaintext file, where the decryption cipher uses a decryption cipher key to generate the plaintext file, and when the decryption cipher is applied to the said given encrypted file, the file decryption key is used as the decryption cipher key of the decryption cipher.

10. The method according to claim 9, wherein determining the said given key material value corresponding to the said given encrypted file includes extracting the said given key material value from the encrypted file.

11. The method according to claim 1, wherein the length of the set of seed bits is at least three times the specified key length, and the length of the set of seed bits is an integer multiple of the specified key length.

12. The method according to claim 11, wherein the key store seed defines an initial set of initial seed bits, where the initial set of initial seed bits has an initial set length less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of initial seed bits, such that the combined length of the initial set of initial seed bits and the appended zeros is equal to the length of the set of seed bits.

13. The method according to claim 1, further comprising securely transmitting the key management instructions and the key store seed to a plurality of different computing devices, where the key management instructions and the key store seed enable each different computing device to generate each of the plurality of encryption keys.

14. A computer program product for managing a plurality of encryption keys, the computer program product comprising a computer-readable medium storing computer-executable instructions for configuring a processor of a computing device to: a) Store a key store seed in a non-transitory memory of the computing device, the key store seed being usable to generate each of the plurality of encryption keys, where the key store seed defines a set of seed bits having a plurality of seed bits, the plurality of seed bits in the set of seed bits being independently and identically distributed, where each encryption key is defined by a plurality of key bits, the encryption keys having a specified key length, the specified key length being the same for each encryption key, the specified key length defining the number of key bits in the plurality of key bits, where the set of seed bits has a length of the set of seed bits, the length of the set of seed bits specifying the number of seed bits in the set of seed bits, the length of the set of seed bits being at least twice the specified key length; b) Determine a key management process that defines a key mapping between the set of seed bits and the plurality of encryption keys, wherein the key management process can be used by the processor to generate each of the plurality of encryption keys from the set of seed bits by using the key mapping and the key material value corresponding to the encryption key; And c) Store key management instructions corresponding to the key management process in the non-transitory memory, wherein the key management instructions can be executed by the processor to generate any particular one of the plurality of encryption keys by: i) Divide the set of seed bits into a plurality of seed bit partitions, wherein, for all of the plurality of encryption keys, the plurality of seed bit partitions are the same seed bit partitions, and wherein the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on the ratio between the number of seed bits in the set of seed bits and the number of key bits, wherein the partition value is an integer and is at least equal to the ratio between the number of seed bits in the set of seed bits and the number of key bits; ii) Determine a key value from the key material value corresponding to the particular encryption key; iii) Use the plurality of seed bit partitions and the key value to determine a key sequence, wherein the key sequence includes a plurality of sets of key sequence bits, each set of key sequence bits corresponding to a seed bit partition, and wherein the key management instructions are defined to configure the processor to determine the key sequence by multiplying each seed bit partition by a corresponding exponent of the key value, wherein each set of key sequence bits corresponds to a product of a seed bit partition and a different exponent of the key value; and iv) Determine an encryption key from the key sequence, wherein the encryption key can be used by the processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

15. The computer program product according to claim 14, wherein the key management instructions are defined to configure the processor to determine the encryption key based on a bitwise addition of the plurality of sets of key sequence bits in the key sequence.

16. The computer program product according to claim 14, wherein the key management instructions are defined to configure the processor to define each seed bit partition, wherein each seed bit partition has a partition length equal to the specified key length, such that the number of seed bits in each seed bit partition is equal to the number of key bits.

17. The computer program product according to claim 14, wherein the key management process specifies that the key value is defined as the key material value.

18. The computer program product according to claim 14, wherein the key management instructions are defined to configure the processor to determine the encryption key from the key sequence in the following manner: a) Determine a key sequence output from the key sequence, where the key sequence output is determined by a bitwise addition of the multiple key sequence bit sets in the key sequence; and b) Determine the encryption key by: i) Input the key sequence output into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key sequence using the key sequence output; ii) Determine the encryption key as the ciphertext key sequence.

19. The computer program product according to claim 14, wherein the key management instructions are defined to configure the processor to determine the key value in the following manner: a) Input the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key material value using the key material value; b) Determine the key value as the ciphertext key material value.

20. The computer program product according to claim 14, further comprising instructions for configuring the processor to identify a file to be encrypted: a) wherein the key management instructions are defined to configure the processor to generate a file encryption key in the following manner: i) Randomly select a specific key material value; ii) Use the key management process to determine a specific key value from the specific key material value; iii) Use the key management process to determine a specific key sequence from the multiple seed bit partitions and the specific key value; and iv) Use the key management process to determine the file encryption key from the specific key sequence; a) Generate an encrypted file by: i) Apply an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cryptographic key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cryptographic key of the encryption cipher; and ii) Generate the encrypted file from the ciphertext file.

21. The computer program product according to claim 20, wherein the encrypted file includes the ciphertext file and the file key material corresponding to the specific key material value.

22. The computer program product according to claim 14, further comprising instructions for configuring the processor to identify a given encrypted file to be decrypted: a) wherein the key management instructions are defined to configure the processor to i) Determine a given key material value corresponding to the given encrypted file; Use the key management process to determine a given key value from the given key material value; ii) Use the key management process to determine a given key sequence with the multiple seed bit partitions and the given key value; iii) Use the key management process to generate a file decryption key from the given key sequence; and iv) Generating a decrypted file by generating a plaintext file by applying a decryption cipher to the given encrypted file, wherein the decryption cipher uses a decryption cipher key to generate the plaintext file, and when the decryption cipher is applied to the given encrypted file, the file decryption key is used as the decryption cipher key for the decryption cipher.

23. The computer program product according to claim 22, wherein determining the given key material value corresponding to the given encrypted file includes extracting the given key material value from the encrypted file.

24. The computer program product according to claim 14, wherein the length of the set of seed bits is at least three times the specified key length, and the length of the set of seed bits is an integer multiple of the specified key length.

25. The computer program product according to claim 24, wherein the key store seed defines an initial set of seed bits, wherein the initial set of seed bits has an initial set length that is less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of seed bits such that the combined length of the initial set of seed bits and the appended zeros is equal to the length of the set of seed bits.

26. The computer program product according to claim 14, further comprising instructions for configuring the processor to securely transmit the key management instructions and the key store seed to a plurality of different computing devices, wherein the key management instructions and the key store seed enable each different computing device to generate each of the plurality of encryption keys.

27. An apparatus for managing a plurality of encryption keys, the apparatus comprising: a) a processor; and b) a non-transitory device memory having instructions stored thereon for configuring the processor to perform the following: i) Storing a key store seed in the non-transitory device memory, the key store seed being usable to generate each of the plurality of encryption keys, wherein the key store seed defines a set of seed bits having a plurality of seed bits, the plurality of seed bits in the set of seed bits being independently and identically distributed, wherein each encryption key is defined by a plurality of key bits, the encryption keys having a specified key length, the specified key length being the same for each encryption key, the specified key length defining the number of key bits in the plurality of key bits, wherein the set of seed bits has a length of the set of seed bits, the length of the set of seed bits specifying the number of seed bits in the set of seed bits, the length of the set of seed bits being at least twice the specified key length; ii) Determining a key management process that defines a key mapping between the set of seed bits and the plurality of encryption keys, wherein the key management process is usable by the processor to generate each of the plurality of encryption keys from the set of seed bits by using the key mapping and a key material value corresponding to the encryption key; and iii) storing key management instructions corresponding to the key management process in the non-transitory device memory, the key management instructions being executable by the processor to generate any particular encryption key of the plurality of encryption keys by: dividing the set of seed bits into a plurality of seed bit partitions, wherein, for all of the encryption keys of the plurality of encryption keys, the plurality of seed bit partitions are the same seed bit partitions, wherein the number of seed bit partitions in the plurality of seed bit partitions is defined by a partition value determined based on a ratio between the number of seed bits in the set of seed bits and the number of key bits, wherein the partition value is an integer and is at least equal to the ratio between the number of seed bits in the set of seed bits and the number of key bits; determining a key value from a key material value corresponding to the particular encryption key; using the plurality of seed bit partitions and the key value to determine a key sequence, wherein the key sequence includes a plurality of key sequence bit sets, each key sequence bit set corresponding to a seed bit partition, wherein the key management instructions are defined to configure the processor to determine the key sequence by multiplying each seed bit partition by a respective exponent of the key value, wherein each key sequence bit set corresponds to a product of a seed bit partition and a different exponent of the key value; and determining an encryption key from the key sequence, wherein the encryption key can be used by the processor to perform at least one of encrypting a plaintext file and decrypting a ciphertext file.

28. The apparatus of claim 27, wherein the key management instructions are defined to configure the processor to determine the encryption key based on a bitwise addition of the plurality of key sequence bit sets in the key sequence.

29. The apparatus of claim 27, wherein the key management instructions are defined to configure the processor to define each seed bit partition, wherein each seed bit partition has a partition length equal to the specified key length, such that the number of seed bits in each seed bit partition is equal to the number of key bits.

30. The apparatus of claim 27, wherein the key management process specifies that the key value is defined as the key material value.

31. The apparatus of claim 27, wherein the key management instructions are defined to configure the processor to determine the encryption key from the key sequence as follows: a) determining a key sequence output from the key sequence, wherein the key sequence output is determined by a bitwise addition of the plurality of key sequence bit sets in the key sequence; and b) determining the encryption key by: i) inputting the key sequence output into a symmetric encryption cipher, the symmetric encryption cipher being configured to generate a ciphertext key sequence using the key sequence output; ii) determining the encryption key as the ciphertext key sequence.

32. The apparatus according to claim 27, wherein the key management instruction is defined to configure the processor to determine the key value in the following manner: a) Input the key material value into a symmetric encryption cipher, where the symmetric encryption cipher is configured to generate a ciphertext key material value using the key material value; b) Determine the key value as the ciphertext key material value.

33. The apparatus according to claim 27, wherein a) The instruction is defined to configure the processor to identify a file to be encrypted; b) The key management instruction is defined to configure the processor to generate a file encryption key in the following manner: i) Randomly select a specific key material value; ii) Use the key management process to determine a specific key value from the specific key material value; iii) Use the key management process to determine a specific key sequence from the multiple seed bit partitions and the specific key value; and iv) Use the key management process to determine the file encryption key from the specific key sequence; c) Generate an encrypted file by the following means: i) Apply an encryption cipher to the file to generate a ciphertext file, where the encryption cipher uses a cipher key to generate the ciphertext file, and when the encryption cipher is applied to the file, the file encryption key is used as the cipher key of the encryption cipher; and ii) Generate the encrypted file from the ciphertext file.

34. The apparatus according to claim 33, wherein the encrypted file includes the ciphertext file and the file key material corresponding to the specific key material value.

35. The apparatus according to claim 27, wherein a) The instruction is defined to configure the processor to identify a given encrypted file to be decrypted; b) The key management instruction is defined to configure the processor to i) Determine a given key material value corresponding to the given encrypted file; ii) Use the key management process to determine a given key value from the given key material value; iii) Use the key management process to determine a given key sequence with the multiple seed bit partitions and the given key value; iv) Use the key management process to generate a file decryption key from the given key sequence; and v) Generate a decrypted file by applying a decryption cipher to the given encrypted file to generate a plaintext file, where the decryption cipher uses a decryption cipher key to generate the plaintext file, and when the decryption cipher is applied to the given encrypted file, the file decryption key is used as the decryption cipher key of the decryption cipher.

36. The apparatus according to claim 35, wherein determining the given key material value corresponding to the given encrypted file includes extracting the given key material value from the encrypted file.

37. The apparatus according to claim 27, wherein the length of the seed bit set is at least three times the specified key length, and the length of the seed bit set is an integer multiple of the specified key length.

38. The apparatus according to claim 37, wherein the key store seed defines an initial set of seed bits, the initial set of seed bits having an initial set length that is less than the length of the set of seed bits, and the set of seed bits is defined by appending zeros to the initial set of seed bits such that the combined length of the initial set of seed bits and the appended zeros is equal to the length of the set of seed bits.

39. The apparatus according to claim 27, wherein the instructions are defined to configure the processor to securely transmit the key management instructions and the key store seed to a plurality of different computing devices, the key management instructions and the key store seed enabling each different computing device to generate each of the plurality of encryption keys.

Images