Encryption key management across multiple computing devices

Abstract

In some examples, a first computing device of a plurality of computing devices may send a request to a key management (KM) device for information related to at least one of an active key encryption key (KEK) and a pre-active KEK associated with an entity. The first computing device may receive, from the KM device, an indication that the KM device does not have an active KEK or a pre-active KEK. In response, the first computing device may send an instruction to the KM device to create a pre-active KEK for the entity. Based on a subsequent determination that there is a plurality of pre-active KEKs for the entity available from the KM device, the first computing device may send an instruction to the KM device to activate the pre-active KEK having the earliest creation time, and the first computing device may receive an active KEK for the entity.

Description

Technical Field

[0001] The present disclosure relates to the technical fields of data encryption and data storage. Background Art

[0002] Data can be encrypted and decrypted using data encryption keys. The Key Management Interoperability Protocol (KMIP) is a standard by which computing systems that use encryption keys communicate with a key management (KM) computing device to obtain encryption keys. For example, KMIP can provide a messaging format for simplifying the management of encryption keys. As an example, keys can be created on a KM computing device and provided to a computing system that uses the keys to encrypt data. KMIP supports symmetric and asymmetric encryption techniques. In addition, under KMIP, encryption keys can have a life cycle of defined states including a pre-active state, an active state, and a deactivated state before being destroyed.

[0003] In some types of computing systems, a data encryption key (DEK) can be used to encrypt stored data. In addition, the DEK itself can be encrypted (wrapped) using a key encryption key (KEK) that can be used to encrypt and protect the DEK. For example, when it is desired to decrypt specific data, the corresponding KEK can be retrieved and used to decrypt the corresponding DEK, and the corresponding DEK can then be used to decrypt the data.

[0004] Once a key is created and used in a computing system, it is often difficult to destroy or replace the key because there may be encrypted data in the system that requires a particular key to decrypt. For example, if a key were to be destroyed before the corresponding encrypted data could be decrypted, the encrypted data could be considered lost. However, key management and security can consume resources in a computing system. Therefore, being able to minimize the number of keys used in a computing system while avoiding data loss would improve the operation of the computing system. Summary of the invention

[0005] In some implementations, a first computing device among a plurality of computing devices in a computing system may send a request to a key management computing device for information about at least one of an active key encryption key (KEK) associated with an entity and a pre-active KEK associated with the entity. The first computing device may receive an indication from the key management computing device that the key management computing device does not have an active KEK or a pre-active KEK associated with the entity. In response to the indication, the first computing device may send an instruction to the key management computing device to create a pre-active KEK for the entity. Based on a subsequent determination that there are multiple pre-active KEKs for the entity that are available from the key management computing device, the first computing device may send an instruction to the key management computing device to activate the pre-active KEK having the earliest creation time, and the first computing device may receive the active KEK for the entity. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The detailed description is set forth with reference to the accompanying drawings. In the drawings, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears. The use of the same reference numbers in different drawings indicates similar or identical items or features.

[0007] Figure 1 An example architecture of a distributed computing system configured for encrypting and decrypting data is shown in accordance with some implementations.

[0008] Figure 2 Shown are selected example components in an example configuration of a computing system in accordance with some implementations.

[0009] Figure 3 is a flow chart illustrating an example process for obtaining an active key according to some embodiments.

[0010] Figure 4 An example key state data structure is shown in accordance with some implementations.

[0011] Figure 5 An exemplary key attribute data structure according to some specific implementations is shown.

[0012] Figure 6 An example active key state data structure is shown in accordance with some implementations.

[0013] Figure 7 Select example components of one or more KM computing devices are shown in accordance with some implementations. DETAILED DESCRIPTION

[0014] Some embodiments herein relate to techniques and arrangements for cryptographic key management in computing systems, such as minimizing key encryption keys (KEKs) per entity and maximizing performance in an environment including multiple computing devices. In some examples, a computing system can minimize the number of KEKs stored on a key management (KM) computing device by allowing only one KEK to be created per user, per namespace, per tenant, or per other entity type. For example, operations based at least in part on KMIP can be used to create only one KEK even when multiple service computing devices, clusters, or other computing systems request a new KEK for use by a particular entity at the same time (e.g., at approximately the same time and / or before completing a first KEK request).

[0015] As an example, each service computing device involved in servicing a data request requiring a new KEK may attempt to create a KEK that matches the request. Additionally, each of the service computing devices may independently query and interact with a key management (KM) computing device in such a way that only one active KEK is generated and shared among all service computing devices that require a KEK for use by a particular entity, while pre-active keys created during the KEK acquisition process may be destroyed. KEKs created or otherwise retrieved from the KM computing device by this process may be cached on each service computing device to alleviate the need for frequent KM computing device accesses.

[0016] In some examples, when the service computing device starts, the service computing device can contact any configured KM computing device and retrieve all keys with a custom attribute indicating that the corresponding key belongs to a computing system associated with the specific service computing device. The retrieved keys can be stored locally, such as in a temporary memory cache or other key data structure. Once in the key data structure on the service computing device, the keys can be further organized into several overlapping mappings to optimize the efficiency of retrieving one or more keys based on certain qualifiers. In addition, the key data structure implements rotation, verification, key update (rekeying), and destruction policies to ensure that only new and valid keys are used for encryption, especially in the event that a specific key is compromised.

[0017] Additionally, when the KM computing device receives a communication from one of the service computing devices included in a computing system (e.g., in a cluster or other type of computing system arrangement including multiple service computing devices) that results in a change to the key data structure of the service computing device, the change to the key data structure may be distributed to all other service computing devices within the computing system, e.g., via indirect action by each of the other service computing devices in the computing system, or additionally or alternatively by direct messaging from the KM computing device or from the service computing device that was the cause of the change to the key data structure to the other service computing devices. This feature limits the need for other service computing devices to contact the KM computing device when the other service computing devices require a created or changed KEK.

[0018] In the examples herein, the interaction between the KMIP client and the KM computing device 119 minimizes the number of requests from the client to the server (i.e., from the service computing device to the KM computing device). In addition, the number of KEKs stored on the service computing device and the KM computing device is also minimized. For example, when a KEK is used even once to encrypt data, then to prevent data loss, the KEK cannot be destroyed unless the KEK is replaced by decrypting all data encryption keys (DEKs) that have been encrypted using the KEK and re-encrypting these DEKs using the currently active replacement KEK. In addition, some examples herein can minimize key-related network traffic between the service computing device and the KM computing device. In addition, some examples minimize or eliminate network traffic based on user or time key requests, such as by providing a key data structure and the key acquisition process herein.

[0019] In addition, some examples herein provide improved security for the data itself. For example, by enforcing the use of a different KEK for each user, namespace, tenant, or other entity, or even for each data object or other data fragment to obtain the highest level of protection, the implementation provides an improvement over conventional techniques that use a shared KEK that can be shared between entities that do not share data. In addition, some examples herein do not use persistent storage external to the KM computing device to store the KEK, but instead only employ a key cache or other type of temporary key data structure in a temporary memory location.

[0020] The implementation of the features of this article may be complicated by the multi-node nature of the computing system of this article. For example, multiple service computing devices (sometimes referred to as "nodes") can be used to read data from a storage device and write data to the storage device at the same time. Therefore, all service computing devices in the system may need to access the same key pool, which may result in a large amount of traffic between the computing system and the KM computing device, if it is not used to provide a multi-node key cache data structure according to the implementation of this article.

[0021] Some examples herein may employ a background service to rotate KEKs on one or more of a per-object basis, a per-user basis, a per-namespace basis, a per-tenant basis, or a per-entity basis, and may use metrics to determine when a particular KEK may be destroyed. For example, the process herein may determine when a particular KEK is no longer in use, for example, by utilizing information obtained via KMIP, which may include an initialization date and a configured crypto period of the KEK lifecycle that allows the KEK to be deactivated. The process herein may further determine (e.g., based on metrics maintained by a service computing device) that there are no longer any DEKs encrypted using a particular KEK (which may be identified in the system based on a unique identifier of the particular KEK). Based on determining that there are no longer any DEKs encrypted using a particular KEK, the process herein may destroy the particular KEK. The examples herein may perform these functions in a manner that does not interrupt performance associated with user-initiated actions (e.g., data read or data write requests). The key rotation process herein may also provide the ability to maintain a scavenge object, such as even when associated metadata is lost. In addition, by employing a different KEK for each user, each namespace, each tenant, or each other entity type, the security of stored data is increased, while the total number of KEKs used by the computing system can be minimized based on at least providing only one active valid KEK to meet the data protection requirements of each such entity respectively. Some examples can use KMIP-specific key attributes such as "pre-active" and "active" to enable this feature in high-performance multi-node and multi-cluster computing environments.

[0022] Some examples herein may be used in conjunction with the storage of data objects on a storage device, such as in a storage device array. For example, a data object such as a file or other object type may typically include object data and object metadata. For example, the object data includes the content of the object. In addition, the object metadata may include information about the object data, such as the location of the object data in a file system, and other system-generated information about the object, user-generated information about the object, and the like.

[0023] In some embodiments, each data object stored by the computing system may have its own system-unique DEK to maximize data protection by not sharing DEKs between data objects. For example, the DEKs for individual data objects may be stored with other metadata for the corresponding data object, or may be stored in other ways and associated with its corresponding data object. Additionally, in the examples herein, each DEK may be encrypted with a KEK, which may be maintained in a key data structure and assigned to a corresponding entity associated with the corresponding data object.

[0024] The computing systems here can use their respective KEKs to access stored objects through their associated DEKs, respectively, and malicious actors may not be able to crack the DEK using patterns between encrypted objects. The computing system can assign a single KEK to each entity that stores data on the computing system. The entity can be an individual user, a tenant (e.g., an organization, a user group, etc.), a namespace within a tenant, or an entire cluster of service computing devices. In some cases, a namespace and / or a tenant may have data stored across several computing system sites that are geographically distant from each other and can provide a replication topology (such as for disaster recovery). In some examples, a corresponding universally unique identifier (UUID) may be associated with each corresponding KEK. For example, the UUID may be unique among a computing system or a group of computing systems that communicate with each other. When it is desired to decrypt the stored data, a matching KEK can be retrieved based at least in part on the corresponding UUID, and the decrypted KEK can be used to decrypt the DEK of the data, which in turn is used to decrypt the data itself.

[0025] Conventional techniques for multi-node key creation and storage typically rely on designating a specific node as a master node responsible for communicating with a key server. The master node can serve requests from other nodes for obtaining keys from a key server. However, this arrangement may include a single point of failure, which typically requires additional redundant contingency plans if the master node is down. For example, if a different node takes over a subsequent failure of the master node, there may be inconsistent or unrelated key server communications depending on the timing. On the other hand, the examples herein do not designate any computing device as a master node, but each service computing device is able to communicate with the KM computing device independently and as needed to request a KEK. Therefore, the examples herein have significantly greater resilience to failures, while also minimizing the number of KM computing device requests to an amount similar to conventional techniques using a master node.

[0026] For purposes of discussion, some example implementations are described in the context of one or more computing systems that utilize a key encryption key to encrypt a data encryption key used to encrypt and decrypt data. However, the embodiments herein are not limited to the specific examples provided and may be extended to other types of computing system architectures, other types of storage environments, other types of client configurations, other types of data, other types of encryption keys, etc., as will be apparent to those skilled in the art based on the disclosure herein.

[0027] Figure 1An example architecture of a distributed computing system 100 configured for encrypting and decrypting data is shown in accordance with some embodiments. A plurality of computing systems 102 are arranged at a plurality of respective computing site locations 104 in the distributed computing system 100, such as a first computing system 102(1) located at a first site location 104(1) and a second computing system 102(2) located at a second site location 104(2). Furthermore, while two computing systems 102 and computing site locations 104 are shown in this example, in other examples, the number of computing systems 102 and computing site locations 104 is not limited to two, and may be one or more computing systems 102 at one or more respective sites 104, such as ranging between one to hundreds of computing systems and sites, some or all of which may be geographically dispersed from one another. Furthermore, in some examples, the plurality of computing systems 102 may be located at a single site 104, or the individual computing systems 102 may be distributed across a plurality of sites 104.

[0028] In addition, computing systems 102 may communicate with each other via one or more networks 106, and may also communicate with respective network storage devices 108. For example, first computing system 102(2) may communicate with network storage device 108(1) that maintains object data 110(1) managed by first computing system 102(1), and second computing system 102(2) may communicate with network storage device 108(2) that maintains object data 110(2) managed by second computing system 102(2). In some examples, network storage devices 108 may be provided by one or more commercial cloud-based storage providers, such as etc., and may typically, but not necessarily, be located remotely from the first computing site 104(1) and the second computing site 104(2).

[0029] In some cases, each computing system 102 may include at least one service computing device 112 and at least one local storage device 114. Thus, one or more service computing devices 112(1) and one or more local storage devices 114(1) may be included at a first computing system 102(1), and one or more service computing devices 112(2) and one or more local storage devices 114(2) may be included at a second computing system 102(2). In some cases, service computing devices 112 and local storage devices 114 may be in physically separate machines. For example, as described below with respect to Figure 2As discussed further, the local storage device 114 may be incorporated into the local storage system. In other examples, the local storage device(s) 114 may be incorporated into the service computing device(s) 112 or may otherwise be included in the service computing device(s) 112. Additionally, in some examples, the service computing devices 112 of the respective computing systems 102 may correspond to computing clusters, such as server clusters associated with one another. However, the computing systems 102 are not limited to the hardware configurations described and illustrated in this disclosure, but may include any suitable or desired hardware configurations capable of providing data storage and performing the functions described herein, and in some cases, the hardware configuration at one of the computing systems 102 may be different from the hardware configuration at another of the computing systems 102.

[0030] In some examples, each service computing device 112 may maintain a key data structure 115, such as a key cache, which may be a temporary key data structure maintained in a portion of a memory of the respective service computing device for storing at least a KEK corresponding to data managed by the respective service computing device 112. Thus, service computing device 112(1) may maintain a respective key data structure 115(1) that includes at least a KEK corresponding to data managed by service computing device 112(1), and service computing device 112(2) may maintain a respective key data structure 115(2) that includes at least a KEK corresponding to data managed by service computing device 112(2).

[0031] In some cases, the service computing devices 112(1) and 112(2) in each computing system 102(1) and 102(2) may include, maintain, or otherwise access metadata data structures 116(1) and 116(2), respectively, which may be used to store metadata about object data 118(1), 110(1) and 118(2), 110(2), respectively, with the metadata being stored at the respective systems 102(1) and 102(2) and at the network storage devices 108(1) and 108(2), respectively. For example, metadata data structure 116 may be a database, a table, or any other suitable data structure. The metadata included in metadata data structure 116 may include information about each respective storage object, such as a path, a name, an owner, a hash value determined from the object data, a DEK used to encrypt / decrypt the storage object data, and the like.

[0032] The computing systems 102(1) and 102(2) can communicate with one or more key management (KM) computing devices 119 via one or more networks 106. For example, the KM computing devices 119 can be configured to provide encryption keys 120, which can include at least the KEK discussed herein, to the computing systems 102 in accordance with the KMIP standard. In some cases, there may be multiple KM computing devices 119 to provide redundancy in the event that one of the KM computing devices 119 fails. Each KM computing device 119 can execute an instance of a key management program 121 that can manage key generation and provision of keys to the corresponding computing system 102, as well as perform other key management functions, as discussed further below.

[0033] In addition, at least some of the service computing devices 112 may be capable of communicating with a plurality of client devices 122(1)-122(N) via one or more networks 106. Each client device 122(1)-122(N) may include a respective instance of a client application 126(1)-126(N) that may be executed on the respective client device 122(1)-122(N), such as for communicating with the respective service computing device 112, e.g., for sending data objects 130 for storage by the computing system 102 and / or for retrieving data objects 130 stored by the computing system 102. Users 128(1)-128(N) may be associated with the respective client devices 122(1)-122(N). In some cases, the client application 126 may include or may be operated by a browser, while in other cases, the client application 126 may include any other type of application having communication functionality that enables communication with the service computing device 112 via one or more networks 106.

[0034] In some cases, a user 128 and / or client device 122 and / or client application 126 may be assigned to access a service computing device 112 at a particular computing site location 104 among the plurality of computing site locations 104. For example, if a first computing site location 104(1) is located in Boston, and the user 128(1) is an employee working in the Boston area, the user 128(1) may be assigned to access the service computing device 112(1) but not other service computing devices 112(2) at a second computing site location 104(2).

[0035] In some examples, various users 128, user groups 128 corresponding to namespaces, tenants, or other entities may be authorized to access only certain of the service computing devices 112 at certain of the site locations 104, such as for load balancing, limiting employee access to local office systems, etc. Furthermore, while two computing systems 102(1) and 102(2) and computing site locations 104(1) and 104(2) are shown in this example, in other examples a different number of systems / storage locations may be used, such as more than two, with the upper limit being based on practicality and diminishing returns rather than technical feasibility.

[0036] In addition, the first computing system 102(1) may be able to communicate with the first network storage device 108(1) via one or more networks, and the second computing system 102(2) may be able to communicate with a second network storage device 108(2) that is different from the first network storage device 108(2) via one or more networks 106. For example, the first network storage device 108(1) may be geographically remote from the second network storage device 108(2). In some cases, the network storage devices 108(1) and 108(2) may be referred to as "cloud storage devices" or "cloud-based storage devices" and may implement a lower cost per megabyte / gigabyte storage solution than the local storage system 114. Alternatively, in other examples, the first network storage device 108(1) and the second network storage device 108(2) may be in the same data center or other same geographic location.

[0037] The one or more networks 106 may include any suitable network, including a wide area network (WAN), such as the Internet; a local area network (LAN), such as an intranet; a wireless network, such as a cellular network; a local wireless network, such as Wi-Fi; and / or short-range wireless communications, such as Wired networks, including fiber channel, optical fiber, Ethernet or any other such network, direct wired connection or any combination thereof. Therefore, one or more networks 106 can include wired and / or wireless communication technology. The components used for such communication can depend at least in part on the type of network, the selected environment, or both. The protocols used to communicate through such networks are well known and will not be discussed in detail herein. Therefore, the service computing device 112, the KM computing device 119, the network storage device 108 and the client device 122 can communicate through one or more networks 106 using wired or wireless connections and combinations thereof.

[0038] In the illustrated example, assume that first user 128(1) uses first computing system 102(1) to store data object 130. For example, first user 128(1) may send object 130 to serving computing device 112(1) for storage by first computing system 102(1). In some cases, first computing system 102(1) may store a copy of object 130 locally as part of local object data 118(1). For example, serving computing device 112 may use a dedicated DEK ( Figure 1 1). Additionally or alternatively, the service computing device 112(1) may send the encrypted object data 132 of the object 130 to the network storage device 108(1) for storage with the object data 110(1). After encryption of the object data, the service computing device 112(1) may store the DEK as part of the metadata associated with the data object 130 in the metadata data structure 116(1). In addition, the service computing device 112(1) may encrypt the DEK using a KEK corresponding to the first user 128(1). For example, if the first user 128(1) is associated with a tenant or other entity, the KEK corresponding to the tenant or other entity may be used to encrypt the DEK. In other examples, the first user may be an entity that does not share data with other entities and has a KEK that is not shared with any other users. Furthermore, although additional variations are discussed below, many other variations will be apparent to those skilled in the art having the benefit of the disclosure herein.

[0039] In some examples, the distributed computing system 100 of the present disclosure may be deployed in a geographically distributed manner, for example, for data recovery and / or concurrent access purposes. Synchronous or asynchronous data replication may be used to transfer data to one or more remote computing systems 102, such as between computing systems 102(1) and 102(2) and / or between computing systems 102(1), 102(2) and a remote computing system 102. Figure 1 Between other computing systems not shown.

[0040] Figure 2 1 shows selected example components in an example configuration of a computing system 102 according to some embodiments. In some examples, computing system 102 may correspond to the example configuration described above with respect to FIG. Figure 1 The computing system 102 (1) and / or 102 (2) discussed above. The computing system 102 includes a plurality of service computing devices 112-1 through 112-M (where M is a positive integer), and which may correspond to the computing devices 112-1 through 112-M described above. Figure 1The service computing devices 112(1) and / or 112(2) are discussed. The service computing devices 112-1 through 112-M can communicate with or otherwise couple to one or more storage systems 202, such as via one or more networks 106, which in some examples can provide local storage devices 114. In some cases of the illustrated system, the one or more networks 106 may include a LAN, a storage area network (SAN) such as a Fibre Channel network, etc., but, as discussed elsewhere herein, implementations herein are not limited thereto and may include other types of networks, direct connections, etc.

[0041] In some examples, the service computing device 112 may include one or more servers or other types of computing devices that may be embodied in any number of ways. For example, in the case of a server, at least a portion of the program, other functional components, and data storage may be implemented on at least one server, such as in a plurality of servers, a server farm, a data center, a cloud-hosted computing service, etc., although other computer architectures may additionally or alternatively be used. In the example shown, the service computing device 112 includes or may have associated therewith one or more processors 210, one or more computer-readable media 212, and one or more communication interfaces 214.

[0042] Each processor 210 may be a single processing unit or multiple processing units, and may include a single or multiple computing units or multiple processing cores. The processor 210 may be implemented as one or more central processing units, microprocessors, microcomputers, microcontrollers, system-on-chip processors, digital signal processors, state machines, logic circuits, graphics processors, and / or any device that manipulates signals based on operating instructions. As an example, the processor 210 may include one or more hardware processors and / or logic circuits of any suitable type that are specially programmed or configured to perform the algorithms and processes described herein. The processor 210 may be configured to obtain and execute computer-readable instructions stored in the computer-readable medium 212, which may be executed to program the processor 210 to perform the functions described herein.

[0043] The computer-readable medium 212 may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). For example, the computer-readable medium 212 may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage devices, solid-state storage devices, tapes, disk storage devices, storage arrays, network attached storage devices, storage area networks, cloud storage devices, or any other medium that can be used to store the desired information and can be accessed by a computing device. Depending on the configuration of the service computing device 112, the computer-readable medium 212 may be a tangible non-transient medium to the extent that when referred to, the non-transient computer-readable medium excludes media such as energy, carrier signals, electromagnetic waves, and / or signals themselves. In some cases, the computer-readable medium 212 may be included in the service computing device 112, while in other examples, the computer-readable medium 212 may be partially separated from the service computing device 112. For example, in some cases, the computer-readable medium 212 may include a portion of the storage in the storage system 202.

[0044] The computer-readable medium 212 may be used to store any number of functional components that can be executed by the processor 210. In many embodiments, these functional components include instructions or programs that can be executed by (one or more) processors 210 and, when executed, specifically program (one or more) processors 210 to perform actions attributed to the service computing device 112 herein. The functional components stored in the computer-readable medium 212 may include a server program 216, which can communicate with a client device, such as for sending data objects to the client device and receiving data objects from the client device. As discussed elsewhere herein, the functional components may also include a storage management program 218, which may encrypt and store object data, store metadata for object data, decrypt object data, and manage KEKs and DEKs used for encryption and decryption. In addition, the storage management program 218 may perform other storage management functions known in the art. In some cases, the functional components may be stored in a storage portion of the computer-readable medium 212, which is loaded into a local memory portion of the computer-readable medium 212 and executed by one or more processors 210.

[0045] In addition, the computer-readable medium 212 may store data and data structures used to perform the functions and services described herein. For example, the computer-readable medium 212 may store metadata data structures 116, such as a metadata database, which may include DEKs 219 and other metadata 220 for data objects stored by the computing system 102. In addition, the computer-readable medium 212 may store key data structures 115, which may include KEKs 222, each of which may be associated with a UUID (universally unique identifier, which is described above with respect to Figure 1 The service computing device 112 may also include or maintain other functional components and data in the computer-readable medium 212, which may include programs, drivers, etc., and data used or generated by the functional components. In addition, the service computing device 112 may include many other logical, programming, and physical components, of which those described above are merely examples relevant to the discussion herein.

[0046] The communication interface 214 may include one or more interfaces and hardware components for enabling communication with various other devices, such as through one or more networks 106. Thus, the communication interface 214 may include or may be coupled to one or more ports that provide a connection for communicating with the storage system 202, and one or more ports that provide a connection to the network 106 for communicating with the client device 122. For example, as otherwise listed elsewhere herein, the communication interface 214 may enable communication through one or more of a LAN, the Internet, a cable network, a cellular network, a wireless network (e.g., Wi-Fi) and a wired network (e.g., Fiber Channel, fiber optic, Ethernet), a direct connection, and a short-range communication (such as BLUETOOTH, etc.).

[0047] In some examples, storage system 202 may include one or more storage computing devices 230, which may include one or more servers or any other suitable computing devices, such as any of the examples discussed above with respect to service computing device 112. Storage computing devices 230 may each include one or more processors 232, one or more computer-readable media 234, and one or more communication interfaces 236. For example, processor 232 may correspond to any of the examples discussed above with respect to processor 210, computer-readable media 234 may correspond to any of the examples discussed above with respect to computer-readable media 212, and communication interface 236 may correspond to any of the examples discussed above with respect to communication interface 214.

[0048] In addition, the computer-readable medium 234 may include a stored program 238 as a functional component executed by one or more processors 232 for managing data storage on a storage device 240 included in the storage system 202. The storage device 240 may include one or more controllers 242 associated with the storage device 240 for storing data on one or more local storage devices 114. For example, the controller 242 may control the array 244, such as for configuring the array 244 in a RAID configuration, an erasure coding configuration, and / or any other suitable storage configuration. The local storage device 114 may be any type of storage device, such as a hard disk drive, a solid state drive, an optical drive, a tape, a combination thereof, and the like. In addition, although several examples of computing systems have been described herein, many other systems capable of implementing the distributed object storage and replication techniques herein will be apparent to those skilled in the art having the benefit of the disclosure herein.

[0049] The computing system 102 can be configured to minimize the number of KEKs 222 stored on the KM computing device 119, such as by allowing each entity (such as a user, namespace, tenant, etc.) to create only one KEK 222. For example, in some cases, data can be divided according to tenants. For example, tenants (e.g., organizations, companies, user groups, etc.) generally do not want to keep their data private and protected from other tenants. In addition, different tenants can have different namespaces. A namespace may include a collection of data objects. In some cases, each namespace may include a private file system relative to other namespaces. In addition, access to one namespace of a tenant does not necessarily grant the user access to other namespaces of the tenant.

[0050] Additionally, tenants can be implemented as a hierarchy, in that a tenant can contain subtenants. A top-level tenant can be a tenant without a parent tenant, such as an enterprise, company, organization, or other entity. A subtenant can be a tenant whose parent tenant is another tenant, for example, the financing arm of an enterprise can be a subtenant of a top-level tenant (which is an enterprise). A default tenant can be a top-level tenant that contains only a default namespace.

[0051] Depending on the desired level of security, in some examples, a single KEK may be assigned to all data associated with a tenant. Alternatively, in other examples, to achieve a higher level of security, a single KEK may be assigned to each different namespace of a tenant, to each user associated with a tenant, or any of many other variations based on rules applicable to a specific entity (such as a specific tenant, namespace, user, etc.).

[0052] In the examples herein, the process for obtaining a KEK for an entity may include multiple steps that utilize knowledge of the KMIP to limit the number of KEKs created when multiple service computing devices 112 and / or computing systems 102 (e.g., a cluster) need a new KEK. As described above, a single KEK may be created and associated with a computing system 102, or a tenant, or a namespace, or an individual user who does not wish to share a KEK with others. Initially, when a service computing device 112 is triggered to obtain a new KEK, the service computing device 112 may send a key request 250 to request all active KEKs and pre-active KEKs 222 associated with a particular entity from the KM computing device 119. For example, if a currently active KEK with a recent initialization date is still valid, the service computing device 112 may use that KEK.

[0053] On the other hand, if there is no currently active KEK or the active KEK has been destroyed, the service computing device 112 may determine if there are any pre-active KEKs. For example, a "pre-active" key that has been generated but not yet activated according to the KMIP standard. Activation can only be performed on a key that is in a pre-active state. The activation operation changes the key state to "active" and sets the activation date to the current date and time.

[0054] If there is no pre-active KEK, the service computing device 112 can instruct the KM computing device to create one. The service computing device 112 can then request all active KEKs and pre-active KEKs from the KM computing device again, and if an active KEK with a valid last initialization date is received, another service computing device 112 may have caused the active KEK to be activated between the first key request and the second key request. In this case, the service computing device 112 can use the received active KEK for data encryption, and can instruct the KM computing device 119 to destroy all other pre-active KEKs on the KM computing device 119.

[0055] In other cases, if no active KEK is received in response to the second request, the service computing device 112 may select the pre-active KEK with the earliest initialization date for activation. For example, by implementing a rule that requires the earliest initialization date to be selected, the algorithm ensures that any other service computing device 112 that may also be attempting to create a valid active KEK at the same time will detect and select the same pre-active KEK. Therefore, the service computing device 112 may send an instruction to the KM computing device 119 to activate the selected pre-activated KEK on the KM computing device 119. If the instruction fails, it may be assumed that another service computing device 112 has already activated the selected KEK, and the service computing device 112 may then send a request to obtain the now active KEK from the KM computing device 119 based on the identifier of the KEK and its activity status.

[0056] On the other hand, if there is no activated KEK at this time, the creation operation fails. Therefore, the service computing device 112 can instruct the KM computing device 119 not to remove any pre-active KEKs and avoid further steps. As another alternative, the service computing device 112 can repeat the aforementioned operations when the KM computing device 119 is available. On the other hand, when the active KEK has been successfully created, the KM computing device 119 can be instructed to distribute the activated KEK to all other service computing devices 112 in the computing system 102 for inclusion in the key data structure of each of the service computing devices 112, so that when a specific entity needs a valid active KEK, the other service computing devices 112 do not need to contact the KM computing device 119. In addition, after the KEK is activated, any other pre-active KEKs that may have been created can be destroyed.

[0057] As described above, the service computing device 112 may include a key data structure 115, which may be in the form of a cache in memory or the like, that maintains previously used KEKs 222 in memory so that each service computing device 112 does not have to contact the key management computing device 119 when a particular KEK is needed. As one example, when each individual service computing device 112 boots up, the service computing device 112 may contact any configured KM computing device 119 and may retrieve all keys with a custom attribute (“x-User-Parent-Location-UUID”) that associates the KEK 222 with the particular computing system 102 of which the service computing device 112 is a member or otherwise associated. Each service computing device 112 maintains a copy of these KEKs 222 in the key data structure 115 for use in responding to client requests involving one of the KEKs 222.

[0058] In the key data structure 115, the KEK 222 can be organized into several overlapping mappings to improve the efficiency of retrieving one or more keys based on certain qualifiers. These internal key data structure mappings can include a mapping of key UUIDs to corresponding KEKs, which is a master mapping of the UUID of the KEK to the KEK object itself, enabling fast lookup of a specific KEK based on the UUID. In addition, UUIDs retrieved from other mappings can be used with this mapping to retrieve a specific KEK for encryption / decryption purposes.

[0059] Additionally, the key data structure 115 may include a mapping of a "location" (e.g., entity associated with a key, such as a tenant, namespace, or user) UUID and KM computing device name to the active KEK UUID currently being used for ingestion, which allows a lookup of a key UUID to be performed based on a combination of the location / entity associated with the KEK and the KM computing device 119 that is maintaining the particular KEK. This information may be used to determine the particular KEK 222 currently being used to encrypt newly ingested data objects for a given entity and KM computing device combination.

[0060] In addition, the key data structure 115 may include a mapping of a computing system UUID and a computing system type to a set of all KEK UUIDs. This enables tracking of all KEKs associated with a particular computing system 102, including current ingestion keys and previously used keys. Additionally, the key data structure 115 may include a mapping of a KM computing device name to a set of ingestion KEK UUIDs, which enables tracking of all active KEKs currently designated for ingestion and associated with the KM computing device. Additional mappings may include a mapping of a KM computing device name to a set of all KEK UUIDS to enable tracking of all KEKs associated with a particular KM computing device 119. Furthermore, while several example mappings are set forth above, many variations will be apparent to those skilled in the art having the benefit of the disclosure herein.

[0061] The service computing device 112 herein can implement KEK verification, rotation and deactivation policies, which can be performed by a module executed by executing the storage management program 218 or other suitable programs. For example, recognized security best practices prevent the use of the same encryption key for an indefinite period of time because destruction or other failures in security may occur, and the key may become accessible to a third party or may be leaked. For example, three time periods can be configured by an administrator, etc. The encryption period can be a configurable total amount of time that the KEK is expected to be used, such as 18 months or other desired time period. After the expiration of the encryption period, the KEK can be deactivated. The deactivated key can still be used for decryption, but when the deactivated key needs to be used, an alert can be sent to the administrator or other user, such as an indication that the key update of the deactivated key has not been fully completed and may need to be audited to provide the administrator with a key update.

[0062] In some examples herein, the crypto period may be divided into three different periods, namely (1) a valid period, during which the KEK is used to encrypt the DEK of newly ingested data; (2) a rotation period following the valid period, during which the KEK is deactivated, no longer used during ingestion, and replaced by a newly activated KEK, but key updates have not yet begun; and (3) a key update period, during which DEKs that have been encrypted by the KEK are decrypted and re-encrypted using the newer KEK. As an example, each of these three periods may be 6 months, and thus the total crypto period may be 18 months, but any of these times may be configured differently by an administrator or user with sufficient system privileges.

[0063] The key renewal period should be long enough to ensure that all DEKs that have been encrypted with the KEK are unwrapped and then re-encrypted using the last or currently active KEK of the corresponding entity. After the key renewal period (and crypto-period) expires, the KEK may be deactivated. As described above, after the KEK is deactivated, the deactivated KEK may be maintained for an additional period of time (e.g., the amount of time used to ensure that no objects have associated DEKs that are still encrypted with the deactivated KEK), during which time the deactivated KEK may still be used to decrypt the DEKs if any DEKs that are still wrapped with the particular deactivated KEK are located. When this occurs, an alert may be sent to an administrator or other user to provide notification that the key renewal process may not have been fully completed and should be audited. In some cases, the KEK may be automatically deactivated after the expiration of a key renewal period (e.g., the last 6 months) or a crypto-period (e.g., 18 months). If the KEK is still in use when it is deactivated, an alert may be generated; otherwise, the KEK may be destroyed. In some examples, any unused deactivated KEKs may be destroyed. Additionally, in some instances, there may be management processes that may deactivate or compromise a KEK before the crypto period expires.

[0064] To help limit the impact in the event that a KEK is compromised, the KEKs herein may be rotated and replaced periodically. The examples herein may implement this strategy by providing a configurable rotation period value, which may be checked against the creation date of the key (also referred to as the "initial date" of the key) on the KM computing device 119 when an active KEK is retrieved from the key data structure 115 for use as an ingestion key for a particular entity. When the time comes to rotate the active KEK, the particular KEK may be marked or otherwise indicated as "deactivated" and no longer used as a DEK for encrypting ingested data. A deactivated KEK may still be used to decrypt the DEK to decrypt data previously encrypted using the KEK and DEK combination. A new KEK may be created / activated and used to replace a deactivated / rotated KEK.

[0065] Additionally, a separate program may be executed to "validate" each KEK once per a configurable validation period (e.g., every 24 hours or other desired time period). For example, validating a KEK may involve retrieving an updated version of the KEK from the KM computing device 119 to ensure that the key data structure 115 has a new version of each KEK. If an updated version of a KEK needs to be disabled or deactivated, appropriate action may be taken locally.

[0066] Examples herein may also implement a KEK key update and destruction policy. For example, the storage management program 218 or other suitable program executed on each service computing device 112 may include an internal background service that continuously polls objects to determine whether the corresponding DEK should be re-encrypted with a new KEK to replace a retired KEK.

[0067] In some examples, when the life of a KEK reaches a rotation period, the KEK can be deactivated and replaced by a new active KEK, which can then be used for object ingestion during its validity period. During the key update period, the deactivated KEK can be replaced by the currently active KEK. In order to replace the KEK, the currently checked DEK can be read by decrypting / unpacking the DEK with the corresponding deactivated KEK, and then the DEK can be re-encrypted (re-wrapped) using the currently active KEK. The re-wrapped DEK is associated with the same object metadata as before for future decryption of the corresponding object data, and the system metrics can be updated for disaster recovery. The background service can check all KEKs maintained by all configured KM computing devices 119 at certain intervals. Any KEK 222 that has reached a specified rotation period (whether they are currently active or otherwise) can be rotated, deactivated, and deactivated at the end of the key update period, and then finally destroyed. Therefore, the strategy implemented herein is intended to replace all KEKs before the cryptographic period of the corresponding KEK expires. Any KEK that is no longer used by any object and is not active can be destroyed. However, unless all KEKs on the KM computing device are destroyed, the KM computing device itself cannot be deactivated.

[0068] The service computing devices 112 can communicate with each other, such as for providing information related to key cache updates or other information related to KEK. According to the embodiments of this article, any delay in responding to a client's request for data can be minimized by ensuring that the KEK 222 is available on any service computing device that can be requested by the service client. In addition, any KM computing device contact that causes the cache to change can be distributed to all service computing devices 112. When it is desired to use the created or changed KEK, or when the rotation cycle of the KEK expires, this function prevents other service computing devices from needing to contact the KM computing device. In some cases, the KM computing device 119 is contacted during the ingestion period. As an example, this can occur when a request to replace the KEK is made or the KEK is marked as damaged. In these cases, the cache allocation request does not wait for the KM computing device to respond. In addition, when the existing KEK is verified (for example, every 24 hours), the result is distributed to other service computing devices by the service computing device to prevent them from unnecessarily contacting the KM computing device to verify the same KEK.

[0069] In the examples herein, background KEK creation and validation is not affected by contacting the KM computing device 119 during the ingestion of user data. For example, a background task can be used to create a new active KEK or validate an active KEK for ingesting data for a particular entity. The currently valid active KEK can be used when executing a background task to prepare for future operations using a new or updated KEK.

[0070] In the examples herein, a single KEK can be quickly generated for a user across multiple service computing devices 112 and multiple computing systems 102. No inter-node messages or additional communications with users or client computing devices are required. In addition, no matter how many nodes may simultaneously request to activate the KEK of a particular entity, only one active KEK is generated, which minimizes the number of KEKs generated by each entity. In addition, in some examples, a background process can be executed to maintain the consistency of the KEK 222 in the key data structure 115 without interrupting user requests. For example, a request to the KM computing device 119 can be executed in the background, such as when a key rotation process determines that the KEK is ready for rotation and deactivation. The active KEK generated by the KM computing device operation can be distributed to all service computing devices 112 upon completion, rather than having each service computing device 112 wait to request a new / updated KEK as needed, such as after receiving a user data request.

[0071] In addition, embodiments herein can maximize data protection by employing a unique DEK for each corresponding storage object while minimizing the number of KEKs that the KM computing device 119 needs to provide to the service computing device 112, such as by using only one KEK per data sharing entity. Furthermore, providing the key data structure 115 on each service computing device 112 can also be used to minimize network traffic between service computing devices 112 and between service computing devices 112 and KM computing devices 119. As described above, the key data structure includes multiple internal mappings that enable quick access to the correct KEK or set of KEKs in memory at each service computing device 112. Many other advantages and benefits of embodiments herein will be apparent to those skilled in the art.

[0072] Figure 3300 is a flowchart illustrating an example process 300 for obtaining an active key according to some embodiments. The process is shown as a collection of boxes in a logical flow chart, which represents a series of operations, some or all of which can be implemented in hardware, software, or a combination thereof. In the context of software, a box can represent computer executable instructions stored on one or more computer-readable media, which, when executed by one or more processors, program the processor to perform the operations. Typically, computer executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific data types. The order in which the boxes are described should not be interpreted as limiting. Any number of the described boxes can be combined in any order and / or in parallel to implement the process or an alternative process, and all boxes do not need to be executed. For the purpose of discussion, the process is described with reference to the environment, framework, and system described in the examples of this article, although the process can be implemented in various other environments, frameworks, and systems. In some cases, process 300 can be performed at least in part by one or more service computing devices 112 or other computing devices in one or more computing systems 102, such as in the above description of Figure 1 In the distributed computing system 100 discussed.

[0073] At 302, the computing system may detect or otherwise receive a trigger to initiate process 300 for obtaining a new active KEK for an entity. As one example, the computing device may receive a data request for an entity for which the computing device does not have an active KEK. As another example, the computing device may determine that the current active KEK should be deactivated and a new active KEK should be obtained.

[0074] At 304, the computing device may send a request to the KM computing device to obtain all active KEKs and pre-active KEKs for a particular entity. For example, the computing device may send a request to the key management computing device for information related to at least one of any active KEK associated with a particular entity and any pre-active KEK associated with the entity.

[0075] At 306, the computing device may determine whether a valid active KEK is received in response to the request. If so, the process proceeds to 308. If not, the process proceeds to 310.

[0076] At 308, when a valid active KEK is returned, the computing device may determine that a new KEK is not needed, and the process may return to 302 to await the next triggering event.

[0077] At 310, when a valid active KEK is not returned in response to the first request, the computing device may determine whether a pre-active KEK is returned. For example, a pre-active KEK is a KEK that may have been created but not yet activated. If not, the process proceeds to 312. If yes, the process proceeds to 314.

[0078] At 312 , when a pre-active KEK is not returned, the computing device may send an instruction to create a pre-active KEK to the KM computing device.

[0079] At 314, the computing device may send a second request to the KM computing device to obtain all active KEKs and pre-active KEKs. The second request may help determine whether another service computing device has caused an active KEK to be created prior to the current process.

[0080] At 316, the computing device may determine whether a valid active KEK was returned in response to the second request. If so, the process proceeds to 326. If not, the process proceeds to 318.

[0081] At 318, the computing device may send an instruction to the KM computing device to activate the oldest pre-active KEK. This rule may cause all service computing devices that may simultaneously attempt to obtain an active KEK for a particular entity to select the same pre-active KEK for activation, thereby avoiding the creation of more than one active KEK for the entity.

[0082] At 320, the computing device may determine whether an active KEK is created in response to the instruction. If so, the process moves to 322. If not, the process moves to 324.

[0083] At 322 , when the active KEK is created in response to the instruction, the computing device may distribute the active KEK to other service computing devices in the computing system.

[0084] At 324, the computing device may send a request to the KM computing device to obtain an active KEK that has been activated by another service computing device before the computing device requested activation. Alternatively, the computing device may directly receive an active KEK from another service computing device that successfully requested creation of an active KEK.

[0085] At 326 , the computing device may send instructions to the KM computing device to request that the KM computing device destroy any pre-active KEKs that may still remain, and the process may return to 302 to await the next triggering event.

[0086] The example processes described herein are merely examples of processes provided for discussion purposes. Many other variations will be apparent to those skilled in the art based on the disclosure herein. In addition, although the disclosure herein sets forth several examples of suitable frameworks, architectures, and environments for executing processes, the embodiments herein are not limited to the specific examples shown and discussed. In addition, the present disclosure provides various example implementations as described and shown in the accompanying drawings. However, as will be known or will become known to those skilled in the art, the present disclosure is not limited to the embodiments described and shown herein, but may be extended to other embodiments.

[0087] Figure 4 An example key state data structure 400 is shown according to some embodiments. In this example, the key state data structure 400 includes a key state column 402, an encryption capability column 404, and a decryption capability column 406. As shown at 408, when the key is in a pre-active state, the key is not allowed to be used for encryption, as shown at 404, and is not allowed to be used for decryption, as shown at 406. As shown at 410, when the key is in an active state, the key can be used for encryption, as shown at 404, and can be used for decryption, as shown at 406. As shown at 412, when the key is deactivated, the key may not be used for encryption, but can still be used for decryption, and if the key is used for decryption, a warning or other alert may be sent to an administrator. As shown at 414, when the key is compromised, the key may not be used for encryption, but can be used for decryption, and if the key is used for decryption, a warning may be sent to an administrator. As shown at 416, when the key is destroyed, the key cannot be used for encryption or decryption. As indicated at 418, when the key is deactivated, the key is not allowed to be used for encryption, but can still be used for decryption, and no warning needs to be sent to the administrator.

[0088] Figure 5 An exemplary key attribute data structure 500 is shown according to some specific implementations. In this example, the key attribute data structure 500 includes a key attribute column 502, a "set by" column 504, and a description column 506. As indicated at 508, an identifier (ID) can be set by the KM computing device, as indicated at 504, and can be an ID that uniquely identifies a particular key to the KM computing device 119 within the system. As indicated at 510, an initialization date attribute can be set by the KM computing device, and can be the date and time when the KM computing device created the particular key. As indicated at 512, a retrieval time can be the date and time when the key was first retrieved from the KM computing device by one of the service computing devices in the computing system.

[0089] As shown at 514, the UUID attribute may be created by a service computing device that may assign a UUID to a key, and the UUID may be a unique identifier within the system (or other individually distinguishable ID) that may be used, such as to retrieve a particular key from the key data structure 115. As shown at 516, the parent location UUID may be a unique identifier within the system (or other individually distinguishable ID) that is created by the service computing device to identify the computing system 102 that uses the key. As shown at 518, the primary location UUID may be a unique identifier within the system (or other individually distinguishable ID) that is created by the service computing device to identify the entity (e.g., tenant, namespace, user) associated with the key. As shown at 520, the additional location UUID may be a unique ID within the system (or other individually distinguishable ID) that is created by the service computing device to associate the key with any additional associated users, tenants, namespaces, etc.

[0090] Figure 6 An example active key state data structure 600 is shown in accordance with some embodiments. In this example, the active key state data structure 600 includes an "active key state" column 602, a "for new data encryption" column 604, a "replacement in existing data" column 606, a "time since creation" column 608, and an "action" column 610. Figure 4 As discussed, an "active" key may be a KEK that is currently used for both encryption of the DEK and decryption of the DEK for the corresponding entity. As shown at 612, while the key is within its validity period, e.g., during the first 6 months (or other configurable time period) after activation, the key may be used to encrypt the DEK of new data, as shown at column 604, and no key replacement or other action may be taken.

[0091] As indicated at 614, when a key has reached a rotation period, the key is deactivated and is not used to encrypt new data unless a new active KEK is not yet available (i.e., being retrieved from the KM computing device). The KEK may enter a rotation state at a user-configurable time (e.g., 6 months to a year after activation), when the key's validity period ends and the KEK is no longer "active." At the end of the rotation period, the key update state begins.

[0092] As shown in 616, when the key state moves to key update, the KEK is still not allowed to be used for encryption associated with new data, but can be used for decryption to replace the KEK with the most recent active KEK. For example, when an encrypted DEK encrypted with the KEK is found, the KEK is replaced by decrypting the DEK and re-encrypting the DEK with the most recent active KEK.

[0093] As shown in 618, when the key state changes to expire, for example, at the end of the key renewal period, which also corresponds to the end of the encryption period, the KEK is deactivated, but not yet destroyed, because destruction may result in data loss. If a DEK that is still encrypted with the deactivated KEK is located, the KEK is required to decrypt the DEK, and an alert is sent to the administrator to notify the administrator that the deactivated KEK is required to decrypt the DEK, which may indicate that the key renewal process for the KEK is not fully completed.

[0094] When the key status is "full", the key is not used for further encryption, as shown at 620. The full status indicates that the maximum byte protection threshold has been reached for this particular KEK, and a new KEK should be activated to protect the additional DEK for the additional data. For example, there may be a threshold maximum amount of data that each KEK is allowed to access, and when that threshold is reached, a new KEK may be activated regardless of whether the KEK currently in use is still in a valid state.

[0095] Figure 7 Selected example components of one or more KM computing devices 119 according to some embodiments are shown. The KM computing device 119 may include one or more servers or other types of computing devices that can be embodied in any number of ways. For example, in the case of a server, the programs, other functional components, and data can be implemented on a single server, a server cluster, a server farm or a data center, a cloud-hosted computing service, etc., although other computer architectures may be used in addition or alternatively. Multiple KM computing devices 119 can be located together or separately and organized as, for example, servers, virtual servers, server libraries, and / or server farms. The described functionality can be provided by servers of a single entity or enterprise, or can be provided by servers and / or services of multiple different entities or enterprises.

[0096] In the illustrated example, the KM computing device 119 includes or may have one or more processors 702, one or more computer-readable media 704, and one or more communication interfaces 706 associated therewith. Each processor 702 may be a single processing unit or multiple processing units, and may include a single or multiple computing units or multiple processing cores. The processor 702 may be implemented as one or more central processing units, microprocessors, microcomputers, microcontrollers, system-on-chip processors, digital signal processors, graphics processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. As an example, the processor 702 may include one or more hardware processors and / or logic circuits of any suitable type that are specially programmed or configured to perform the algorithms and processes described herein. The processor 702 may be configured to obtain and execute computer-readable instructions stored in the computer-readable medium 704, which may program the processor 702 to perform the functions described herein.

[0097] The computer-readable medium 704 may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storing information (such as computer-readable instructions, data structures, program modules or other data). For example, the computer-readable medium 704 may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage devices, solid-state storage devices, tape and disk storage devices, network or cloud storage devices, array storage devices, network attached storage devices, storage area networks, or any other medium that can be used to store the desired information and can be accessed by the computing device. Depending on the configuration of the KM computing device 119, the computer-readable medium 704 may be a tangible non-transient medium to the extent that when mentioned, the non-transient computer-readable medium excludes media such as energy, carrier signals, electromagnetic waves and / or signals themselves. In some cases, the computer-readable medium 704 may be in the same location as the KM computing device 119, while in other examples, the computer-readable medium 704 may be partially away from the KM computing device 119.

[0098] The computer-readable medium 704 may be used to store any number of functional components that are executable by the processor 702. In many embodiments, these functional components include instructions or programs that are executable by the processor 702 and, when executed, specifically program the processor 702 to perform the actions attributed herein to the KM computing device 119. The functional components stored in the computer-readable medium 704 may include the key management program 121, which may include one or more computer programs, applications, executable codes, or portions thereof.

[0099] In addition, the computer-readable medium 704 can store data, data structures, and other information used to perform the functions and services described herein. For example, the computer-readable medium 704 can store keys 120, including KEK 222. The KM computing device 119 can also include or maintain other functional components and data, which can include programs, drivers, etc., as well as data used or generated by the functional components. In addition, the KM computing device 119 can include many other logical, programming, and physical components, of which the above-mentioned ones are merely examples relevant to the discussion herein.

[0100] The one or more communication interfaces 706 may include one or more software and hardware components for enabling communications with various other devices, such as via one or more networks 106. For example, as otherwise listed elsewhere herein, the communication interface 706 may enable communications via LANs, the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., Fiber Channel, fiber optic, Ethernet), direct connections, and short-range communications (such as etc.) in one or more communications.

[0101] Various instructions, methods and techniques described herein can be considered in the general context of computer executable instructions, such as computer programs and applications stored on computer readable media and executed by the processors herein. Generally, the terms program and application can be used interchangeably, and can include instructions, routines, scripts, modules, objects, components, data structures, executable codes, etc. for performing specific tasks or realizing specific data types. These programs, applications, etc. can be executed as native code, or can be downloaded and executed such as in a virtual machine or other just-in-time compilation execution environment. Generally, in various embodiments, the functions of programs and applications can be combined or distributed as needed. The implementation of these programs, applications and techniques can be stored on a computer storage medium or transmitted across some form of communication medium.

[0102] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. A system comprising: A computing system having a plurality of computing devices capable of communicating with a key management computing device over a network, wherein a first computing device of the plurality of computing devices is configured by executable instructions to perform operations comprising: sending a request to the key management computing device for information related to at least one of an active key encryption key (KEK) associated with an entity and a pre-active KEK associated with the entity; receiving, from the key management computing device, an indication that the key management computing device does not have an active KEK or a pre-active KEK associated with the entity; In response to the indication, sending to the key management computing device an instruction for creating a pre-active KEK for the entity; Based on a subsequent determination that there are a plurality of pre-active KEKs for the entity that are available from the key management computing device, sending an instruction to the key management computing device to activate the pre-active KEK having the earliest creation time; and An active KEK for the entity is received.

2. The system of claim 1, wherein the operations further comprise: The active KEK and an indication of successful activation of the active KEK are received from the key management computing device.

3. The system according to claim 1, wherein: The active KEK for the entity is received from a second computing device of the plurality of computing devices.

4. The system of claim 3, the operation further comprising receiving an indication that the instruction to activate the pre-active KEK was unsuccessful based at least on a request by the second computing device of the plurality of computing devices to activate the pre-active KEK having the earliest creation time before the instruction was received from the first computing device.

5. The system of claim 1, wherein the operations further comprise: An instruction is sent to the key management computing device to destroy any remaining pre-active KEK corresponding to the entity.

6. The system of claim 1, wherein the operations further comprise: The active KEK associated with the entity and a plurality of other active KEKs associated with other entities are periodically received from at least one of the key management computing device and one of the plurality of computing devices.

7. The system of claim 1, wherein the operations further comprise: After expiration of a first amount of time, the active KEK associated with the entity is deactivated, and a new active KEK associated with the entity is requested from the key management computing device.

8. The system according to claim 7, wherein: Deactivating the active KEK allows the deactivated KEK to be used to decrypt previously encrypted data encryption keys (DEKs), but not to be used to encrypt DEKs.

9. The system of claim 7, wherein the operations further comprise: After expiration of the second amount of time, a previously encrypted data encryption key (DEK) is decrypted using the deactivated KEK and the DEK is re-encrypted with a currently active KEK associated with the entity.

10. The system of claim 9, the operations further comprising: After expiration of a third amount of time, the deactivated KEK is deactivated, wherein after the deactivation, an alert is sent to a user based on the need for the deactivated KEK to decrypt a DEK previously encrypted using the now-deactivated KEK.

11. The system of claim 1, the operations further comprising: storing the active KEK in a data structure including a plurality of active KEKs; as well as Each active KEK is associated with a corresponding individually distinguishable identifier (ID) in the data structure.

12. A method comprising: sending, by a computing device, a request for information related to at least one of an active key encryption key (KEK) associated with an entity and a pre-active KEK associated with the entity to a key management computing device, wherein the computing device is one of a plurality of computing devices included in a computing system configured to store object data; receiving, from the key management computing device, an indication that the key management computing device does not have an active KEK or a pre-active KEK associated with the entity; In response to the indication, sending to the key management computing device an instruction for creating a pre-active KEK for the entity; Based on a subsequent determination that there are a plurality of pre-active KEKs for the entity that are available from the key management computing device, sending an instruction to the key management computing device to activate the pre-active KEK having the earliest creation time; and An active KEK for the entity is received.

13. The method according to claim 12, further comprising: The active KEK and an indication of successful activation of the active KEK are received from the key management computing device.

14. One or more non-transitory computer-readable media storing one or more programs executable by a first computing device among a plurality of computing devices in a computing system to configure the first computing device to perform operations comprising: sending a request to a key management computing device for information related to at least one of an active key encryption key (KEK) associated with an entity and a pre-active KEK associated with the entity; receiving, from the key management computing device, an indication that the key management computing device does not have an active KEK or a pre-active KEK associated with the entity; In response to the indication, sending to the key management computing device an instruction for creating a pre-active KEK for the entity; based on subsequently determining that there are a plurality of pre-active KEKs for the entity that are available from the key management computing device, sending an instruction to the key management computing device to activate the pre-active KEK having the earliest creation time; as well as An active KEK for the entity is received.

15. The one or more non-transitory computer-readable media of claim 14, the operations further comprising: The active KEK and an indication of successful activation of the active KEK are received from the key management computing device.

Images