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) or a pre-active KEK associated with an entity. The first computing device may receive an indication from the KM device 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. Thereafter, based on determining that there are multiple 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 the active KEK for the entity.

Description

[Technical Field]

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

[0002] Data may 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 may provide a messaging format to simplify the management of encryption keys. As an example, keys may be created on a KM computing device and provided to computing systems that use the keys to encrypt data. KMIP supports both symmetric and asymmetric encryption techniques. Furthermore, under KMIP, encryption keys may have a lifecycle with defined states, including a pre-active state, an active state, and an inactive state, before being discarded.

[0003] In some types of computing systems, a data encryption key (DEK) may be used to encrypt stored data. The DEK may itself be encrypted (wrapped) using a key encryption key (KEK), which may be used to encrypt and protect the DEK. For example, when it is desired to decrypt particular data, the corresponding KEK may be obtained and used to decrypt the corresponding DEK, which may then be used to decrypt the data. Once a key is created and used within a computing system, it is generally difficult to revoke or replace the key because there may be encrypted data within the system that requires a specific key for decryption. For example, if a key is revoked before decrypting the corresponding encrypted data, the encrypted data may be considered lost. However, key management and security may consume resources within a computing system. Therefore, minimizing the number of keys used within a computing system while avoiding data loss would improve the operation of the computing system. Summary of the Invention [Means for solving the problem]

[0004] In some implementations, a first computing device of a plurality of computing devices in a computing system may send 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 or 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. Thereafter, based on determining that there are multiple pre-active KEKs for the entity available from the key management computing device, the first computing device may send an instruction to the key management computing device to activate a pre-active KEK having an earliest creation time, and the first computing device may receive an active KEK for the entity. [Brief explanation of the drawings]

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

[0006] [Figure 1] FIG. 1 illustrates an example architecture of a distributed computing system configured to encrypt and decrypt data according to some implementations.

[0007] [Figure 2] FIG. 2 illustrates an example of selected components in an example configuration of a computing system according to some implementations.

[0008] [Figure 3]FIG. 3 is a flow diagram illustrating an example process for obtaining an active key according to some implementations.

[0009] [Figure 4] FIG. 4 illustrates an example of a key state data structure according to some implementations.

[0010] [Figure 5] FIG. 5 illustrates an example of a key attribute data structure according to some implementations.

[0011] [Figure 6] FIG. 6 illustrates an example of an active key state data structure according to some implementations.

[0012] [Figure 7] FIG. 7 illustrates an example of selected components of one or more KM computing devices according to some implementations. DETAILED DESCRIPTION OF THE INVENTION

[0013] Some implementations herein are directed to techniques and arrangements for encryption key management in a computing system, such as to minimize key encryption keys (KEKs) per entity and maximize performance in environments including multiple computing devices. In some examples, a computing system may minimize the number of KEKs stored on a key management (KM) computing device by ensuring that only one KEK is created per user, namespace, tenant, or other entity type. For example, operations based at least in part on KMIP may be used to create only one KEK even if multiple service computing devices, clusters, or other computing systems contemporaneously (e.g., at approximately the same time and / or prior to completion of the initial KEK request) request a new KEK for use by a particular entity.

[0014] 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. Furthermore, each service computing device may independently query and interact with a key management (KM) computing device in a manner such that only one active KEK is generated and shared across all service computing devices requiring a KEK for use by a particular entity, while pre-active keys created during the KEK acquisition process may be discarded. KEKs created by this process or otherwise obtained from a KM computing device may be cached on each service computing device to mitigate the need for frequent access to the KM computing device.

[0015] In some examples, when a service computing device is started, it may contact any configured KM computing devices and retrieve all keys with custom attributes indicating that the individual keys belong to the computing system to which the particular service computing device is associated. The retrieved keys may 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 may additionally be organized into several overlapping maps to optimize the efficiency of retrieving one or more keys based on specific qualifiers. Furthermore, the key data structure enables rotation, validation, rekeying, and retirement strategies to ensure that only fresh and valid keys are used for encryption, particularly if a particular key is compromised.

[0016] Additionally, if a KM computing device receives a communication from one of the service computing devices included in a computing system (such as a cluster or other type of computing system configuration including multiple service computing devices) that results in a change to the service computing device's key data structure, the change to the key data structure may be distributed to all other service computing devices in the computing system through indirect action of each of the other service computing devices in the computing system, or additionally or alternatively, through direct messaging from the KM computing device or service computing device that caused 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 they need a created or changed KEK.

[0017] In examples herein, interactions between KMIP clients and KM computing devices 119 allow for minimizing the number of requests from the client to the server (i.e., from the service computing device to the KM computing device). Additionally, the number of KEKs stored on the service computing device and the KM computing device is also minimized. For example, once a KEK has been used to encrypt data, it cannot be discarded to prevent data loss unless it is replaced by decrypting all data encryption keys (DEKs) encrypted using that KEK and re-encrypting those DEKs with the currently active replacement KEK. Furthermore, some examples herein may minimize key-related network traffic between the service computing device and the KM computing device. Additionally, some examples minimize or eliminate network traffic for user-based or time-critical requests, such as by providing the key data structures and key retrieval processes herein.

[0018] Additionally, 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, and even for each data object or other piece of data, for the highest level of protection, implementations provide an improvement over conventional techniques that use a shared KEK that may be shared between entities that would not otherwise share data. Furthermore, some examples herein do not use persistent storage external to the KM computing device to store the KEK, but rather use only a key cache or other type of ephemeral key data structure in a temporary memory location.

[0019] Implementation of features herein may be complicated by the multi-node nature of the computing systems herein. For example, multiple service computing devices (sometimes referred to as "nodes") may be used simultaneously to read and write data to storage. As a result, all of the service computing devices in the system may need to access the same key pool, which may congest traffic between the computing system and the KM computing devices without the provision of a multi-node key caching data structure according to implementations herein.

[0020] Some examples herein may employ background services to rotate KEKs on one or more of a per-object, per-user, per-namespace, per-tenant, or per-other entity basis, and may use metrics to determine when a particular KEK can be retired. For example, a process herein may determine when a particular KEK is no longer in use, such as by utilizing information obtained via KMIP, which may include a KEK lifecycle initialization date and a configured cryptoperiod that enable deactivation of the KEK. A process herein may further determine (e.g., from metrics maintained by a service computing device) that there are no longer any DEKs encrypted using a particular KEK (which may be identified within the system based on the particular KEK's unique identifier). Based on a determination that there are no longer any DEKs encrypted using the particular KEK, a process herein may retire the particular KEK. Examples herein may perform these functions in a manner that does not interrupt performance associated with user-initiated actions, such as data read or data write requests. The key rotation process herein may also provide for preserving the ability to reclaim an object, even if associated metadata is lost. Furthermore, employing a different KEK per user, namespace, tenant, or other entity type may increase the security of stored data while minimizing the total number of KEKs used by the computing system, based at least on providing only one active and valid KEK to meet the data protection requirements of each such entity. Some examples may use KMIP-specific key attributes such as "pre-active" and "active" to enable this functionality within high-performance multi-node and multi-cluster computing environments.

[0021] Some examples herein may be used in connection with the storage of data objects on storage devices, such as in an array of storage devices. 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. Furthermore, 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, etc.

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

[0023] A computing system herein may use individual KEKs to access stored objects through their associated DEKs, while a malicious actor may not be able to crack the DEK using patterns between encrypted objects. The computing system may assign a single KEK to each entity that stores data on the computing system. An entity may be an individual user, a tenant (e.g., an organization, a group of users, etc.), a namespace within a tenant, or an entire cluster of service computing devices. In some cases, a namespace and / or tenant may have data stored across several computing system sites that are geographically separate from one another and may provide a replication topology for disaster recovery, etc. In some examples, an individual universally unique identifier (UUID) may be associated with an individual KEK. For example, the UUID may be unique within a computing system or a group of computing systems that communicate with one another. When it is desired to decrypt stored data, a matching KEK may be obtained based at least in part on the individual UUID, and the decrypted KEK may be used to decrypt the data's DEK, which may then be used to decrypt the data itself.

[0024] Conventional techniques for multi-node key creation and storage typically rely on designating a particular node as a primary node responsible for communicating with a key server. This primary node may then service requests from other nodes to obtain keys from the key server. However, this configuration may contain a single point of failure, typically requiring additional redundancy fallback, if the primary node goes down. For example, if a different node takes over after the primary node fails, there may be inconsistent or redundant key server communications depending on timing. On the other hand, examples herein do not designate any computing device as a master node; instead, each service computing device can communicate independently and as needed with the KM computing device to request a KEK. As a result, examples herein significantly increase failure tolerance while minimizing the number of KM computing device requests to a similar amount as conventional techniques employing a primary node.

[0025] For purposes of illustration, some example implementations are described in the context of one or more computing systems that utilize a key-encrypting key to encrypt data encryption keys used to encrypt and decrypt data. However, implementations herein are not limited to the particular 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 in light of the disclosure herein.

[0026] FIG. 1 illustrates an example architecture for a distributed computing system 100 configured to encrypt and decrypt data according to some implementations. Multiple computing systems 102 are located within the distributed computing system 100 at multiple individual computing site locations 104, such as a first computing system 102(1) located at a first site location 104(1) and a second computing system 102(2) at a second site location 104(2). Additionally, while two computing systems 102 and computing site locations 104 are illustrated in this example, the number of computing systems 102 and computing site locations 104 in other examples is not limited to two and may be one or more computing systems 102 at one or more individual sites 104, ranging from one to hundreds of computing systems and sites, some or all of which may be geographically dispersed from one another. Additionally, in some examples, multiple computing systems 102 may be located at a single site 104, or individual computing systems 102 may be distributed across multiple sites 104.

[0027] Additionally, computing systems 102 may communicate with each other over one or more networks 106 and may further communicate with respective network storage 108. For example, a first computing system 102(2) may communicate with network storage 108(1) that holds object data 110(1) managed by the first computing system 102(1), and a second computing system 102(2) may communicate with network storage 108(2) that holds object data 110(2) managed by the second computing system 102(2). In some examples, network storage 108 may be provided by one or more commercial cloud-based storage providers, such as AMAZON®, MICROSOFT®, IBM®, GOOGLE®, HITACHI VANTARA®, etc., and may typically, although not necessarily, be located in a location remote from first computing site 104(1) and second computing site 104(2).

[0028] 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 in 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 in a second computing system 102(2). In some instances, the service computing device 112 and the local storage device 114 may be located in physically separate machines. For example, the local storage device 114 may be incorporated within a local storage system, as discussed further below with respect to FIG. 2. In other examples, the local storage device 114 may be incorporated within or otherwise included in the service computing device 112. Additionally, in some examples, the service computing device 112 of an individual computing system 102 may correspond to a computing cluster, such as a cluster of related servers. However, the computing systems 102 are not limited to the hardware configurations described and illustrated in this disclosure and may include any suitable or desired hardware configuration capable of providing data storage and performing the functions described herein, and the hardware configuration in one of the computing systems 102 may, in some cases, differ from the hardware configuration in another of the computing systems 102.

[0029] 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 within a portion of the memory of the individual service computing device for storing at least KEKs corresponding to data managed by the individual service computing device 112. Thus, service computing device 112(1) may maintain an individual key data structure 115(1) that includes at least KEKs corresponding to data managed by service computing device 112(1), and service computing device 112(2) may maintain an individual key data structure 115(2) that includes at least KEKs corresponding to data managed by service computing device 112(2).

[0030] 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, that may be used to store metadata about the stored object data 118(1), 110(1) and 118(2), 110(2), respectively, on the local storage devices 114(1) and 114(2), respectively, in the respective systems 102(1) and 102(2) and on the network storage devices 108(1) and 108(2), respectively. For example, the metadata data structure 116 may be a database, a table, or any other suitable data structure. The metadata included in the metadata data structure 116 may include information about the individual stored objects, such as the path, name, owner, hash values ​​determined from the object data, and DEKs used to encrypt / decrypt the stored object data.

[0031] Computing systems 102(1) and 102(2) can communicate with one or more key management (KM) computing devices 119 over one or more networks 106. For example, a KM computing device 119 can be configured to provide encryption keys 120 to computing systems 102 according to the KMIP standard, which can include at least a KEK as discussed herein. In some cases, there can be multiple KM computing devices 119, such as to provide redundancy in case one of the KM computing devices 119 fails. Each KM computing device 119 can run an instance of a key manager 121, which can manage the generation and provision of keys to individual computing systems 102, and can perform other key management functions as discussed further below.

[0032] Additionally, at least some of the service computing devices 112 can communicate with multiple client devices 122(1)-122(N) over one or more networks 106. For example, each client device 122(1)-122(N) may include a respective instance of a client application 126(1)-126(N) that may execute on the respective client device 122(1)-122(N), such as to transmit data objects 130 for storage by the computing system 102 and / or to communicate with the respective service computing device 112 to retrieve 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 operate via a browser, while in other cases, the client application 126 may include any other type of application having communication capabilities that enable it to communicate with the service computing device 112 over one or more networks 106.

[0033] In some cases, a user 128, and / or a client device 122, and / or a client application 126 may be assigned to access a service computing device 112 at a particular computing site location 104 of multiple computing site locations 104. For example, if a first computing site location 104(1) is located in Boston and a 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 another service computing device 112(2) at a second computing site location 104(2).

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

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

[0036] 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 a short-range wireless communication such as BLUETOOTH®, a wired network including Fibre Channel, optical fibre, Ethernet or any other such network, a direct wired connection, or any combination thereof. Thus, the one or more networks 106 may include both wired and / or wireless communication technologies. The components used for such communication may depend, at least in part, on the type of network, the selected environment, or both. Protocols for communicating over such networks are well known and will not be discussed in detail herein. Thus, the service computing device 112, the KM computing device 119, the network storage 108, and the client devices 122 may communicate over the one or more networks 106 using wired or wireless connections, and combinations thereof.

[0037] In the illustrated example, assume that a first user 128(1) uses a first computing system 102(1) to store a data object 130. For example, the first user 128(1) may transmit the object 130 to the service computing device 112(1) for storage by the first computing system 102(1). In some cases, the first computing system 102(1) may locally store a copy of the object 130 as part of the local object data 118(1). For example, the service computing device 112 may use a dedicated DEK (not shown in FIG. 1 ) to encrypt the object data of the data object 130 before storing the object data on the local storage device 114(1) as part of the local object data 118(1). Additionally or alternatively, the service computing device 112(1) may transmit the encrypted object data 132 of the object 130 to the network storage 108(1) for storage with the object data 110(1). After encrypting the object data, service computing device 112(1) may store the DEK in metadata data structure 116(1) as part of the metadata associated with data object 130. Furthermore, service computing device 112(1) may encrypt the DEK using a KEK corresponding to first user 128(1). For example, if first user 128(1) is associated with a tenant or other entity, then the KEK corresponding to that 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. Further, additional variations are discussed below, although numerous other variations will be apparent to those skilled in the art having the benefit of this disclosure.

[0038] In some examples, the distributed computing system 100 herein may be deployed in a geographically distributed manner for purposes of data recovery and / or concurrent access, etc. Synchronous or asynchronous data replication may be employed to transfer data to one or more remote computing systems 102, such as between computing systems 102(1) and 102(2) and / or between these computing systems 102(1), 102(2) and other computing systems not shown in FIG. 1.

[0039] FIG. 2 illustrates an example of selected components in an example configuration of a computing system 102 according to some implementations. In some examples, computing system 102 may correspond to computing systems 102(1) and / or 102(2) discussed above with respect to FIG. 1. Computing system 102 includes multiple service computing devices 112-1 through 112-M (where M is a positive integer), which may correspond to service computing devices 112(1) and / or 112(2) discussed above with respect to FIG. 1. Service computing devices 112-1 through 112-M may communicate with one or more networks 106 or otherwise be connected to one or more storage systems 202, which may provide local storage 114 in some examples. In some cases of the illustrated system, one or more networks 106 may include a LAN, a storage area network (SAN) such as a Fibre Channel network, or the like, although implementations herein are not limited thereto and may include other types of networks, direct connections, and the like, as discussed elsewhere herein.

[0040] In some embodiments, service computing device 112 may include one or more servers or other types of computing devices, which may be embodied in any number of ways. For example, in the case of a server, at least a portion of the programs, other functional components, and data storage may be implemented on at least one server across multiple servers, a server farm, a data center, a cloud-hosted computing service, etc., although other computer architectures may also or alternatively be used. In the illustrated example, service computing device 112 may include or be associated with one or more processors 210, one or more computer-readable media 212, and one or more communication interfaces 214.

[0041] Each processor 210 may be a single processing unit or several processing units and may include single or multiple computational units or multiple processing cores. 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 operational instructions. By way of example, processor 210 may include one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. Processor 210 may be configured to retrieve and execute computer-readable instructions stored in computer-readable medium 212, which may be executed to program processor 210 to perform the functions described herein.

[0042] 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, solid-state storage, magnetic tape, magnetic disk storage, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store desired information and that is accessible by a computing device. Depending on the configuration of the service computing device 112, the computer-readable medium 212 may be tangible, non-transitory media, where non-transitory computer-readable media is referred to as excluding media such as energy, carrier signals, electromagnetic waves, and / or the signals themselves. In some cases, the computer-readable medium 212 may be contained within the service computing device 112, while in other examples, the computer-readable medium 212 may be partially separate from the service computing device 112. For example, in some cases, computer-readable medium 212 may include a portion of the storage within storage system 202 .

[0043] The computer-readable medium 212 may be used to store any number of functional components executable by the processor 210. In many implementations, these functional components include instructions or programs executable by the processor 210 that, when executed, specifically program the processor 210 to perform actions attributed herein to the service computing device 112. The functional components stored in the computer-readable medium 212 may include a server program 216 that may communicate with client devices to send data objects to client devices, receive data objects from client devices, and the like. The functional components may further include a storage management program 218 that may encrypt and store object data, store metadata for the object data, decrypt object data, and manage KEKs and DEKs used for encryption and decryption, as further discussed elsewhere herein. 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, loaded into a local memory portion of the computer-readable medium 212, and executed by one or more processors 210.

[0044] Additionally, 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 a metadata data structure 116, such as a metadata database, which may include a DEK 219 and other metadata 220 for data objects stored by the computing system 102. Additionally, 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 (a universally unique identifier that is at least unique within the distributed computing system 100, discussed above with respect to FIG. 1). For example, as discussed further below, a UUID may be used to associate a particular KEK with a particular entity and particular metadata of an object to be encrypted or decrypted. The service computing device 112 may also include or maintain data within the computer-readable medium 212, which may include other functional components and programs, drivers, etc., and data used or generated by the functional components. Additionally, service computing device 112 may include many other logical, programmatic, and physical components, of which the above-described are merely examples relevant to the present discussion.

[0045] Communication interface 214 may include one or more interfaces and hardware components for enabling communication with various other devices, such as via one or more networks 106. Accordingly, communication interface 214 may include or connect to one or more ports that provide a connection for communicating with storage system 202 and one or more ports that provide a connection to network 106 for communicating with client device(s) 122. For example, communication interface 214 may enable communication via 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., Fibre Channel, Fiber Optic, Ethernet), a direct connection, and a short-range communication such as BLUETOOTH®, as additionally listed elsewhere herein.

[0046] 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 device, such as any of the examples discussed above with respect to service computing device 112. Storage computing device 230 may each include one or more processors 232, one or more computer-readable media 234, and one or more communications interfaces 236. For example, processor 232 may correspond to any of the examples described above with respect to processor 210, computer-readable media 234 may correspond to any of the examples described above with respect to computer-readable medium 212, and communications interface 236 may correspond to any of the examples described above with respect to communications interface 214.

[0047] Additionally, computer-readable medium 234 may include storage programs 238 as functional components executed by one or more processors 232 to manage the storage of data on storage 240 included in storage system 202. Storage 240 may include one or more controllers 242 associated with storage 240 to store data on one or more local storage devices 114. For example, controller 242 may control array 244, such as to configure array 244 in a RAID configuration, an erasure coding configuration, and / or any other suitable storage configuration. Local storage device 114 may be any type of storage device, such as a hard disk drive, a solid-state drive, an optical drive, magnetic tape, combinations thereof, etc. Additionally, while several example computing systems have been described herein, numerous 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 this disclosure.

[0048] The computing system 102 may be configured to minimize the number of KEKs 222 stored on the KM computing device 119, such as by allowing only one KEK 222 to be created per entity, such as a user, namespace, tenant, etc. For example, in some cases, data may be partitioned according to tenant. For example, a tenant (e.g., an organization, a company, a group of users, etc.) typically does not want its data to be kept private and secure from other tenants. Furthermore, different tenants may have different namespaces. A namespace may contain a collection of data objects. In some cases, each namespace may contain a file system that is private to other namespaces. Furthermore, access to one namespace of a tenant does not necessarily grant that user access to other namespaces of the tenant.

[0049] Additionally, tenants may be implemented as a hierarchy in that they may contain subtenants. A top-level tenant may be a tenant that has no parent tenant, such as a company, corporation, organization, or other entity. A subtenant may be a tenant whose parent is another tenant, for example, a finance department of a company may be a subtenant of a top-level tenant that is a company. A default tenant may be a top-level tenant that contains only a default namespace.

[0050] 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 data for each different namespace of a tenant, for each user associated with a tenant, or in any of a number of other variations based on rules applicable to a particular entity, such as a particular tenant, namespace, user, etc.

[0051] In the examples herein, the process of obtaining a KEK for an entity may include multiple steps that utilize knowledge of KMIP to limit the number of KEKs created when multiple service computing devices 112 and / or computing systems 102 (e.g., a cluster) require 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, for which it is undesirable to share the 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 and pre-active KEKs 222 associated with the particular entity from the KM computing device 119. For example, if the currently active KEK with the most recent initialization date is still valid, the service computing device 112 may use this KEK.

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

[0053] If no pre-active KEK exists, the service computing device 112 may instruct the KM computing device 119 to create one. The service computing device 112 may then again request all active and pre-active KEKs from the KM computing device; if an active KEK with a valid, recent initialization date is received, it is possible that another service computing device 112 activated this active KEK between the first and second key requests. In this case, the service computing device 112 may use the received active KEK to encrypt data and may instruct the KM computing device 119 to discard all other pre-active KEKs on the KM computing device 119.

[0054] 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 oldest initialization date for activation. For example, by implementing a rule requiring the selection of the oldest initialization date, the algorithm ensures that any other service computing device 112 that may be simultaneously attempting to create a valid active KEK will find and select the same pre-active KEK. Thus, the service computing device 112 may send an instruction for the KM computing device 119 to activate the selected pre-active KEK on the KM computing device 119. If this instruction fails, the service computing device 112 may assume that another service computing device 112 has already activated the selected KEK, and the service computing device 112 may send a request to obtain the currently active KEK from the KM computing device 119 based on the KEK's identifier and its active state.

[0055] On the other hand, if there is no activated KEK at this point, the creation operation has failed. Thus, the service computing device 112 may instruct the KM computing device 119 not to delete any pre-active KEKs and avoid further steps. As another alternative, the service computing device 112 may repeat the above operations if a KM computing device 119 is available. On the other hand, if the creation of the active KEK is successful, the KM computing device 119 may be instructed to distribute the activated KEK to all other service computing devices 112 in the computing system 102 for inclusion in their respective key data structures, so that other service computing devices 112 do not need to contact the KM computing device 119 when a valid active KEK is required for a particular entity. Furthermore, after activating the KEK, any other pre-active KEKs that may have been created may be discarded.

[0056] As mentioned above, the service computing device 112 may include a key data structure 115, which may take the form of an in-memory cache or the like that holds previously used KEKs 222 in memory so that each service computing device 112 does not need to contact the key management computing device 119 when a particular KEK is needed. As an example, when an individual service computing device 112 starts up, the service computing device 112 may contact any configured KM computing devices 119 and obtain 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 its key data structure 115 for use when responding to client requests that include one of the KEKs 222.

[0057] In the key data structure 115, the KEKs 222 may be organized into several overlapping maps to improve the efficiency of retrieving one or more keys based on specific qualifiers. These internal key data structure maps may contain a mapping of key UUIDs to corresponding KEKs, which is the primary mapping of a KEK's UUID to the KEK object itself, allowing for quick lookup of a specific KEK based on its UUID. Additionally, UUIDs retrieved from other maps may be used in conjunction with this map to retrieve a specific KEK for encryption / decryption purposes.

[0058] Additionally, the key data structure 115 may include a mapping of "location" (e.g., an entity such as a tenant, namespace, or user with which the key is associated) UUID and KM computing device name to the active KEK UUID currently being used for ingest, allowing a lookup of the key UUID to be performed based on the combination of the location / entity associated with the KEK and the KM computing device 119 holding 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 specified entity and KM computing device combination.

[0059] Further, the key data structure 115 may include a mapping to the set of all KEK UUIDs for a computing system UUID and computing system type. This mapping allows tracking of all KEKs associated with a particular computing system 102, including both the current ingest key and previously used keys. In addition, the key data structure 115 may include a mapping to the set of ingest KEK UUIDs for a KM computing device name, allowing tracking of all active KEKs currently designated for use in ingest and associated with a KM computing device. Additional mappings may include a mapping to the set of all KEK UUIDs for a KM computing device name to allow tracking of all KEKs associated with a particular KM computing device 119. Furthermore, while several example mappings are described above, numerous variations will be apparent to those skilled in the art having the benefit of this disclosure.

[0060] The service computing device 112 herein may enforce KEK validation, rotation, and deactivation policies, which may be performed by modules executed by the execution of the storage management program 218 or other appropriate programs. For example, accepted security best practices discourage using the same encryption key indefinitely because a security breach or other loss may occur, making the key accessible to a third party or otherwise compromised. For example, a period of three may be configurable by an administrator or the like. A cryptoperiod may be a configurable amount of time the KEK is expected to be usable, such as 18 months or another desired period. After the cryptoperiod expires, the KEK may be deactivated. A deactivated key may be used following decryption, but a warning may be sent to an administrator or other user when a deactivated key needs to be used, such as to provide an indication to the administrator that rekeying of the deactivated key has not been sufficiently completed and may require review.

[0061] In some examples herein, the cryptoperiod may be divided into three distinct periods: (1) a validity period during which the KEK is used to encrypt DEKs for newly captured data; (2) a rotation period following the validity period during which the KEK is retired and no longer used during capture, and is replaced with a newly activated KEK, but re-keying has not yet begun; and (3) a re-key period during which DEKs encrypted by the KEK are decrypted and re-encrypted using the newer KEK. As an example, each of these three periods may be six months, so that the total cryptoperiod may be 18 months, although any of these times may be configured differently by an administrator or a user with sufficient system privileges.

[0062] The rekey period must be long enough to ensure that all DEKs encrypted using the KEK are unwrapped and re-encrypted using the individual entity's most recent or currently active KEK. After the rekey period (and cryptoperiod) expires, the KEK may be deactivated. As noted above, after a KEK is deactivated, the deactivated KEK may be retained for an additional period (e.g., to ensure that no objects with associated DEKs remain encrypted with the deactivated KEK), during which time the deactivated KEK may still be used to decrypt any DEKs that remain wrapped with that particular deactivated KEK. If this situation occurs, a warning may be sent to an administrator or other user to provide notice that the rekey process may not have been fully completed and should be reviewed. In some cases, a KEK may be automatically deactivated after the expiration of the rekey period (e.g., the last six months) or cryptoperiod (e.g., 18 months). If the KEK is still in use when it is deactivated, a warning may be generated; otherwise, the KEK may be discarded. In some instances, any unused KEK that is deactivated may be discarded. Additionally, in some instances, there may be an administrative process to deactivate or compromise a KEK before the cryptoperiod expires.

[0063] To help limit the impact of a KEK being compromised, the KEKs herein may be periodically rotated and replaced. Examples herein may implement this policy by providing a configurable rotation period value that may be checked against the key's creation date (also referred to as the key's "initial date") on the KM computing device 119 when an active KEK is retrieved from the key data structure 115 for use as an ingest key for a particular entity. When it is time to rotate an active KEK, the particular KEK may be marked or otherwise designated as "revoked" and will no longer be used to encrypt DEKs for ingested data. The revoked KEK may continue to be used to decrypt DEKs to decrypt data previously encrypted using that KEK and DEK combination. A new KEK may be created / activated and used in place of the retired / rotated KEK.

[0064] Additionally, a separate procedure may be performed to "activate" each KEK once per configurable activation period (e.g., every 24 hours or other desired period). For example, validating a KEK may include obtaining an updated version of the KEK from KM computing device 119 to ensure that key data structure 115 has a fresh version of each KEK. If an updated version of a KEK needs to be revoked or deactivated, appropriate action is taken locally.

[0065] Examples herein may also implement KEK re-keying and revocation policies. For example, the storage management program 218 or other suitable program running on each service computing device 112 may include an internal background service that continuously examines objects to determine whether the corresponding DEK should be re-encrypted with a new KEK to replace a revoked KEK.

[0066] In some examples, when a KEK's life span reaches its rotation period, it may be retired and replaced by a new active KEK, which may be used to retrieve objects during its validity period. During a rekey period, a retired KEK may be replaced by the current active KEK. To replace the KEK, the currently verified DEK may be retrieved by decrypting / unwrapping it with the corresponding retired KEK, and the DEK may then be re-encrypted (re-wrapped) using the currently active KEK. The re-wrapped DEK may be associated with the same object metadata for use in future decryptions of individual object data, and system metrics may be updated for disaster recovery purposes. A background service may check all KEKs held by all configured KM computing devices 119 at specific intervals. Any KEK 222 that has reached its specified rotation period, whether currently active or not, may be rotated, retired, and deactivated at the end of the rekey period before finally being destroyed. Therefore, the policy implemented herein aims to replace all KEKs before their respective cryptoperiods expire. Any KEK that is not in use by any object and is inactive may be revoked. However, a KM Computing Device cannot be decommissioned unless all KEKs on that device have been revoked.

[0067] Service computing devices 112 may communicate with each other, such as to provide information related to updating the key cache or other information related to the KEK. According to implementations herein, any delay in responding to customer requests for data may be minimized by ensuring that the KEK 222 is available on any service computing device that may be requested to service the customer request. Additionally, any KM computing device contact that results in a cache change may be distributed to all service computing devices 112. This functionality eliminates the need for other service computing devices to contact the KM computing device when it desires to use a created or modified KEK or when the KEK's rotation period expires. In some cases, the KM computing device 119 is contacted during retrieval. As an example, this may occur when a request to replace the KEK is made or when the KEK is marked as compromised. In these situations, the cache distribution request does not wait for the KM computing device's response. Additionally, when an existing KEK is validated (e.g., every 24 hours), the result is distributed by the service computing device to other service computing devices, preventing other service computing devices from unnecessarily contacting the KM computing device to validate the same KEK.

[0068] In the present example, background KEK creation and activation is not affected by contact with the KM computing device 119 during user data capture. For example, a background task may be used to create a new active KEK or activate an active KEK to be used to capture data for a particular entity. A currently valid active KEK may be used while the background task is running in preparation for future operations involving the new or updated KEK.

[0069] In the examples herein, a single KEK may be generated quickly for users across multiple service computing devices 112 and multiple computing systems 102. No inter-node messages or additional communication with users or client computing devices is required. Furthermore, only one active KEK is generated regardless of how many nodes may simultaneously request activation of a KEK for a particular entity, which minimizes the number of KEKs generated per entity. Additionally, in some examples, a background process may be performed to maintain the consistency of the KEK 222 within the key data structure 115 without interrupting user requests. For example, a request to the KM computing device 119 may be performed in the background, such as when a key rotation process determines that a KEK has been rotated and is ready to be revoked. The active KEK resulting from the operation of the KM computing device may be distributed to all service computing devices 112 upon completion, such as after receiving a user data request, rather than having each service computing device 112 wait to request a new / updated KEK as needed.

[0070] Additionally, implementations herein can maximize data protection by employing a unique DEK for each individual storage object, while minimizing the number of KEKs that KM computing device 119 needs to provide to service computing device 112, such as by using only one KEK per data sharing entity. Furthermore, providing a key data structure 115 on each service computing device 112 also helps minimize network traffic between service computing devices 112 and between service computing device 112 and KM computing device 119. As discussed above, the key data structure includes multiple internal maps that allow for rapid access to the correct KEK or set of KEKs within the memory of each service computing device 112. Numerous other advantages and benefits of implementations herein will be apparent to those skilled in the art.

[0071] FIG. 3 is a flow diagram illustrating an example process 300 for obtaining an active key, according to some implementations. This process is illustrated as a collection of blocks in a logical flow diagram, which represent a sequence of operations, some or all of which may be implemented by hardware, software, or a combination thereof. In the software context, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, programs the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the blocks are described should not be construed as limiting. Any number of the described blocks can be combined in any order and / or in parallel to implement a process or alternative processes, and not all of the blocks need be performed. For illustrative purposes, the process is described with reference to the environments, frameworks, and systems described in the examples herein; however, the process may be implemented within a wide variety of other environments, frameworks, and systems. In some cases, process 300 may be performed at least in part by one or more service computing devices 112 or one or more other computing devices of computing system 102, such as those in distributed computing system 100 discussed above with respect to FIG. 1.

[0072] At 302, a computing system may detect or otherwise receive a trigger that initiates 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 revoked and a new active KEK should be obtained.

[0073] At 304, the computing device may send a request to the KM computing device to obtain all active 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 any active KEKs associated with a particular entity or any pre-active KEKs associated with the entity.

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

[0075] At 308, if 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 trigger event.

[0076] At 310, if 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 already been created but not yet activated. If a pre-active KEK is not returned, the process proceeds to 312. If so, the process proceeds to 314.

[0077] At 312, if a pre-active KEK has not been returned, the computing device may send instructions to the KM computing device to create a pre-active KEK.

[0078] At 314, the computing device may send a second request to the KM computing device to obtain all active and pre-active KEKs. This second request may help determine whether another service computing device has already created an active KEK slightly earlier than the current process.

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

[0080] 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 be simultaneously attempting to obtain an active KEK for a particular entity to select the same pre-active KEK for activation, thereby avoiding creating multiple active KEKs for that entity.

[0081] At 320, the computing device may determine whether an active KEK has been created in response to the instruction. If an active KEK has been created, the process proceeds to 322. If not, the process proceeds to 324.

[0082] At 322, if an 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.

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

[0084] At 326, the computing device may send an instruction to the KM computing device to request that the KM computing device discard any pre-active KEKs that may still remain, and the process may return to 302 to wait for the next trigger event.

[0085] The example processes described herein are merely example processes provided for illustrative purposes. Numerous other variations will be apparent to those skilled in the art in light of the disclosure herein. Furthermore, while the disclosure herein describes some example frameworks, architectures, and environments suitable for implementing the processes, the implementations herein are not limited to the specific examples shown and described. Furthermore, the disclosure provides various example implementations as described and illustrated. However, the disclosure is not limited to the implementations described and illustrated herein, and may extend to other implementations as known or become known to those skilled in the art.

[0086] FIG. 4 illustrates an example of a key state data structure 400 according to some implementations. 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. If a key is in a pre-active state, as shown at 408, the key is not authorized to be used for encryption, as shown at 404, and is not authorized to be used for decryption, as shown at 406. If a key is in an active state, as shown at 410, the key may be used for encryption, as shown at 404, and may be used for decryption, as shown at 406. If a key is deactivated, as shown at 412, the key may not be used for encryption but may still be used for decryption, and a notice or other warning may be sent to an administrator if the key is used for decryption. If a key is compromised, as shown at 414, the key may not be used for encryption but may be used for decryption, and a notice may be sent to an administrator if the key is used for decryption. When a key is revoked, it cannot be used to encrypt or decrypt, as shown at 416. When a key is revoked, as shown at 418, it is not authorized to be used for encryption, but it can still be used for decryption, and no notice needs to be sent to an administrator.

[0087] 5 illustrates an example of a key attribute data structure 500 according to some 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 shown at 508, the identifier (ID) may be set by the KM computing device as shown at 504 and may be an ID that uniquely identifies a particular key to a KM computing device 119 in the system. As shown at 510, the initialization date attribute may be set by the KM computing device and may be the date and time that the KM computing device created a particular key. As shown at 512, the acquisition time may be the date and time that the key was first acquired from the KM computing device by one of the service computing devices in the computing system.

[0088] As shown at 514, the UUID attribute may be created by a service computing device that can assign a UUID to a key, where the UUID may be a unique identifier within the system (or other individually distinguishable ID) that can be used to retrieve a particular key, such as from 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) 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) created by the service computing device to identify the entity (e.g., tenant, namespace, user) with which the key is associated. As shown at 520, the additional location UUIDs may be unique identifiers within the system (or other individually distinguishable IDs) created by the service computing device to associate the key with any additional associated users, tenants, namespaces, etc.

[0089] 6 illustrates an example of an active key status data structure 600 according to some implementations. In this example, the active key status data structure 600 includes an "Active Key Status" column 602, a "Used for New Data Encryption" column 604, a "Replacement in Existing Data" column 606, a "Time Since Creation" column 608, and an "Action" column 610. As discussed above with respect to FIG. 4, an "active" key may be a KEK currently being used to both encrypt and decrypt the corresponding entity's DEK. If the key is within its validity period, e.g., the first six months (or other configurable period) after activation, as shown in 612, the key may be used to encrypt DEKs for new data, as shown in column 604, and there is no need to replace the key or take other action.

[0090] As shown in 614, when a key reaches its rotation period, it is retired and will not be used to encrypt new data unless a new active KEK is still available (i.e., obtained from a KM computing device). A KEK can enter a rotation state at a user-configurable time (e.g., six months to one year after activation), at which point the key's validity period ends and the KEK is no longer "active." The rekey status begins at the end of the rotation period.

[0091] When the key status transitions to rekey, as shown at 616, the KEK is still not allowed to be used for encryption with respect to new data, but may be used for decryption to replace the KEK with the most recent active KEK. For example, if an encrypted DEK is found that was encrypted using the KEK, the KEK is replaced by decrypting the DEK and re-encrypting the DEK using the most recent active KEK.

[0092] As shown in 618, if the key status changes to expired, for example, at the end of a re-key period that also corresponds to the end of a cryptoperiod, the KEK is deactivated but not yet destroyed because destruction could result in data loss. If a DEK is found that is still encrypted with a deactivated KEK, that KEK is needed to decrypt the DEK, and an alert is sent to the administrator informing the administrator that a deactivated KEK is needed to decrypt the DEK, which may indicate that the re-key process for that KEK has not fully completed.

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

[0094] FIG. 7 illustrates an example of selected components of one or more KM computing devices 119 according to some implementations. KM computing device 119 may include one or more servers or other types of computing devices, which may be embodied in any number of ways. For example, in the case of a server, the programs, other functional components, and data may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, etc., although other computer architectures may additionally or alternatively be used. Multiple KM computing devices 119 may be located together or separately and organized, for example, as servers, virtual servers, server banks, and / or server farms. The described functionality may be provided by the servers of a single entity or company, or by the servers and / or services of multiple different entities or companies.

[0095] In the depicted example, the KM computing device 119 may include or be associated with one or more processors 702, one or more computer-readable media 704, and one or more communication interfaces 706. Each processor 702 may be a single processing unit or several processing units, and may include 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 operational instructions. By way of example, the processor 702 may include one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to execute the algorithms and processes described herein. The processor 702 may be configured to retrieve and execute computer-readable instructions stored in the computer-readable media 704, which may program the processor 702 to perform the functions described herein.

[0096] The computer-readable medium 704 may include volatile and non-volatile memory and / or removable and non-removable media implemented by 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, solid-state storage, magnetic tape and magnetic disk storage, network or cloud storage, array storage, network-attached storage, storage area network, or any other medium that can be used to store desired information and that is accessible by a computing device. Depending on the configuration of the KM computing device 119, when non-transitory computer-readable medium is referred to as excluding media such as energy, carrier signals, electromagnetic waves, and / or the signals themselves, the computer-readable medium 704 may be a tangible, non-transitory medium. In some cases, the computer readable medium 704 may be in the same location as the KM computing device 119, while in other instances, the computer readable medium 704 may be partially remote from the KM computing device 119.

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

[0098] Additionally, the computer-readable medium 704 may store data, data structures, and other information used to perform the functions and services described herein. For example, the computer-readable medium 704 may store key 120, including KEK 222. The KM computing device 119 may also include or maintain other functional components and data, including programs, drivers, etc., and data used or generated by the functional components. Furthermore, the KM computing device 119 may include many other logical, programmatic, and physical components, of which the above-described are merely examples relevant to the discussion herein.

[0099] The one or more communication interfaces 706 may include one or more software and hardware components for enabling communication with various other devices, such as over one or more networks 106. For example, the communication interface 706 may enable communication over 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., Fibre Channel, Fiber Optic, Ethernet), a direct connection, and near-field communication such as BLUETOOTH®, as further listed elsewhere herein.

[0100] Various instructions, methods, and techniques described herein may be considered in the general context of computer-executable instructions, such as computer programs and applications, stored on a computer-readable medium and executed by a processor herein. In general, the terms program and application may be used interchangeably and may include instructions, routines, scripts, modules, objects, components, data structures, executable code, etc. for performing particular tasks or implementing particular data types. These programs, applications, etc. may be executed as native code or may be downloaded and executed in a virtual machine or other just-in-time compilation execution environment, etc. Typically, the functionality of the programs and applications may be combined or distributed as desired in various implementations. Implementations of these programs, applications, and techniques may be stored on computer storage media or transmitted over some form of communication medium.

[0101] Although the subject matter has been described in specific language as describing 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. 1. A system including a computing system having a plurality of computing devices capable of communicating over a network with a key management computing device, wherein a first computing device of the plurality of computing devices comprises: sending a request to the key management computing device for information relating to at least one of an active key encryption key (KEK) associated with an entity or a pre-active KEK associated with the entity; receiving an indication from the key management computing device that the key management computing device does not have an active or pre-active KEK associated with the entity; In response to the submission, sending an instruction to the key management computing device to create a pre-active KEK for the entity; thereafter, based on determining that there are multiple pre-active KEKs for the entity 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; receiving an active KEK for the entity; 2. A system configured by executable instructions to perform operations including:

2. The system of claim 1 , wherein the operations further include receiving the active KEK from the key management computing device and an indication that activation of the active KEK was successfully performed.

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

4. 4. The system of claim 3, wherein the operations further include receiving an indication that the command to activate the pre-active KEK failed based at least on the second computing device of the plurality of computing devices requesting activation of the pre-active KEK having the earliest creation time before the command was received from the first computing device.

5. The system of claim 1 , wherein the actions further comprise sending an instruction to the key management computing device to revoke any remaining pre-active KEKs corresponding to the entity.

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

7. 2. The system of claim 1, wherein the actions further comprise revoking the active KEK associated with the entity after expiration of a first time period and requesting a new active KEK associated with the entity from the key management computing device.

8. 8. The system of claim 7, wherein the act of revoking the active KEK allows the revoked KEK to be used to decrypt a previously encrypted data encryption key (DEK), but not to encrypt a DEK.

9. 8. The system of claim 7, wherein the operations further include, after expiration of a second time period, decrypting a previously encrypted data encryption key (DEK) using the revoked KEK and re-encrypting the DEK with a current active KEK associated with the entity.

10. 10. The system of claim 9, wherein the operations further include deactivating the revoked KEK after expiration of a third time period, and wherein after deactivation, a warning is sent to a user based on the need for the deactivated KEK to decrypt a DEK that was previously encrypted using the now-deactivated KEK.

11. The operation is storing the active KEK in a data structure containing a plurality of active KEKs; Associating each active KEK with a respective uniquely distinguishable identifier (ID) within said data structure; The system of claim 1 further comprising:

12. transmitting, by a computing device, a request for information related to at least one of an active key encryption key (KEK) associated with an entity or a pre-active KEK associated with the entity to a key management computing device, the computing device being one of a plurality of computing devices included in a computing system configured to store object data; receiving an indication from the key management computing device that the key management computing device does not have an active or pre-active KEK associated with the entity; In response to the submission, sending an instruction to the key management computing device to create a pre-active KEK for the entity; thereafter, based on determining that there are multiple pre-active KEKs for the entity 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; receiving an active KEK for the entity; A method comprising:

13. 13. The method of claim 12, further comprising receiving the active KEK from the key management computing device and an indication that activation of the active KEK has been successfully performed.

14. sending a request to a key management computing device for information relating to at least one of an active key encryption key (KEK) associated with an entity or a pre-active KEK associated with said entity; receiving an indication from the key management computing device that the key management computing device does not have an active or pre-active KEK associated with the entity; In response to the submission, sending an instruction to the key management computing device to create a pre-active KEK for the entity; thereafter, based on determining that there are multiple pre-active KEKs for the entity 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; receiving an active KEK for the entity; One or more non-transitory computer-readable media storing one or more programs executable by a first computing device of a plurality of computing devices in a computing system to configure the first computing device to perform operations including:

15. 15. The one or more non-transitory computer-readable media of claim 14, wherein the operations further include receiving the active KEK from the key management computing device and an indication that activation of the active KEK was successfully performed.

Images