Federated Key Management

Abstract

To achieve enhanced data security in an environment accompanied by distributed computing resources.SOLUTION: The system uses information presented in relation to a request, and determines whether to process the request and how to process the request. The information can be electronically signed by a claimant by using a key such that the system which processes the request can verify that the claimant has the key, and that the information is authentic. The information can include information for identifying a holder of the key necessary for processing the request, and the holder of the key may be the system or another, probably, a third party's system. The request for decrypting data can be processed to secure the lapse of a fixed time before access to data to be decrypted is provided, and to provide a chance to cancel the request, and / or to reduce security violations thereby.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 13 / 765,209, filed February 12, 2013, the contents of which are incorporated herein by reference in their entirety. This application is incorporated for all purposes into co-pending U.S. patent application Ser. No. 13 / 764,944, filed concurrently herewith, entitled "AUTOMATIC KEY ROTATION," co-pending U.S. patent application Ser. No. 13 / 764,963, filed concurrently herewith, entitled "DATA SECURITY SERVICE," co-pending U.S. patent application Ser. No. 13 / 765,020, filed concurrently herewith, entitled "DATA SECURITY WITH A SECURITY MODULE," co-pending U.S. patent application Ser. No. 13 / 764,995, filed concurrently herewith, entitled "POLICY ENFORCEMENT WITH ASSOCIATED DATA," co-pending U.S. patent application Ser. No. 13 / 765,239, filed concurrently herewith, entitled "DELAYED DATA ACCESS," co-pending U.S. patent application Ser. No. 13 / 765,239, filed concurrently herewith, entitled "DATA SECURITY The entire disclosures of co-pending U.S. patent application Ser. No. 13 / 765,265, entitled "SECURE MANAGEMENT OF INFORMATION USING A SECURITY MODULE," and co-pending U.S. patent application Ser. No. 13 / 765,283, filed concurrently herewith, entitled "SECURE MANAGEMENT OF INFORMATION USING A SECURITY MODULE," are incorporated by reference. [Brief explanation of the drawings]

[0002] Various embodiments according to the present disclosure will now be described with reference to the drawings.

[0003] [Figure 1] 1A-1C show exemplary diagrams depicting various aspects of the present disclosure in accordance with various embodiments. [Figure 2] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented. [Figure 3]1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented, as well as an example of the flow of information between various components of the environment in accordance with at least one embodiment. [Figure 4] 1 illustrates example steps of an exemplary process for storing ciphertext in accordance with at least one embodiment. [Figure 5] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented, as well as an example of the flow of information between various components of the environment in accordance with at least one embodiment. [Figure 6] 1 illustrates example steps of an exemplary process for responding to a request to obtain data, according to at least one embodiment. [Figure 7] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented, as well as an example of the flow of information between various components of the environment in accordance with at least one embodiment. [Figure 8] 1 illustrates example steps of an illustrative process for responding to a request to store data, in accordance with at least one embodiment. [Figure 9] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented, as well as an example of the flow of information between various components of the environment in accordance with at least one embodiment. [Figure 10] 1 illustrates example steps of an exemplary process for responding to a request to obtain data, according to at least one embodiment. [Figure 11] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented. [Figure 12] 1 illustrates an illustrative example of an environment in which various aspects of the present disclosure may be implemented, as well as an example of the flow of information between various components of the environment in accordance with at least one embodiment. [Figure 13] 1 illustrates example steps of an exemplary process for responding to a request to obtain data, according to at least one embodiment. [Figure 14] 1 illustrates example steps of an illustrative process for responding to a request to decrypt data in accordance with at least one embodiment. [Figure 15]1 illustrates example steps of an exemplary process for obtaining decoded data in accordance with at least one embodiment. [Figure 16] 1 illustrates a diagrammatic representation of an example cryptographic service in accordance with at least one embodiment. [Figure 17] 1 illustrates example steps in an exemplary process for configuring a policy in accordance with at least one embodiment. [Figure 18] 1 illustrates example steps of an exemplary process for performing cryptographic operations while enforcing policy, in accordance with at least one embodiment. [Figure 19] 1 shows an illustrative example of a process for encrypting data in accordance with at least one embodiment. [Figure 20] 1 illustrates an illustrative example for encrypting data using a security module in accordance with at least one embodiment. [Figure 21] 1 illustrates an illustrative example for encrypting a key used to encrypt data using a security module, according to at least one embodiment. [Figure 22] 1 illustrates an illustrative example of a process for enforcing policy using relevant data, according to at least one embodiment. [Figure 23] 1 illustrates an illustrative example of a process for enforcing policy using associated data and security modules in accordance with at least one embodiment. [Figure 24] 1 illustrates an illustrative example of a policy state diagram in accordance with at least one embodiment. [Figure 25] 10 illustrates an illustrative example of another state diagram for a policy in accordance with at least one embodiment. [Figure 26] 1 shows an illustrative example of a process for automatically rotating keys in accordance with at least one embodiment. [Figure 27] 1 shows an illustrative example of a process for automatically rotating keys in accordance with at least one embodiment. [Figure 28] 1 shows an illustrative example of a representation of a database that may be used to track key usage, according to at least one embodiment. [Figure 29] 1 illustrates an illustrative example of an environment in which various embodiments may be implemented. [Figure 30] 1 shows a diagrammatic representation of information that may be associated with a key in accordance with at least one embodiment. [Figure 31] 1 illustrates a diagrammatic representation of key access annotations that may be included in association with a request, according to at least one embodiment. [Figure 32] 1 shows an illustrative example of a process for processing a request in accordance with at least one embodiment. [Figure 33] 1 shows an illustrative example of a process for processing a request in accordance with at least one embodiment. [Figure 34] 1 illustrates an environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0004] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described embodiments.

[0005] The techniques described and proposed herein enable enhanced data security in environments with distributed computing resources. In one example, the distributed computing environment includes one or more data services that may be implemented by suitable computing resources. The data services may enable various operations to be performed in connection with data. As one illustrative example, the distributed computing environment includes one or more data storage services. Electronic requests may be sent to the data storage services to perform data storage operations. Example operations are operations to store data using the data storage services and to retrieve data stored by the data storage services using the data storage services. Data services, including data storage services, may also perform operations that manipulate data. For example, in some embodiments, the data storage services may encrypt data.

[0006] Various embodiments of the present disclosure include a distributed computing environment including a cryptographic service implemented using appropriate computing resources. The cryptographic service may be implemented by a distributed system that receives electronic requests and, in response, performs cryptographic operations, such as encrypting plaintext and decrypting ciphertext. In some embodiments, the cryptographic service manages keys. In response to a request to perform a cryptographic operation, the cryptographic service may perform the cryptographic operation using the managed keys. For example, the cryptographic service may select an appropriate key to perform the cryptographic operation, perform the cryptographic operation, and provide one or more results of the cryptographic operation in response to the received request. In an alternative configuration, the cryptographic service may generate an envelope key (e.g., a session key used to encrypt a particular data item) and return the envelope key to the system that invokes the service's cryptographic operation. The system may then use the envelope key to perform the cryptographic operation.

[0007] In some embodiments, a cryptographic service manages keys for multiple tenants of a computing resource service provider. A computing resource tenant may be an entity (e.g., an organization or individual) operating as a customer of the computing resource provider. The customer may remotely and programmatically configure and operate resources physically hosted by the computing resource provider. When a customer submits a request to a cryptographic service to perform a cryptographic operation (or when an entity submits a request to a cryptographic service), the cryptographic service may select a key managed by the cryptographic service for the customer to perform the cryptographic operation. Keys managed by a cryptographic service may be securely managed so that other users and / or data services do not have access to the keys of others. Lack of access by an entity (e.g., a user, customer, service) to another entity's key may mean that the entity does not have an approved way to obtain the key of others and / or to have systems managing the keys of others use the key at the entity's direction. For example, a cryptographic service may manage keys on behalf of a customer so that other customers cannot both have access to that customer's key(s) and cause the cryptographic service to perform cryptographic operations using that customer's key(s). As another example, a cryptographic service may manage keys so that other services, such as data storage services, cannot cause the cryptographic service to perform cryptographic operations using some or all of the keys. Unauthorized access to keys may be prevented by appropriate security measures, for example, so that unauthorized access is difficult or impossible. Difficulty may result from computational infeasibility to gain access and / or from the need for fraud (e.g., illegal, illicit, and / or otherwise prohibited, such as compromise of authorization credentials) to occur. Systems according to various embodiments may be configured to ensure an objective measure of computational infeasibility to gain access to keys.Such a measure may be measured, for example, in terms of the amount of time that a computer having a defined unit of computing power (e.g., a particular number of operations per unit of time) would take, on average, to decrypt the encrypted information required for authorized access to the key.

[0008] As mentioned, a cryptographic service may receive requests from various entities, such as customers of a computing resource provider. A cryptographic service may also receive requests from entities internal to the computing resource provider. For example, in some embodiments, a data service implemented by a computing resource provider may send a request to a cryptographic service to have the cryptographic service perform a cryptographic operation. As an example, a customer may send a request to a data storage service to store a data object. The request may indicate that the data object should be encrypted when stored. The data storage service communicates the request to the cryptographic service to perform the cryptographic operation. The cryptographic operation may, for example, be the encryption of a key used by the data storage service to encrypt the data object. The cryptographic operation may be the encryption of the data object itself. The cryptographic operation may be to generate an envelope key that the data storage service can use to encrypt the data object.

[0009] Systems according to various embodiments implement various security measures to provide enhanced data security. For example, in various embodiments, a cryptographic service is limited in the manner in which it can utilize the keys it manages. For example, in some embodiments, a cryptographic service is configured to only use keys corresponding to a customer upon appropriate authorization. If a request to use a customer's key purports to originate from the customer (i.e., from a computing device operating on behalf of the customer), the cryptographic service may be configured to require that the request be digitally signed using an appropriate certificate owned by the customer. If a request to use a customer's key originates from another data service, the cryptographic service may be configured to require that the data service provide proof that the signed request to the data service was made by the customer. In some embodiments, for example, a data service is configured to acquire and provide a token that serves as proof of an authenticated customer request. Other security measures may also be incorporated into the configuration of an electronic environment that includes a cryptographic service. For example, in some embodiments, a cryptographic service is configured to restrict key usage according to context. As one illustrative example, a cryptographic service may be configured to use a key for encryption for requests from a customer or from a data service acting on behalf of a customer. However, the cryptographic service may be configured to only use the key for decryption upon request from a customer (but not from another data service). In this manner, if the data service is compromised, the data service cannot force the cryptographic service to decrypt the data.

[0010] Various security measures may be incorporated into a cryptographic service and / or its electronic environment. Some security measures may, in some embodiments, be managed according to configurable policies. As an example, a cryptographic service may utilize an application programming interface (API) that allows a user to configure policies on a key. The policies on a key, when processed by the cryptographic service, may be determinative of whether the key can be used in a particular context. The policies may, for example, restrict the identities of users and / or systems that can direct use of the key, limit the time a key can be used, limit data regarding which keys are used to perform cryptographic operations, and provide other restrictions. The policies may provide explicit restrictions (e.g., who cannot use the key) and / or provide explicit authorization (e.g., who can use the key). Furthermore, policies may be complexly configured to generally provide conditions under which a key can and cannot be used. When a request to perform a cryptographic operation using a key is received, any policies on the key may be accessed and processed to determine whether the request can be fulfilled according to the policies.

[0011] Various embodiments of the present disclosure relate to the enforcement of policies associated with keys that may be managed by a cryptographic service. Users of a cryptographic service, such as customers of a computing resource provider that hosts the cryptographic service, may specify policies on keys that are enforced by the cryptographic service. The policies may encode who can instruct the cryptographic service to use the key, what operations may be performed using the key, under what circumstances the key may be used, and / or other constraints and / or privileges associated with key usage.

[0012] In one embodiment, data associated with the ciphertext is used to enforce a policy. The data associated with the ciphertext may be data obtained through the use of a cipher, such as an Advanced Encryption Standard (AES) mode. For example, inputs to a cipher algorithm may include plaintext and associated data to be encrypted. The cipher algorithm may use a key to encrypt the plaintext and provide an authentication output, such as a message authentication code (MAC), that enables determining whether the associated data has been altered. The authentication output may be determined at least in part based on the associated data and the plaintext.

[0013] Policy enforcement may be based, at least in part, on associated data. For example, some policies may require that associated data have a specific value before decrypted ciphertext (i.e., plaintext) is provided. An authentication output (e.g., a MAC) may be used to ensure that the associated data has not been altered and therefore policy enforcement is performed correctly. The associated data may be any suitable data, and the data itself may be explicitly or implicitly specified by the policy. For example, a policy may specify that decrypted ciphertext (plaintext) can be provided only if the request to decrypt the ciphertext is submitted by a user with a user identifier encoded in the associated data used to encrypt the ciphertext. In this manner, if another user requests decryption of the ciphertext (without impersonating the user with the user identifier), the request will not be fulfilled because it conflicts with the policy. As another example, a policy may state that decrypted ciphertext can be provided only if the ciphertext is tagged with specified information. As yet another example, a policy may state that decrypted ciphertext can be provided only if the associated data is tagged equal to a hash of the plaintext, a hash of the ciphertext, or some other specified value. In general, embodiments of the present disclosure enable rich policy enforcement around the input or output of a cryptographic algorithm before the output of the cryptographic algorithm is revealed. In some embodiments, the associated data may itself represent a policy.

[0014] Various embodiments of the present disclosure also enable policies centered around key usage. For example, in some embodiments, keys are automatically rotated to prevent keys from being used long enough to enable a successful cryptographic attack that can reveal the key. To prevent keys from being used long enough to result in a possible security breach, a cryptographic service or other system that utilizes keys may track operations performed with the key. When a key identified by a key identifier (KeyID) has been used for a threshold number of operations, the key may be retired (e.g., unavailable for future encryption operations, but available for future decryption operations) and replaced with a new key identified by KeyID. In this manner, new keys are generated in a timely manner. Furthermore, various embodiments of the present disclosure perform such key rotation in a manner that is transparent to a particular entity. As an example, a customer of a computing resource provider or other entity may submit a request to a cryptographic service to perform an operation using a key identified by KeyID. The cryptographic service may perform key rotation independently of any request from the entity to perform key rotation. From the perspective of a customer or other entity, requests can still be serviced using the KeyID without any reprogramming or other reconfiguration required due to the key being retired and replaced with a new key.

[0015] In some embodiments, multiple systems supporting a cryptographic or other service may simultaneously have access to a key and be used to fulfill requests to perform cryptographic operations. For example, a cryptographic service may utilize a cluster of security modules, at least some of which store one or more keys redundantly. The service may assign operations to security modules and maintain its own counters. When a security module uses its assignment (e.g., performs its assigned number of operations using a key), the service may check whether the key is still usable or whether it should be retired. Note that a security module (or other computer system) may be configured to perform multiple types of operations using a key, such as encryption, decryption, digital signature generation, etc. In some embodiments, not all types of operations cause a security module to use a portion of its assignment of operations. For example, a decryption operation may not result in the assigned operation being used, while an encryption operation may result in the assigned operation being used. In general, in various embodiments, a cryptographic operation that results in the generation of new information (e.g., ciphertext and / or digital signatures) may result in the assigned operation being used, while a cryptographic operation that does not result in the generation of new information may not result in the assigned operation being used. Furthermore, different types of operations may result in different numbers of cryptographic operations being performed. As an example, encryption of plaintext may require varying amounts of cryptographic operations based at least in part on the size of the plaintext. For example, with the use of a block cipher, an assigned cryptographic operation may be used for each block of ciphertext that is generated.

[0016] If the total number of operations available for a key is still available, the service may allocate additional operations to the security module. If a key should be retired (e.g., because a counter so indicates), the service causes security modules that store the key redundantly to retire the key and replace it with a new key, where the new key can be generated or otherwise obtained by one security module and securely passed to the remaining security modules. In some embodiments, other security modules instead exhaust their allocated operations under the old key. If a security module malfunctions, becomes inoperable, is intentionally taken offline (e.g., for maintenance), and / or does not provide information about the number of operations it has performed using one or more keys and is otherwise unavailable to perform cryptographic operations, the service may treat that unavailability as a use of its allocation. For example, if a security module is allocated 1 million operations for each key in a set of keys and the security module becomes inoperable, the service may operate as if the security module had performed 1 million operations for each key in the set of keys. For example, the service may assign additional operations to the security module or another security module and adjust the counters accordingly, and / or cause one or more of the keys to be retired and replaced if the corresponding counters indicate that replacement is necessary.

[0017] Embodiments of the present disclosure also enable enhanced data security through annotations and / or federated key management techniques. In some embodiments, a request submitted to a service (such as a cryptographic service or other data service) may include or be otherwise associated with an annotation (also referred to as a key access annotation) that includes information that enables policy enforcement. In certain embodiments, a key access annotation must satisfy one or more conditions before the corresponding request can be fulfilled. In some embodiments, the one or more conditions include that the annotation be digitally signed using a key associated with a KeyID, where the KeyID identifies a different key that can be used to fulfill the request. The presence of a valid digital signature may indicate that the information in the annotation has not been altered and may also prove possession of the key used to generate the digital signature.

[0018] In some embodiments, the key access annotation may include an identifier for the owner of a key that can be used to fulfill the request. The key owner may be the entity hosting the system receiving the request, or may be another system, such as a third-party system. The system receiving the request may detect the presence of the identifier and, as appropriate, either process the request itself or send the request to the identified key owner for processing according to the identifier. The entity receiving the request and / or the key owner may verify the digital signature for policy enforcement, as described above and elsewhere herein. For example, if the digital signature is invalid, the recipient of the request may not pass the request to the key owner identified in the annotation. Similarly, if the key owner determines that the digital signature is invalid, it may reject the request. The entity receiving the request and the key owner may verify the same digital signature, or in some embodiments, the request includes at least two signatures, one for the recipient of the request and one for the key owner. Each signature may be generated using a key corresponding to the entity whose signature is intended to be verified.

[0019] Embodiments of the present disclosure also enable enhanced data security through mandatory delays before certain types of requests are fulfilled. For example, in some embodiments, decryption of certain data requires a delay before cleartext is provided in response to the corresponding request. During the delay, various actions can be taken to notify interested parties of the pending request to decrypt the information. In this manner, interested parties (e.g., an organization's compliance officer or other person authorized to allow cleartext to be provided) are given the opportunity to cancel the request before the cleartext is provided. In various embodiments, requests are easily canceled. For example, the requirements for canceling a request may be less stringent than the requirements for the request to be fulfilled. In this manner, unauthorized data leakage can be easily detected and / or prevented.

[0020] FIG. 1 is an example diagram 100 illustrating various embodiments of the present disclosure. In one embodiment, a cryptographic service performs cryptographic operations, which may include the application of one or more computations according to one or more cryptographic algorithms. As illustrated in FIG. 1, a cryptographic service allows a user or service to generate plaintext from ciphertext. In one example configuration, a cryptographic service can be used to encrypt / decrypt keys and use these keys to encrypt / decrypt data, such as data stored within a data storage service. For example, a cryptographic service may receive a request to generate plaintext from ciphertext encrypted under a key. The cryptographic service can determine that the requester is an authorized entity, decrypt the key using a master key, and return the decrypted key to the service, which can then use the decrypted key to generate plaintext from the ciphertext. In another configuration, the cryptographic service receives ciphertext and processes the received ciphertext into plaintext that is provided as a service by the cryptographic service. In this example, the ciphertext may be provided to the cryptographic service as part of an electronic request to the cryptographic service from an authorized entity, which may be a customer of the computing resource provider operating the cryptographic service and / or another service of the computing resource provider. 1 may utilize one or more cryptographically strong algorithms to encrypt data. Such cryptographically strong algorithms may include, for example, Advanced Encryption Standard (AES), Blowfish, Data Encryption Standard (DES), Triple DES, Serpent, or Twofish, and may be either asymmetric or symmetric key systems depending on the particular implementation selected. In general, a cryptographic service may utilize any encryption and / or decryption algorithm (cipher) or combination of algorithms that utilizes the data managed by the cryptographic service.

[0021] As described in more detail below, cryptographic services can be implemented in a variety of ways. In some embodiments, a cryptographic service is implemented by a computer system configured according to the following description. The computer system may itself comprise one or more computer systems. For example, a cryptographic service may be implemented as a network of computer systems collectively configured to perform cryptographic operations according to various embodiments. Or, stated another way, the computer system may be a distributed system. In some embodiments, ciphertext is information encrypted using a cryptographic algorithm. In the example of FIG. 1, ciphertext is the encrypted form of plaintext. Plaintext can be any information, and while its name does not include literal text, plaintext and ciphertext can be information encoded in any suitable form and do not necessarily include, but may include, textual information. For example, as illustrated in FIG. 1, plaintext and ciphertext include sequences of bits. Plaintext and ciphertext may also be represented in other ways, and in general, in any manner in which encryption and decryption can be performed by a computer system.

[0022] FIG. 2 shows an illustrative example of an environment 200 in which a cryptographic service such as that illustrated in FIG. 1 may be implemented. In the 200 environment, various components work together to provide secure data-related services. In this particular example, the environment 200 includes a cryptographic service, an authentication service, a data service front-end, and a data service back-end storage system. In one embodiment, the cryptographic service is configured within the environment 200 to perform cryptographic operations, such as by receiving plaintext from the data service front-end and providing ciphertext in return, or by providing an envelope key to the service so that the service can perform the cryptographic operation using the envelope key. The cryptographic service may perform additional functions, as described below, such as secure storage of keys for performing cryptographic operations, such as converting plaintext to ciphertext and decrypting ciphertext back to plaintext. The cryptographic service also performs operations associated with policy enforcement, such as by enforcing policies associated with keys stored therein. Example policies that may be enforced by the cryptographic service are provided below. The data service front-end in one embodiment is a system configured to receive and respond to requests sent over a network from various users. The request may be a request to perform an operation related to data stored or to be stored in a data service backend storage system. In environment 200, the authentication service, the cryptographic service, the data service front end, and the data service backend storage system may be systems of a computing resource provider that utilizes the systems to provide services to customers, represented by users, illustrated in Figure 2. The network illustrated in Figure 2 may be any suitable network or combination of networks, including those described below.

[0023] In some embodiments, an authentication service is a computer system configured to perform operations related to authenticating a user. For example, a data services front end may provide information from a user to the authentication service and, in return, receive information indicating whether a user request is authentic. The determination of whether a user request is authentic may be performed in any suitable manner, and the manner in which authentication is performed may vary among various embodiments. For example, in some embodiments, a user digitally signs a message sent to the data services front end. The digital signature may be generated using secret information available to both the authenticating entity (e.g., the user) and the authentication service (e.g., the private key of a key pair associated with the user). The request and the signature for the request may be provided to the authentication service, which may use the secret information to calculate a reference signature for comparison with the received signature to determine whether the request is authentic. If the request is authentic, the authentication service may provide information that the data services front end can use to prove that the request is authentic to other services, such as cryptographic services, so that the other services can act accordingly. For example, the authentication service may provide a token that another service can analyze to verify the authenticity of the request. A digital signature and / or token may have limited validity in various ways. For example, the digital signature and / or token is valid for a specific amount of time. In one example, the digital signature and / or token is generated based at least in part on a function (e.g., a hash-based message authentication code) that treats an input included with the digital signature and / or token for verification as a timestamp. An entity verifying a submitted digital signature and / or token may check that the received timestamp is sufficiently recent (e.g., within a specified amount of time from the current time) and generate a reference signature / token to use for the received timestamp. If the timestamp used to generate the submitted digital signature / token is not sufficiently recent and / or if the submitted signature / token and the reference signature / token do not match, authentication may fail.In this manner, if the electronic signature is compromised, the potential damage caused by the compromise is limited because the electronic signature is only valid for a short amount of time. Note that other methods of verifying authenticity are also considered within the scope of this disclosure.

[0024] In some embodiments, the data service backend storage system is a computer system that stores data according to requests received through the data service front-end. As discussed in more detail below, the data service backend storage system may store data in encrypted form. Data in the data service backend storage system may also be stored in unencrypted form. In some embodiments, an API implemented by the data service front-end allows a request to specify whether data stored in the data service backend storage system should be encrypted. Data that is encrypted and stored in the data service backend storage system may be encrypted in various ways according to various embodiments. For example, in various embodiments, data is encrypted using a key that is accessible to the cryptographic service but inaccessible to some or all systems in environment 200. Data may be encoded by the cryptographic service for storage in the data service backend storage system, and / or in some embodiments, data may be encrypted by another system, such as a user system or the system of the data service front-end, using a key that is decrypted by the cryptographic service. Examples of various ways that environment 200 may operate to encrypt data are provided below.

[0025] Numerous variations of environment 200 (and other environments described herein) are considered within the scope of this disclosure. For example, environment 200 may include additional services that may communicate with the cryptographic service and / or the authentication service. For example, environment 200 may include additional data storage services (each of which may comprise a front-end system and a back-end system) that may store data in different ways. For example, one data storage service may provide active access to data, where the data storage service performs the data storage service in a synchronous manner (e.g., a request to retrieve data may receive a synchronous response along with the retrieved data). Another data storage service may provide an archival data storage service. Such an archival data storage service may utilize asynchronous request processing. For example, a request to retrieve data may not receive a synchronous response including the retrieved data. Rather, the archival data storage service may require a second request to be submitted to obtain the retrieved data once it is ready to provide it. As another example, environment 200 may include a metering service that receives information from the cryptographic service (and / or other services) and uses that information to create billing records. The billing records may be used to bill customers for use of the cryptographic services (and / or other services). Additionally, information from the cryptographic services may provide guidance on how much fees should be charged. For example, in some instances, customers may be provided with a bill for use of the cryptographic services. In other instances, fees for use of the cryptographic services may be aligned with usage fees for other services, such as data services, that utilize the cryptographic services as part of their operation. Usage may be metered and billed in various ways, such as per operation, per period, and / or other ways. Other data services may also be included in environment 200 (or other environments described herein).

[0026] Additionally, FIG. 2 depicts a user interacting with the data services front end. It should be understood that the user may interact with the data services front end through a user device (e.g., a computer) not illustrated in the figure. Furthermore, the user depicted in FIG. 2 (and elsewhere in the figure) may also represent a non-human entity. For example, an automated process executing on a computer system may interact with the data services front end as described herein. As one illustrative example, the entity represented by the user in FIG. 2 may be a server that, as part of its operation, uses the data services front end to store and / or retrieve data from a data services backend storage system. As yet another example, the entity represented by the user in FIG. 2 may be an entity offered as a service of a computing resource provider that operates one or more of the services in FIG. 2. For example, the user in FIG. 2 may represent a virtual or other computer system of a program execution service provided by a computing resource provider. Other variations, including other environmental variations described below, are also considered within the scope of this disclosure.

[0027] For example, FIG. 3 shows an illustrative example of an environment 300 in which various embodiments of the present disclosure may be implemented. Similar to FIG. 2, the environment of FIG. 3 includes an authentication service, a data service front-end system (data service front-end), a cryptographic service, and a data service back-end storage system. The authentication service, data service front-end, cryptographic service, and data service back-end storage system may be configured as described above in connection with FIG. 2. For example, a user may access the data service front-end through a suitable communications network, although such a network is not illustrated in the figure. In the example environment 300 illustrated in FIG. 3, arrows are provided to represent the flow of information. In this example, a user sends a PUT request to the data service front-end. The PUT request may be a request to store specified data in the data service back-end storage system. In response to the PUT request, the data service front-end may determine whether the PUT request is authentic, i.e., whether the user submitted the request in a manner that allows the requested operation to be performed in accordance with an authentication policy implemented by the system.

[0028] FIG. 3 illustrates an exemplary example of how such an authentication decision may be made. In this particular example, the data service front end submits an authentication request to an authentication service. The authentication service may use the authentication request to determine whether a PUT request from a user is authentic. If the request is authentic, the authentication service may provide authentication credentials to the data service front end. The authentication credentials may be an electronic token or other information that another service, such as a cryptographic service, can use to independently determine that an authentic request has been received. In one exemplary example, the PUT request is sent along with a signature for the PUT request. The PUT request and its signature are provided through an authentication service that independently calculates what the signature should be if authentic. If the signature generated by the authentication service matches the signature provided by the user, the authentication service may determine that the PUT request is authentic and may provide authentication credentials accordingly. Determining whether the PUT request is authentic also includes one or more operations related to policy enforcement. For example, if the signature is valid but policy otherwise indicates that the PUT request should not be completed (e.g., the request was submitted during a time prohibited by policy), the authentication service may provide information indicating that the request is not authentic. (Note, however, that such policy enforcement may be performed by other components of environment 300.) The authentication service may generate the signature, such as by using a key shared by the authentication service and the user. The authentication credential, as noted, may be information that allows another service, such as a cryptographic service, to independently verify that the request is authentic. For example, using the cryptographic service example illustrated in FIG. 3, the authentication credential may be generated based at least in part on a key shared by both the authentication service and the cryptographic service, such as a key that is inaccessible to other services.

[0029] As illustrated in Figure 3, upon receiving an authentication credential from the authentication service, the data service front end provides the plaintext and the authentication credential to the cryptographic service. The plaintext and the authentication credential are provided to the cryptographic service in accordance with an API call or other electronic request (e.g., an Encrypt API call). The cryptographic service may analyze the authentication credential to determine whether to encrypt the plaintext.

[0030] Note that additional information may be provided to the cryptographic service. For example, an identifier for the key to be used to encrypt the plaintext may be provided as an input parameter to the API call from the data services front end (alternatively, the identifier may have been received from the user). Note, however, that the identifier may not be sent to the cryptographic service. For example, in various embodiments, it may be possible to separately determine which key to use to encrypt the plaintext. For example, information sent from the data services front end to the cryptographic service may include information associated with the user, such as an identifier for the user and / or an organization associated with the user, such as an identifier for the customer on whose behalf the user submitted the PUT request. Such information may be used by the cryptographic service to determine a default key to be used. In other words, the key may be implicitly specified by the information available for determining the key. In general, the determination of the key to be used may be performed in any suitable manner. Furthermore, in some embodiments, the cryptographic service may generate or select a key and provide an identifier for the generated or selected key to be used later. Another example of an API parameter may be an identifier for a master key for the customer account on which the encryption operation is performed.

[0031] As illustrated in FIG. 3, if the authentication credentials are sufficient for the cryptographic service to encrypt the plaintext, the cryptographic service can perform one or more cryptographic operations. In one embodiment, the one or more cryptographic operations can include an operation to generate an envelope key used to encrypt the plaintext. The envelope key can be a randomly generated symmetric key or the private key of a key pair. After the envelope key is generated, the cryptographic service can encrypt the envelope key with a master key specified in the API call and either persistently store the encrypted envelope key (e.g., by storing the encrypted key in a storage service or some other persistent storage) or discard it. In addition, the cryptographic service can send the plaintext version of the envelope key as well as the encrypted envelope key to the data service front end. The data service can then encrypt the plaintext (i.e., data associated with the encryption request) using the plaintext version of the envelope key and store the envelope key in persistent storage in association with an identifier for the master key used to encrypt the envelope key. In addition, the data service can discard the plaintext version of the envelope key. Thus, in some embodiments, the data service can no longer decrypt the ciphertext after discarding the plaintext version of the envelope key.

[0032] In alternative embodiments, the cryptographic operation may involve encrypting plaintext. For example, a cryptographic service may encrypt plaintext and provide the ciphertext to a data service front-end storage system. The data service front-end may then provide the ciphertext to a data service back-end storage system for persistent storage according to the operation. Other information may also be transmitted from the data service front-end to the data service back-end storage system. For example, an identifier for the key used to encrypt the plaintext to generate the ciphertext may be provided by the data service back-end storage system along with the ciphertext for storage. Other information may also be provided, such as metadata identifying the user and / or the user's organization.

[0033] As with all environments described herein, many variations are considered within the scope of this disclosure. For example, the flow of information between various components of environment 300 may differ from that shown. For example, information flowing from one component to another via intermediate components (e.g., data from an authentication service to a cryptographic service and / or data from a cryptographic service to a data service backend storage system) may be provided directly to its destination and / or via other intermediate components of environment 300 (not necessarily included in the figure). As another example, a PUT request (and hereafter a GET request) is provided for illustrative purposes. However, any suitable request for performing the described operations may be used.

[0034] 4 shows an illustrative example of a process 400 that may be used to store data within a data storage service according to an embodiment. Process 400 may be performed, for example, by the data service front-end illustrated in FIG. 3. Some or all of process 400 (or any other process described herein, or variations and / or combinations thereof) may be performed under the control of one or more computer systems comprised of executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively execute on one or more processors, by hardware, or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0035] As illustrated in FIG. 4 , process 400 includes receiving 402 a PUT request. The PUT request may be received electronically over a network and may include information associated with the request, such as information required for authentication, such as a digital signature of the PUT request. In response to receiving the PUT request, process 400 may include submitting 404 an authentication request. For example, a system executed within process 400 may submit the authentication request (e.g., via an appropriately configured API call) to a separate authentication service such as described above in connection with FIG. 3 . Similarly, a data services front end that performs its own authentication may submit the authentication request to an authentication module implemented by the data services front end. In general, the authentication request may be submitted in any suitable manner according to various embodiments.

[0036] Once the authentication request is submitted, an authentication response is received 406 by the entity that submitted 404 the authentication request. For example, referring to FIG. 3 , the authentication service may provide a response to a data service front end that includes proof of authentication for use by other services. Other information, such as an indication of whether the authentication was successful, may also be sent. A determination may be made 408 as to whether the request is authentic. The authenticity of the request may depend on one or more factors checked by an entity, such as the authentication service, or a combination of entities that collectively perform such checks. Authenticity may require, for example, that the request provide a required valid certificate (e.g., a digital signature generated by a private key shared by the checking entities) and / or that policy allows the request to be fulfilled. From the perspective of the system submitting 404 the authentication request and receiving the authentication response, authenticity may depend on the received authentication response. Thus, in some embodiments, the determination 408 as to whether the request is authentic may be performed based at least in part on the received authentication response. For example, if the authentication was not authentic, the authentication response may so indicate, and a decision 408 may be made accordingly. Similarly, the response may implicitly indicate that the authentication request is authentic, such as by not including information that would be included if the request were not authentic. If the PUT request is determined 408 to be inauthentic, the PUT request may be rejected 410. Rejecting the PUT request may be performed in any suitable manner and may depend on the various embodiments in which process 400 is being performed. For example, rejecting 410 the PUT request may include sending a message to the user who submitted the PUT request. The message may indicate that the request was rejected. Rejecting the request may also include providing information about why the request was rejected, such as an incorrect digital signature or other reasons that may be used to determine how to resolve any issues that resulted in the PUT request being inauthentic or unauthorized.

[0037] If the PUT request is determined to be authentic and authorized 408, in one embodiment, process 400 includes performing 412 one or more cryptographic operations that result in encryption of the plaintext. For example, a request (e.g., a properly configured API call) is submitted to a cryptographic service, providing a key used to perform one or more cryptographic operations. The request provided to the cryptographic service may be provided with proof that the PUT request is authentic, so that the cryptographic service can independently decide whether to perform the cryptographic operation (e.g., encrypting the plaintext to provide ciphertext or generating an envelope key that can be used to encrypt the plaintext). However, in various embodiments, authentication proof may not be provided to the cryptographic service; for example, the cryptographic service may operate according to the request it receives. For example, when the cryptographic service receives a request from a data services front-end, the cryptographic service may rely on the fact that the data services front-end has already independently verified the authentication of the request. In such embodiments and other embodiments, the data services front-end may authenticate itself with the cryptographic service to provide an additional layer of security. The cryptographic service may generate or otherwise obtain a key, encrypt the obtained key, or otherwise obtain an encrypted key (e.g., from memory), and provide the obtained key and the encrypted obtained key upon request. The obtained key may be encrypted using a key identified in a request to the cryptographic service. The obtained key may be used to encrypt plaintext, and after encrypting the plaintext, the obtained key may be discarded (e.g., irrevocably deleted from memory). In an alternative embodiment, a system executing process 400 may generate or otherwise obtain a key used to perform one or more cryptographic operations and provide the obtained key to a cryptographic service for encryption.

[0038] In some embodiments, performing one or more cryptographic operations may result in ciphertext being generated. The ciphertext generated as a result of the one or more cryptographic operations may be stored 414 for possible subsequent retrieval. As noted above, storage of the ciphertext may include storage of additional information that enables subsequent decryption of the ciphertext. For example, the ciphertext may be stored along with an identifier of a key used to encrypt the plaintext into the ciphertext, such that the key with the identifier can later be used to decrypt the ciphertext to obtain the plaintext. Storage of the ciphertext may also be performed in any suitable manner. For example, storage of the ciphertext may be performed by a data service backend storage system, as described above.

[0039] FIG. 5 therefore shows an illustrative example of environment 500 and an information flow illustrating how plaintext may be obtained. Environment 500 in this example includes an authentication service, a cryptographic service, a data service front-end, and a data service back-end storage system. The authentication service, cryptographic service, data service front-end, and data service back-end storage system may be systems such as those described above. As illustrated in FIG. 5 , the data service front-end is configured to receive a GET request from a user and provide plaintext in return. To do this, the data service front-end may also be configured to submit an authentication request to the authentication service, which itself may be configured to provide authentication credentials to the data service front-end, if appropriate. The data service front-end may also be configured to send a request to the cryptographic service, causing the cryptographic service to perform one or more cryptographic operations related to decrypting the data. In embodiments in which envelope keys are used, the data service may submit a request (e.g., an API call) to the cryptographic service that includes or specifies the encrypted envelope key (or an identifier for the encrypted envelope key), authentication credentials, and an identifier of the master key used to encrypt the envelope key to the cryptographic service. The cryptographic service can determine whether the authentication credentials are sufficient to allow the operation, and if so, decrypt the envelope key. The decrypted envelope key can be sent back to the data service, which can use it to decrypt the encrypted plaintext. The data service can then discard the decrypted plaintext key.

[0040] In an alternative embodiment, the data services front-end may be configured to provide the received authentication credentials to the cryptographic service along with the ciphertext for the cryptographic service to decrypt. The cryptographic service may be configured accordingly to determine whether the authentication credentials are sufficient to allow decryption of the ciphertext, and if the authentication credentials are sufficient, to decrypt the ciphertext using an appropriate key (which may be identified to the cryptographic service by the data services front-end), and provide the decrypted ciphertext (plaintext) to the data services front-end. To provide the ciphertext to the cryptographic service, the data services front-end may be configured to obtain the ciphertext from the data services back-end storage system (e.g., via an appropriately configured API call).

[0041] FIG. 6 shows an illustrative example of a process 600 that may be used to obtain plaintext in accordance with various embodiments. Process 600 may be performed, for example, by the data services front-end system (data services front-end) illustrated above in connection with FIG. 5 , although process 600 and variations thereof may be performed by any suitable system. In one embodiment, process 600 includes receiving 602 a GET request (or other suitable request) from a user. Receiving the GET request may be performed as described above in connection with other types of requests. Upon receiving 602 the GET request, an authentication request may be submitted 604 to an authentication service or in any manner as described above. An authentication response may be received in response. Based at least in part on the received authentication response, a determination may be made 608 whether the GET request is authentic. If 608 the GET request is determined to be inauthentic, process 600 may include rejecting 610 the request, which may be performed in various manners in accordance with various embodiments, as described above.

[0042] If it is determined 608 that the GET request is authentic, process 600 may include retrieving the ciphertext from storage. Retrieving 612 the ciphertext from storage may be performed in any suitable manner. For example, with reference to environment 500 described above in connection with FIG. 5, the data service front-end may submit a request for the ciphertext to a data service back-end storage system and receive the ciphertext in response. In general, the ciphertext may be obtained from storage in any suitable manner. Upon receiving the ciphertext, process 600 may include performing 614 one or more operations related to decrypting the ciphertext. For example, in one embodiment, the data storage service may send a request to a cryptographic service to perform 614 one or more cryptographic operations related to decrypting the ciphertext. In one example configuration, the data service may send an API call to the cryptographic service that includes authentication credentials for the encrypted envelope key (or an identifier for the encrypted envelope key) and an identifier for the master key used to encrypt the envelope key to the cryptographic service. The cryptographic service can determine whether the authentication credentials are sufficient to allow the operation, and if so, decrypt the envelope key. The decrypted envelope key can be sent back to the data service, which can use it to decrypt the encrypted plaintext.

[0043] In another configuration, the ciphertext may be provided to a cryptographic service, such as the cryptographic service described above in connection with FIG. 5. Other information, such as proof of authentication that the cryptographic service can use to determine whether to decrypt the ciphertext, may also be provided to the cryptographic service. Additionally, in some embodiments, an identifier for the key to be used by the cryptographic service to decrypt the ciphertext may be provided to the cryptographic service. However, in other embodiments, the key may be implicitly indicated to the cryptographic service. For example, the cryptographic service may use a default key associated with the customer indicated to the cryptographic service. In general, any manner in which the cryptographic service can determine which key to use to decrypt the ciphertext may be used.

[0044] As illustrated in FIG. 6 , after the ciphertext is decrypted, process 600 may include providing 616 a response to the GET request. Providing a response to the GET request may be performed in various manners according to various embodiments. For example, providing a response to the GET request may include providing cleartext. In other embodiments, the cleartext may be a key that is later used to decrypt other encrypted information provided in response to the GET request. In general, depending on the role of the cleartext in a particular embodiment of the present disclosure, providing a response to the GET request may be performed in various ways.

[0045] As noted, various embodiments of the present disclosure enable data to be stored by a data storage service in a variety of ways. FIG. 7 shows an illustrative example of an environment 700 with arrows indicating the flow of information according to such an embodiment. As illustrated in FIG. 7, the environment 700 includes an authentication service, a cryptographic service, a data service front-end, and a data service back-end storage system, as described above. In this particular example, the data service front-end is a computer system configured to receive PUT requests from various users. The PUT requests may include or specify a data object to be stored by the data service back-end storage system. The PUT requests may also specify a key identifier for a key to be used to encrypt the data object. The data service front-end may also be configured to interact with the authentication service to provide authentication credentials to a cryptographic service operable to receive a key and key identifier, as described above, and in response provide a key encrypted by the key identified by the key identifier. The data service front-end may then effect storage in the data service back-end storage system. The data that may be stored may include a data object encrypted by the key. The data that may be stored may also include a key encrypted by the key identified by the key identifier. As discussed elsewhere herein, the encrypted data object and the encrypted key may be stored in different services.

[0046] As illustrated in Figure 7, the data services front end is configured to provide encrypted information to a data services backend storage system for storage. In this example, the data services front end is configured to provide a data object encrypted under a key and a key encrypted under another key having KeyID. Note that for purposes of illustration, curly bracket notation is used to represent encryption. Specifically, the information within the curly brackets is the information encrypted under the key specified in the subscript. For example, {Data Object} Key represents the data "Data Object" encrypted under the key "Key". Key identifiers may also appear in subscript using this curly bracket notation. When a key identifier appears in subscript, the information within the curly brackets is encrypted under the key identified by that key identifier. For example, {Data Object} KeyID indicates that the data object "Data Object" is encrypted under the key identified by the key identifier "KeyID". Similarly, {Key} KeyID represents that the key "Key" is encrypted under the key identified by the identifier "KeyID." In other words, this disclosure uses both keys and key identifiers in subscripts, and the meaning of the subscripts should be clear from the context. The ciphertext may contain additional metadata that can be used to determine the identity of the associated decryption key.

[0047] FIG. 8 shows an illustrative example of a process 800 that may be performed to store a data object in a data storage system, such as the data service back-end storage system described above in connection with FIG. 7. Process 800 may be performed by any suitable system, such as by the data service front-end system described above in connection with FIG. 7. In one embodiment, process 800 includes receiving 802 a PUT request for a data object. Receiving a PUT request for a data object may be performed in any suitable manner, as described above. Note that the data object may be received in connection with the request or may be received from another service. For example, the request may include an identifier for the data object that may be obtained from another service using the identifier. Similar to the other processes described above, process 800 in one embodiment includes submitting 804 an authentication request and receiving 806 an authentication response. The received authentication response 806 may be used to determine 808 whether the PUT request is an authentic request. If 808 the PUT request is determined to be inauthentic, process 800 may include rejecting 810 the request, as described above. If the PUT request is determined 808 to be authentic, process 800 may include obtaining 812 a key identifier (KeyID), such as a keyID for a master key used to encrypt the envelope key. Obtaining 812 the KeyID may be performed in any suitable manner, and the manner in which the KeyID is obtained may vary according to various embodiments. For example, as illustrated in FIG. 7, the PUT request may specify a KeyID. As another example, the user's identity, or an identity otherwise associated with the user, may be used to obtain an identifier or default key. As another example, a ciphertext may provide an indication of the associated KeyID. As yet another example, one or more policy decisions may be used to determine which key identifier to obtain.

[0048] In one embodiment, process 800 also includes generating 814 a key, such as an envelope key. Key generation may be performed in any suitable manner, such as by a cryptographic service or a service requesting a cryptographic operation from a cryptographic service (e.g., a data storage service). For example, the key may be generated using a key derivation function using appropriate inputs to the key derivation function. Examples of key derivation functions include KDF1 defined in IEEE Std 1363 2000, key derivation functions defined in ANSI X9.42, and HMAC-based key derivation functions, such as the HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) specified in RFC 5869. As another example, the key may be generated by a random or pseudo-random number generator, a hardware entropy source, or a deterministic random bit generator, such as that specified by the National Institute of Standards and Technology Special Publication (NIST SP) 800-90A. 8 shows process 800 including generating 814 a key, it should be noted that the key may be obtained in other ways, such as by retrieval from storage. In other words, the key may be pre-generated.

[0049] Continuing with process 800 illustrated in FIG. 8 , in some embodiments, process 800 includes using 816 the generated key to encrypt a data object. For example, in embodiments in which the cryptographic service generates the key, the cryptographic service can provide the key, a KeyID, and an encrypted copy of the key to the data service. For example, with reference to FIG. 7 , the data service front end may receive the envelope key and a KeyID for the master key used to encrypt the envelope key from the cryptographic service, along with any other relevant information, such as authentication credentials. The plaintext copy of the encryption key may then be used to encrypt the data object. The plaintext copy of the encryption key may be discarded, and the encrypted data object and encrypted key may then be stored 818. For example, with reference to FIG. 7 , the data service front end may send the encrypted data object and encrypted key to a data service backend storage system for storage. In configurations in which the service generates the key, the service may provide the key and KeyID to the cryptographic service. For example, the data service front end may send the envelope key and the KeyID for the master key used to encrypt the envelope key, along with any associated information such as authentication credentials, to the cryptographic service. A plaintext copy of the encryption key may then be used to encrypt the data object. The service may discard the plaintext copy of the encryption key, and the encrypted data object as well as the encrypted key may then be stored. For example, with reference to Figure 7, the data service front end may send the encrypted data object and the encrypted key to a data service backend storage system for storage.

[0050] The encrypted data object and the encrypted envelope key may be stored without a plaintext version of the key; that is, the plaintext key may be inaccessible to the data service backend storage system and one or more other systems. The key under which the data object is encrypted (e.g., a master key) may be made inaccessible in any suitable manner. In some embodiments, this is achieved by storing it in memory accessible only to the cryptographic service. In some other embodiments, this may be achieved by storing the master key within, or otherwise under the protection of, a hardware or other security module. In some embodiments, the memory location storing the plaintext envelope key (e.g., the data service's memory) may be allowed to be overwritten, or the memory location storing the key may be intentionally overwritten to make the data service front-end inaccessible to the key. As another example, the plaintext envelope key may be maintained in volatile memory that eventually ceases to store the key. In this manner, the envelope key is accessible only if it is decrypted using the key identified by KeyID, or if it is otherwise obtained in an unauthorized manner, which may be computationally infeasible, such as by decrypting the key without the key identified by KeyID. In other words, the key identified by KeyID is required for authorized access to the key under which the data object is encrypted. In this manner, because decrypting the data object requires access to the key, which can only be obtained by decryption using the key identified by KeyID, or by other means that are not computationally feasible, if the data service backend storage system of FIG. 7 is compromised, such a compromise will not provide access to the unencrypted data object.

[0051] As described, various embodiments of the present disclosure enable users to both store data objects and retrieve them in a secure manner. FIG. 9 therefore shows an illustrative example of an environment 900 that may be used to obtain data objects from storage. As illustrated in FIG. 9, the environment 900 includes an authentication service, a cryptographic service, a data service front-end system, and a data service back-end storage system. The authentication service, the cryptographic service, the data service front-end, and the data service back-end storage system may be computer systems as described above. As illustrated in FIG. 9, the data service front-end system is configured to receive a data object request and provide the data object in response. To provide the data object in response, the data storage front-end system in this embodiment is configured to interact with the authentication service, the cryptographic service, and the data service back-end storage system, as illustrated in FIG. 9. For example, in various embodiments, the data service front-end system is configured to submit an authentication request to the authentication service and receive authentication credentials in response to the request. As another example, the data services front end may be configured to provide a key encrypted with a key identified by a KeyID and authentication credentials to the cryptographic service, the cryptographic service being operable to determine whether to provide the key based at least in part on the authentication credentials, and, if determined to provide the key, providing the key to the data services front end. The data services front end may also be configured to provide other information, such as the KeyID, to the cryptographic service. However, in some embodiments, the KeyID may be indicated to the cryptographic service implicitly, such as by association with other information provided to the cryptographic service. Note also that in some embodiments, a user provides the KeyID to the data services front end in connection with submitting a request to the data services front end.9, the data service front end in some embodiments is configured to request a data object from a data service backend storage system and, in response, receive a data object encrypted by a key and a key encrypted by a key identified by a KeyID. In some embodiments, the cryptographic service may be operable to refuse to perform decryption of ciphertext that was not generated using a key associated with a specified KeyID.

[0052] The data service front end, in one embodiment, is configured to decrypt the data object using a key received from the cryptographic service and provide the decrypted data object to a user. FIG. 10 therefore shows an illustrative example of a process 1000 that may be used to provide a decrypted object in accordance with various embodiments. Process 1000 may be performed by any suitable system, such as a data service front end system as described in connection with FIG. 9 . In one embodiment, process 1000 includes receiving 1002 a GET request for a data object. Receiving the GET request for the data object may be performed in any suitable manner, as described above in connection with other types of requests. For example, the GET request for the data object may include information used to authenticate the request and / or other information. Process 1000 therefore, in one embodiment, includes submitting 1004 an authentication request to an authentication system and receiving 1006 an authentication response, similar to other processes described herein. Submitting the authentication request and receiving the authentication response may be performed in any suitable manner, as described above. The authentication response may be used to determine 1008 whether the GET request is authentic. If the GET request is determined 1008 to be inauthentic, the process 1000 in one embodiment includes rejecting the request 1010. However, if the GET request is determined 1008 to be authentic, the process 1000 in one embodiment includes retrieving the encrypted data object and the encrypted key from storage 1012. For example, the data services front-end system may obtain the encrypted data object and the encrypted key from the data services back-end storage system illustrated above in connection with FIG.

[0053] In one embodiment, process 1000 includes providing 1014 the encrypted envelope key to a cryptographic service. Providing 1014 the encrypted envelope key to a cryptographic service may be performed in any suitable manner and may be provided along with other information, such as authentication credentials, that enable the cryptographic service to determine whether to decrypt the encrypted key. Additionally, providing 1014 the encrypted envelope key to a cryptographic service may include providing an identifier of a key needed for authorized decryption of the encrypted envelope key, to enable the cryptographic service to select a key identified by the identifier from among multiple keys managed by the cryptographic service. As noted above, however, the key may be identified implicitly. The cryptographic service may therefore select the appropriate key to decrypt the encrypted key. Thus, in one embodiment, process 1000 includes receiving 1016 the decrypted envelope key from the cryptographic service. For example, if the cryptographic service determines that the authentication credentials are valid and / or that decryption is allowable according to any applicable policy, the cryptographic service may provide the decrypted key to a system seeking to decrypt the data object. The data object may then be decrypted using the decrypted envelope key 1018. The decrypted data object may then be provided 1020 to a requestor, such as a user or other system that submitted a GET request.

[0054] In many cases, it is desirable for a user (i.e., typically a device utilizing the cryptographic service) to interact directly with the cryptographic service. FIG. 11 therefore shows an illustrative example of an environment 1100 that enables direct user access to a cryptographic service. Included in environment 1100 is an authentication service, a data service front-end, and a data service back-end storage system. The authentication service, data service front-end, and data service back-end storage system may be as described above. For example, the data service front-end may be configured to receive and respond to requests from users over a suitable network as illustrated in FIG. 11. As part of responding to requests from users over the network, the data service front-end may also be configured to interact with the authentication service to determine whether the user request is authentic and / or enforce policies on the request. The data service front-end may also be configured to interact with the data service back-end storage system as part of fulfilling a user request. User requests may include, for example, PUT requests to store data in the back-end storage system and GET requests to retrieve data from the data service back-end storage system. As above, other requests, such as a request to delete data stored in a data service backend storage system, a request to update data stored in a data service backend storage system, etc., may also be used in accordance with various embodiments.

[0055] In the particular example of FIG. 11 , in environment 1100, the cryptographic service includes a cryptographic service front-end and a data service back-end. Like the data service front-end, the cryptographic service front-end is configured to receive and respond to requests from users over a network. The cryptographic service front-end is also configured to interact with an authentication service to determine whether a user request is authentic. Determining whether a user request is authentic can be performed in a convenient manner as described above. Note that while the cryptographic service front-end and the data service front-end interact with the same authentication service, the cryptographic service front-end and the data service front-end can interact with different authentication services. Additionally, the cryptographic service front-end can be configured to enforce policies when responding to user requests.

[0056] The cryptographic services front-end, in some embodiments, can be configured to interact with a cryptographic services back-end. The cryptographic services back-end is configured to perform cryptographic operations according to instructions received from the cryptographic services front-end. Cryptographic operations include encryption, decryption, hash calculations, and the like. The environment 1100 can be used by a user to have plaintext encrypted by the cryptographic services, for example, so that the encrypted data can be stored in a data services back-end storage system. Examples of such uses of the environment 1100 are provided below. Additionally, detailed examples of example cryptographic services are also provided below.

[0057] Data may be stored in the data service backend storage system in any suitable manner, as described above. For example, the techniques for storing encrypted data in the backend storage system described above may be used in environment 1100. For example, although not illustrated, the data service front-end may communicate with the cryptographic service front-end to have the cryptographic service backend encrypt data and then store it in the data service backend storage system. The encrypted data may be a data object and / or an encrypted key used to encrypt the data object. In environment 1100, data may be stored in other ways in the data service backend storage system. For example, a user may provide plaintext to be encrypted by the cryptographic service and may receive ciphertext in response. The user may then interact with or submit a request to the data service front-end to request that the ciphertext be stored in the data service backend storage system. The data service front-end, in this example, may store the ciphertext in any manner. For example, the data service front-end and backend storage system may be configured to be independent of whether the data is encrypted.

[0058] Additionally, as with all environments illustrated herein, additional front-end systems may be logically disposed between the user, the data services front-end, the cryptographic services front-end, and possibly other front-end systems to coordinate actions between the systems. For example, in some embodiments, a user may interact with a front-end system that itself interacts with the cryptographic services front-end and the data services front-end, making operation more convenient from the user's perspective. For example, the user may request that a data object be encrypted and stored, and the front-end system responds to that request by appropriate interaction with the cryptographic services front-end and the data services front-end. However, from the user's perspective, such may be performed by a single request. Other variations are also within the scope of this disclosure.

[0059] FIG. 12 shows an illustrative example of an environment 1200 that may be used to implement various embodiments of the present disclosure. In FIG. 12, the environment 1200 is configured to allow a user to store ciphertext in a data service backend storage system. Thus, as illustrated in FIG. 12, the environment 1200 includes a data service front-end, a data service back-end storage system, an authentication service, a cryptographic service front-end, and a cryptographic service back-end. The data service back-end storage system, the data service front-end, the authentication service, the cryptographic service front-end, and the cryptographic service back-end may be systems such as those described above in connection with FIG. 11. For example, as illustrated in FIG. 12, the data service front-end may be configured to receive and respond to user requests and may also be configured to enforce policies on the user requests. The data service front-end may be configured to submit an authentication request to the authentication service as part of the response to the request and receive authentication credentials in response. Upon successful authentication, the data service front end may be further configured to interact with the data service backend storage system to obtain encrypted, and possibly unencrypted, data objects from the data service backend storage system, which may then be provided to the user.

[0060] As illustrated in FIG. 12, the cryptographic services front-end is also configured to provide an authentication request to the authentication service and receive an authentication certificate in response. The authentication certificate can be used to obtain a service from the cryptographic services back-end. For example, the cryptographic services front-end can be configured to provide a ciphertext along with the authentication certificate to the cryptographic services back-end, which can be configured to decrypt the ciphertext and provide the ciphertext in return. As illustrated in FIG. 12, the ciphertext can be an encrypted key, and the cryptographic services back-end can decrypt the encrypted key and provide the decrypted key, which is a plaintext key, to the cryptographic services front-end, which is further configured to provide the plaintext key to a user. The user can then use the key to decrypt an encrypted data object received from the data services front-end or to decrypt an encrypted data object stored within the user's domain (e.g., in a data center or computer system operated or controlled by the user). In this example, the user may have obtained an encrypted key from the data services front-end. For example, the user may have submitted a request to the data services front-end for a data object and / or a key used to encrypt the data object. Although illustrated as a single request in Figure 11, separate requests may be made for both the data object and the key. As illustrated in Figure 11, the data service front end may obtain the encrypted data object and encrypted key from the data service backend storage system and provide the encrypted data object and encrypted key to the user.

[0061] As with all environments illustrated herein, variations are considered within the scope of this disclosure. For example, FIG. 12 shows a data object encrypted under a key and the key encrypted by another key identified by a key identifier that has been provided to a user. Additional levels of encryption may also be used. For example, the data object may be encrypted under a key accessible only to the user (and / or inaccessible by other components of environment 1200). The key used to encrypt the data object may also be encrypted under a key accessible only to the user. In this example, unauthorized access (user absent) to components of environment 1200 still does not provide access to the unencrypted contents of the data object, because access to the user's key still requires authorized decryption.

[0062] As another example, in the environment 1200 illustrated in FIG. 12 , the data service front-end and data service back-end storage system do not have access to the keys needed to decrypt the encrypted data and therefore do not have access to the cleartext data stored by the data service back-end storage system. However, in some embodiments, access may be granted to the data service front-end and / or the data service back-end storage system. For example, in one embodiment, temporary access to the keys may be provided to the data service front-end to enable the data service front-end to obtain the encrypted data, decrypt the encrypted data, use the decrypted data for a particular purpose (e.g., indexing), and then delete or otherwise lose access to the decrypted data. Such actions may be governed by policies enforced by the data service front-end and / or the cryptographic service and may require approval from the user.

[0063] FIG. 13 shows an illustrative example of a process 1300 that may be used to obtain an encrypted data object and an encrypted key from a data services backend storage system, such as described above. Process 1300 may be performed, for example, by the data services front-end system described above in connection with FIG. 12. In one embodiment, process 1300 includes receiving 1302 a GET request for the encrypted data object. Receiving the GET request may be performed in any suitable manner, such as by receiving the request via an API call to the data services front-end system. As a result of receiving the GET request, process 1300 may include submitting 1304 an authentication request and receiving 1306 an authentication response. Submitting 1304 the authentication request and receiving 1306 the authentication response may be performed in any suitable manner, such as described above. The authentication response may be used to determine 1308 whether the GET request is authentic. If 1308 the GET request is determined to be inauthentic, process 1300 may include rejecting 1310 the GET request. Denying the GET request 1310 may be performed in any suitable manner, as described above. However, if the GET request is determined to be authentic 1308, process 1300 may include providing 1312 the encrypted data object along with an encrypted key that, when decrypted, can be used to decrypt the encrypted data object. As with all processes described herein, it should be noted that many variations are considered within the scope of this disclosure. For example, process 1300 may be configured to respond to a GET request when authentic by providing the encrypted data object without providing the encrypted key. The requester, be it a user or system submitting the GET request, may obtain the encrypted key in other ways. For example, in some embodiments, the user may store the encrypted key itself in a data storage system under the user's control.As another example, one storage service may store the encrypted data object and another may store the encrypted key, and the user may obtain the encrypted data object and the encrypted key from the respective service. As another example, another service or a third party to the user may be used to store the encrypted key, and the user may obtain the encrypted key upon request. In general, any method by which the encrypted key can be provided may be used.

[0064] As illustrated in FIG. 13 , process 1300 may result in an entity being provided with a data object and an encrypted key that can be used to decrypt the data object. In various embodiments, the encrypted key must be decrypted in order to decrypt the data object. FIG. 14 therefore shows an illustrative example of a process 1400 that may be used to provide a decrypted key to an entity that needs such decrypted key to decrypt a data object encrypted using the decrypted key. Process 1400 may be performed by any suitable system, such as by the cryptographic services front-end system described above in connection with FIG. 12 . In one embodiment, process 1400 includes receiving 1402 a decryption for decrypting a key using another key having a specified KeyID. While process 1400 is described in connection with decrypting a key, it should be noted that process 1400 may be suitable for decrypting data generally. The decryption request may be received 1402 in any suitable manner as described above (e.g., via an appropriately configured API call). Furthermore, the decryption request may be received by any entity appropriate to the context in which process 1400 is being executed. For example, the decryption request may originate from a user or from another system, such as the data service front end discussed above. The decryption request may also include the data to be decrypted (e.g., a key) or a reference thereto. The KeyID may be specified in any suitable manner. For example, in some embodiments, the decryption request includes the KeyID or a reference to the KeyID, i.e., information that can be used to determine the KeyID. As described above, the KeyID may also be specified implicitly. For example, the KeyID may be obtained by association with available data, such as the identity of the requestor who submitted the decryption request. For example, the key corresponding to the KeyID may be a default key for the requestor or the entity on whose behalf the request was submitted.

[0065] In one embodiment, process 1400 includes submitting 1404 an authentication request and receiving 1406 an authentication response. Submitting 1404 the authentication request and receiving 1406 the authentication response may be performed in any suitable manner, as described above. Further, as described above, the received authentication response may be used to determine 1408 whether the GET request is authentic. If 1408 the GET request is determined to be inauthentic, process 1400 may include rejecting 1410 the GET request. Rejecting 1410 the GET request may be performed in any suitable manner, as described above. However, if 1408 the GET request is determined to be authentic, process 1400 may include accessing policy information for the specified KeyID and / or requester. The policy information may include information including one or more policies related to the KeyID and / or requester.

[0066] In one embodiment, the accessed policy information is used to determine 1414 whether any applicable policies permit decryption of the key with the specified KeyID. If it is determined 1414 that the policies do not permit decryption of the key specified by the KeyID, the process 1400 may include rejecting 1410 the GET request as described above. However, if it is determined 1414 that the policies do permit decryption of the key with the specified KeyID, the process 1400 may include decrypting 1416 the key using the key identified by the KeyID. Once the key is decrypted using the key with the KeyID, the decrypted key may then be provided 1418 to the requestor (or, in some embodiments, another authorized destination) that submitted the decryption request, such as by transmission over a network.

[0067] As illustrated in environment 1200 discussed above, a user may obtain an encrypted data object and a key for decrypting the data object in a variety of ways. Figure 15 shows an illustrative example of a process 1500 that may be used to obtain plaintext in accordance with various embodiments. Process 1500 may be performed by any suitable system, such as by a system operated and / or hosted by a user as described in connection with Figure 12. Other suitable systems include systems operating on behalf of a user, possibly following a pre-programmed process, but not necessarily according to real-time user input provided.

[0068] In one embodiment, process 1500 includes receiving 1502 the ciphertext from a data storage service. Requesting 1502 the ciphertext from the data storage service may be performed in any suitable manner, such as those described above. For example, a system performing process 1500 may request 1502 the ciphertext using an appropriately configured API call within environment 1200 illustrated above in connection with FIG. 12 and / or via process 1300 described above in connection with FIG. 13.

[0069] Process 1500 may also include receiving the ciphertext and the encrypted key. Receiving the ciphertext and the encrypted key may be performed in any suitable manner. For example, the ciphertext and the encrypted key may be received in response to a request for the ciphertext from the data storage service. However, in general, the ciphertext and the encrypted key may be received in other suitable manners 1504. For example, the request to receive the ciphertext from the data storage service may be an asynchronous request, and the ciphertext may be received pursuant to a subsequently submitted separate request 1504. Furthermore, the ciphertext and the encrypted key may be provided in a single response or may be obtained separately, such as by different responses (which may be from the same or different systems). As another example, the system performing process 1500 may store the encrypted key locally or otherwise, and the encrypted key may be retrieved from local memory.

[0070] In one embodiment, process 1500 includes requesting decryption of an encrypted key using a key with a specified KeyID. The KeyID may be specified in any suitable manner, as described above. Furthermore, it should be noted that a system executing process 1500 may be able to specify the KeyID in any suitable manner. For example, the encrypted key and / or information provided therewith may specify the KeyID. As another example, a system executing process 1500 may have local or remote access to information that allows the KeyID to be determined. A local or remote database may, for example, associate a data object identifier with a key identifier for a key used to encrypt the data object. In general, any manner that may allow a system to specify the KeyID may be used. Furthermore, in some embodiments, the KeyID need not be specified, such as when information provided to the cryptographic service is sufficient to determine the KeyID. The request 1506 for decryption of an encrypted key may be performed in any suitable manner, such as in connection with the environment described above in connection with FIG. 12 and / or by execution of process 1400 described above in connection with FIG. 14.

[0071] In one embodiment, process 1500 includes receiving 1508 a decrypted key. Receiving 1508 a decrypted key may be performed in any suitable manner. For example, the decrypted key may be received in response to a request to decrypt the encrypted key. As another example, the request to decrypt the encrypted key may be an asynchronous request, with a separate request being submitted to receive the decrypted key. In general, the decrypted key may be received in any suitable manner. Furthermore, as with all information flow from one device to another, the passing of information may be performed using a secure channel. For example, the decrypted key may be re-encrypted for decryption by the entity receiving the decrypted key. In general, any manner of secure communication may be used to pass information from one entity to another.

[0072] Once the decrypted key is received 1508, process 1500 may include decrypting 1510 the ciphertext using the decrypted key, thereby obtaining the plaintext. Note that, as with all processes described herein, variations are considered within the scope of this disclosure. For example, process 1500 shows the request for the ciphertext and the request for the decryption of the encrypted key being performed sequentially. However, as with many of the operations described herein in connection with various processes, the operations need not be performed sequentially in various embodiments. For example, if the system performing process 1500 has access to, or is otherwise able to access, the encrypted key prior to the request for the ciphertext, the system may request the ciphertext and request the decryption of the encrypted key in parallel or in an order different from that illustrated. Other variations are also within the scope of this disclosure.

[0073] As described above, various embodiments of the present disclosure are directed to providing cryptographic services. The cryptographic services may be provided by a cryptographic service system as described above. Accordingly, FIG. 16 shows an illustrative example of a cryptographic service 1600 according to various embodiments. As illustrated in FIG. 16 and described above, the cryptographic service 1600 logically comprises a front-end system and a back-end system. Both the front-end system and the back-end system may be implemented by one or more computer systems configured to perform the operations described herein. For example, as illustrated in FIG. 16, the front-end system of the cryptographic service 1600 implements a request API and a policy configuration API. The request API, in some embodiments, is an API configured for cryptographic requests and other operations performed by the cryptographic service. Thus, requests may be issued to the front-end system via the request API so that such cryptographic operations may be performed by the cryptographic service.

[0074] The Request API can be configured with the following high-level request examples available: CreateKey(KeyID) Encrypt(KeyID, Data, [AAD]) Decrypt(KeyID, Ciphertext, [AAD]) Shred(KeyID) ReKey(Ciphertext, OldKeyID, NewKeyID).

[0075] The CreateKey(KeyID) request, in some embodiments, causes a cryptographic service to create a key identified by the KeyID identified in the request. Upon receiving the request, the cryptographic service may generate a key and associate it with a KeyID. It should be noted that the KeyID identifier may be, but is not necessarily, a unique identifier. For example, the KeyID may identify a family of keys. For example, in some embodiments, key rotation is performed. Key rotation may involve replacing a key with another key to prevent the collection of enough decrypted data to allow for the effective cracking of the cipher used. When performed at the direction of an entity different from the cryptographic service, use of the CreateKey(KeyID) request may cause the cryptographic service to create a new key to replace the old key identified by the KeyID. The old key may still be identified by the KeyID, but may, for example, be used only for decryption (of data already encrypted using the old key) and not for future encryption. As another example, in some embodiments, users of a cryptographic service provide unique key identifiers, but it is possible that two different customers could provide the same identifier. In such cases, the identifier may not uniquely identify a key, or even a family of keys. Various measures may be taken to address this. For example, the identity or other information associated with the user of the cryptographic service may be used to identify the appropriate key or family of keys. In still other embodiments, the cryptographic service may assign KeyIDs randomly, sequentially, or using any other method.

[0076] Note that when a KeyID does not uniquely identify a key, various systems may be provided to enable appropriate functionality. For example, in various embodiments, the family of keys identified by the KeyID is finite. When a decryption operation is requested using a key identified by the KeyID, additional data (e.g., a timestamp of when the encryption was performed) may enable determining the appropriate key to use. In some embodiments, the ciphertext may include information indicating the key version. In some embodiments, every possible key is used to provide different decryptions of the data. Because there are a finite number of keys, the appropriate decryption may be selected from those provided. In some embodiments, decryption using the key is performed in a manner that allows the cryptographic service to detect that the ciphertext was not generated at least in part based on the key, such as by using authenticated encryption. Other variations are also within the scope of this disclosure.

[0077] The Encrypt(KeyID, Data, [AAD]) request may be used to cause a cryptographic service to encrypt specific data using the key identified by KeyID. Additional Authenticated Data (AAD) may be used for various purposes and may be data that is not necessarily encrypted, but is authenticated, for example, by a digital signature, a message authentication code, or generally a keyed hash value included with the AAD. In some embodiments, the ciphertext is generated including at least a portion of the AAD. In some embodiments, the AAD is provided separately during decryption. In some other embodiments, the AAD is generated at decryption time, based at least in part on the request and / or other metadata, such that decryption is successful only if the metadata passes. In some embodiments, policy may constrain whether cryptographic operations can be performed on a particular AAD. Processing of an Encrypt(KeyID, Data, [AAD]) request according to programming logic and / or policies enforced by the cryptographic service may require both that the AAD contain a specific value and that the AAD be authentic (e.g., unaltered since the original transmission). Similarly, a Decrypt(KeyID, Ciphertext, [AAD]) request may be used to have a cryptographic service decrypt the specified ciphertext using the key identified by KeyID. The AAD in the Decrypt(KeyID, Ciphertext, [AAD]) request may be used as described above. For example, processing of a Decrypt(KeyID, Ciphertext, [AAD]) according to programming logic and / or policies enforced by the cryptographic service may require both that the AAD contain a particular value and that the AAD be authentic (e.g., unaltered from the original transmission).

[0078] Shred(KeyID) may be used in some embodiments to cause a cryptographic service to electronically shred a key or family of keys identified by a specified KeyID. Electronic shredding may include making the key no longer accessible. For example, use of the Shred(KeyID) request may cause a cryptographic system to instruct one or more hardware devices to perform a SecureErase operation on one or more keys identified by a specified KeyID. In general, the key(s) identified by the KeyID may be electronically shredded in any suitable manner, such as by overwriting other data (e.g., a series of zeros or ones, or a random string) over the data encoding the key. If the key(s) are stored encrypted under a key, the key used to encrypt the key(s) may be electronically shredded, thereby causing loss of access to the key(s). In some embodiments, the shredding operation may render decryption operations that point to the shredded KeyIDs inoperable at some determined point in the future. Other manners of securely and permanently destroying any possible access to the key(s) may be used.

[0079] The ReKey(Ciphertext, OldKeyID, NewKeyID) request may, in some embodiments, be used to cause a cryptographic service to encrypt ciphertext under a different key. Upon receiving a ReKey(Ciphertext, OldKeyID, NewKeyID) request, the cryptographic service may decrypt the specified ciphertext using the key identified by OldKeyID and then encrypt the decrypted ciphertext using the key identified by NewKeyID. If the key identified by NewKeyID does not already exist, the cryptographic service may generate a key to use and associate the generated key with the specified NewKeyID as described in connection with the Create(KeyID) request described above. In some embodiments, a ReKey operation may be operable to allow data to be transmitted between isolated instances of a cryptographic service. In some embodiments, policy may allow a rekey operation to be performed on a ciphertext but not allow the same requestor to directly decrypt the ciphertext. In some embodiments, ReKey may assist in rekeying ciphertext from a key identified by a first KeyID in a first account to a key identified by a KeyID in a second account.

[0080] Similarly, the front-end system, in one embodiment, may implement a policy configuration API that allows users to submit requests to configure policies for the performance of cryptographic operations and other policy-related operations. Policies may, in various embodiments, be associated with keys, groups of keys, accounts, users, and other logical entities. Example policies that may be configured via the policy configuration API are provided below. In one embodiment, the cryptographic services policy configuration API includes the following requests:

[0081] SetKeyPolicy(KeyID, Policy) Suspend(KeyID, Public Key) Reinstate(KeyID, Private Key)

[0082] In one embodiment, the SetKeyPolicy(KeyID, Policy) request may be used to cause a cryptographic service to store a policy on the key (or family of keys) identified by KeyID. A policy may be determinative information about whether a requested cryptographic operation can be performed within a particular context. A policy may be encoded in a declarative access control policy language, such as eXtensible Access Control Markup Language (XACML), Enterprise Privacy Authorization Language (EPAL), Amazon Web Services Access Policy Language, Microsoft SecPol, or any suitable method for encoding one or more conditions that must be met for a cryptographic operation to be performed. A policy may define what operations can be performed, when they can be performed, which entities can make authorized requests for operations to be performed, what information is required for a particular request to be authorized, etc. Additionally, policies may be defined and / or enforced using access control lists, privileges associated with users, and / or operation bitmasks in addition to or instead of the examples listed above. An example policy is shown below:

[0083] In some embodiments, a cryptographic service may support a suspend operation, for example, using the Suspend(KeyID, Public Key) API call. The suspend operation allows a customer of a cryptographic service to deny a cryptographic service operator use of or access to a key. This may be useful for customers concerned about hidden legal commands or other circumstances in which a cryptographic service operator may be tricked into performing certain operations using a key. It may also be useful for customers who wish to lock down certain data and make it inaccessible online. In some embodiments, a suspend operation may involve receiving a public key from a customer and encrypting a key specified by a given KeyID with the received public key, and shredding the key specified by KeyID to prevent the provider from accessing the suspended key unless the private key associated with the public key is provided, for example, using the Reinstate(KeyID, Private Key) API call specifying the KeyID and including the private key. In some embodiments, a suspend operation may involve encrypting the key associated with the specified KeyID with another key managed by the cryptographic service, including, but not limited to, one created for the purpose of the immediate suspend operation. The ciphertext produced by this operation can be provided to the customer and is not stored within the cryptographic service. The original key, identified by the KeyID, can then be destroyed. The cryptographic service may be operable to receive the provided ciphertext and re-import the suspended key. In some embodiments, the ciphertext may be generated in a manner that prevents the cryptographic service from returning a decrypted version to the customer.

[0084] As illustrated in FIG. 16 , cryptographic services 1600, in some embodiments, includes a backend system that itself comprises various components. For example, the backend system in this example includes a request processing system, which may be a subsystem of cryptographic services 1600 configured to perform operations according to requests received via either a request API or a policy configuration API. For example, the request processing component may receive requests received via the request API, which may determine whether such requests are authentic and therefore capable of being fulfilled, and fulfill the requests. Fulfilling the requests may include, for example, performing and / or having performed cryptographic operations. The request processing unit may be configured to interact with an authentication interface that enables the request processing unit to determine whether the request is authentic. The authentication interface may be configured to interact with an authentication system such as described above. For example, when a request is received by the request processing unit, the request processing unit may utilize the authentication interface to interact with an authentication service that provides authentication credentials that can be used to effect the execution of cryptographic operations, if appropriate.

[0085] The backend system of cryptographic services 1600 also includes, in this illustrative example, multiple security modules (cryptographic modules) and a policy enforcement module. One or more of the security modules may be hardware security modules, although in various embodiments, the security modules may be any suitable computing device configured to have the functionality described herein. Each security module in one embodiment stores multiple keys associated with a KeyID. Each security module may be configured to securely store the keys so that they are inaccessible to other components of cryptographic services 1600 and / or other components of other systems. In one embodiment, some or all of the security modules comply with at least one security standard. For example, in some embodiments, the security modules are each validated in compliance with the Federal Information Processing Standard (FIPS) outlined in FIPS Publications 140-1 and / or 140-2, such as at one or more security levels outlined in FIPS Publication 140-2. Additionally, in some embodiments, each security module is certified under the Cryptographic Module Validation Program (CMVP). The security module may be implemented as a hardware security module (HSM) or a separate security module having some or all of the functionality of an HSM. In some embodiments, a validated module is used to bootstrap operations. In some embodiments, a customer can configure some keys to be stored within and operated only by the validated module, and other keys to be operated by software. In some embodiments, the performance or cost associated with these various options may vary.

[0086] The security modules may be configured to perform cryptographic operations according to instructions provided by the request processing unit. For example, the request processing unit may provide a ciphertext and a KeyID to the appropriate security module, along with instructions for the security module to decrypt the ciphertext using a key associated with the KeyID and provide the plaintext accordingly. In some embodiments, the back-end system of cryptographic service 1600 stores multiple keys forming a key space. Each of the security modules may store all of the keys in the key space, although variations are considered within the scope of this disclosure. For example, each of the security modules may store a subspace of the key space. The subspaces of the key space stored by the security modules may overlap because keys are stored redundantly across security modules. In some embodiments, a particular key may be stored only within a designated geographic region. In some embodiments, a particular key may be accessible only to operators with a particular certification or clearance level. In some embodiments, a particular key may be stored in, and used only with, a module operated by a particular third-party provider under contract with the provider of data storage services. In some embodiments, the security module's configuration control may require a lawful order to enforce use of the key, as well as approval by the customer to involve either additional entities to be enforced or additional jurisdictions to enforce the action. In some embodiments, customers may be provided with independent options for the jurisdiction in which their ciphertext is stored and in which their keys are stored. In some embodiments, the security module that stores the key may be configured to provide audit information to the owner of the key, and the security module may be configured so that the customer cannot suppress the generation and provision of audit information.In some embodiments, a security module may be configured to independently verify signatures generated by a customer, such that a provider (e.g., hosting the security module) cannot perform operations under keys stored by the security module. Additionally, some security models may store all of a key space, while some security modules may store subspaces of the key space. Other variations are also within the scope of this disclosure. In cases where different security modules store different subspaces of the key space, the request processing unit may be configured with a relational table or other mechanism, etc., to determine which security module to instruct to perform cryptographic operations according to various requests.

[0087] In one embodiment, the policy enforcement module is configured to obtain information from the request processing unit and determine, based at least in part on the information, whether a request received from the API can be fulfilled. For example, when a request to perform a cryptographic operation is received via the request API, the request processing unit may interact with the policy enforcement module to determine whether fulfillment of the request is authorized by any appropriate policies, e.g., policies applicable to the specified KeyID in the request and / or other policies associated with the requester. If the policy enforcement module authorizes fulfillment of the request, the request processing unit may accordingly instruct the appropriate security module to perform the cryptographic operation in accordance with the fulfillment of the request.

[0088] As with all figures described herein, many variations are considered within the scope of this disclosure. For example, FIG. 16 shows a policy enforcement module separate from the security modules. However, each security module may include a policy enforcement module in addition to or instead of the separately illustrated policy enforcement module. As such, each security module may be independently configured to enforce a policy. Additionally, as another example, each security module may include a policy enforcement module that enforces a different policy than the policy enforced by the separate policy enforcement module. Many other variations are considered within the scope of this disclosure.

[0089] As described above, various policies may be configured by a user in or associated with a KeyID such that the policies may be enforced when a request specifies a cryptographic operation to be performed in association with a key corresponding to the KeyID. FIG. 17 provides an illustrative example of a process 1700 for updating a policy according to various embodiments. Process 1700 may be performed by any suitable system, such as by a cryptographic service system as described above in connection with FIG. 16. In one embodiment, process 1300 includes receiving 1302 a request to update a policy for a KeyID. The request may be received 1302 in any suitable manner. For example, referring to FIG. 16 as an example, the request may be received via a policy configuration API of a front-end system of cryptographic services 1600 described above. The request may be received in any suitable manner.

[0090] In one embodiment, process 1700 includes submitting 1704 an authentication request and receiving 1706 an authentication response. Submitting 1704 the authentication request and receiving 1706 the authentication response may be performed in any suitable manner, as described above. As further described above, the received authentication response may be used to determine 1708 whether the request to update the policy for the KeyID is authentic. If 1708 the received request to update the policy for the KeyID is determined to be inauthentic, the request may be denied 1710. Denying 1710 the request may be performed in any suitable manner, as described above. However, if 1708 the received request to update the policy for the KeyID is determined to be authentic, process 1700 may include accessing 1712 policy information applicable to the requester. The policy information may be information upon which any policy applicable to the requester may be enforced. For example, within an organization utilizing the cryptographic services performed by process 1700, only certain users of the organization may be permitted to update the policy for the KeyID. The policy information may indicate which users can have the cryptographic service update the policy for the KeyID and / or even whether the policy is updatable according to existing policies. For example, in some embodiments, a cryptographic service may receive a request to enforce a new policy. The cryptographic service may check whether any existing policies allow the new policy to be introduced. If the cryptographic service determines that existing policies do not allow the new policy to be enforced, the request may be denied. In general, policy information may be any information usable for enforcing policies applicable to the requestor.

[0091] As illustrated in Figure 17, process 1700 includes using policy information to determine 1704 whether policy allows the requested update to be performed. If it is determined 1714 that policy does not allow the requested update to be performed, process 1700 may include denying 1710 the request as described above. However, if it is determined 1714 that policy does allow the requested update to be performed, process 1700 may include updating 1716 the policy for the KeyID. Updating the policy for the KeyID may include updating policy information and storing the updated policy according to or in association with the KeyID. The updated policy information may be stored, for example, by a policy enforcement module of the cryptographic service as described above in connection with Figure 16.

[0092] Policies may also be enforced by other components of the electronic environment operating in conjunction with the cryptographic service. For example, with reference to FIG. 2 discussed above, the cryptographic service may provide an electronic representation of the policy to the data service front end for enforcement by the data service front end. Such may be useful in situations where the data service is better suited to enforce the policy. For example, whether an action is permitted by a policy may be based at least in part on information accessible to the data service front end but not accessible to the cryptographic service. As an example, a policy may be based on data stored by a data service backend storage system on behalf of a customer associated with the policy.

[0093] As described above, cryptographic services may include various systems that enable enforcement of policies according to the policies on keys having KeyIDs. Accordingly, FIG. 18 shows an illustrated example of a process 1800 that may be used to enforce policies. Process 1800 may be performed by any suitable system, such as by a cryptographic service system as described above in connection with FIG. 16. In one embodiment, process 1800 includes receiving 1802 a request to perform one or more cryptographic operations using a key having a KeyID. While FIG. 18 illustrates process 1800 as being performed in connection with a request to perform one or more cryptographic operations, it should be noted that process 1800 may be suitable for use with any request to perform an operation that is not necessarily cryptographic. Example operations are described above.

[0094] A determination may be made 1804 whether the received request is authentic. Determining whether the received request is authentic may be performed in any suitable manner, as described above. For example, determining 1804 whether the request is authentic may include submitting an authentication request and receiving an authentication response, as described above. If the request is determined to be inauthentic 1804, process 1800 may include rejecting 1806 the request. Rejecting 1806 may be performed in any suitable manner, as described above. However, if the request is determined to be authentic 1804, process 1800 may include accessing 1808 the KeyID and / or requestor policy information. Accessing the KeyID and / or requestor policy information may be performed in any suitable manner. For example, accessing the KeyID and / or requestor policy information may be performed by accessing storage policy information from one or more storage systems that store such policy information. The access policy information may be used to determine 1810 whether the policy allows one or more operations to be performed.

[0095] If the policy determines that the one or more operations do not allow the operation to be performed 1810, the process 1800 may include denying the request 1806. However, if the policy determines that the one or more operations do allow the operation to be performed, the process 1800 may include performing the requested one or more cryptographic operations 1812. One or more results of the performance of the one or more cryptographic operations may be provided 1814, such as provided to the requestor who submitted the received request 1802 to perform the one or more cryptographic operations. In some embodiments, information derived at least in part from the permitted requests and / or denied requests may be provided via an audit subsystem.

[0096] As discussed, embodiments of the present disclosure enable flexible policy configuration and enforcement. In some embodiments, a policy may stipulate which services can perform which operations in which contexts. For example, a policy on a key may allow a data storage service to have a cryptographic service perform encryption operations but not decryption operations. A policy on a key may also include one or more conditions on ciphertext and / or decrypted plaintext. For example, a policy may require that the ciphertext and / or plaintext produce a particular hash value (which may be a keyed hash value) before the results of the operation are provided in response to a request. A policy may specify one or more restrictions and / or permissions based at least in part on the time, the Internet Protocol (IP) from which the request originates, the type of content being encrypted / decrypted, the AAD, and / or other information.

[0097] Many variations are considered within the scope of this disclosure. For example, the various embodiments discussed above discuss interaction with a separate authentication service. However, components of the environments discussed above may have their own authorization components, and determining whether a request is authentic may or may not involve communication with another entity. Furthermore, each of the environments discussed above is illustrated in conjunction with specific operations and functions enabled by the environment. The techniques discussed above in conjunction with different environments may be combined, and generally, environments consistent with this disclosure may enable flexible use of various technologies. By way of example only, a cryptographic service may be used to encrypt both keys and other content, such as keyless data objects, upon request. As another example, a cryptographic service may be configured to receive and respond to requests from both users (e.g., customers of a computing resource provider) and other services (e.g., data storage services). In some embodiments, a cryptographic service and / or an associated authentication service may be configured for use with a mobile device to perform encryption of stored data. In some embodiments, at least one unlock pin may be verified by the cryptographic service. In still other embodiments, the cryptographic service may receive information generated by hardware attestation as part of its operation. In some embodiments, the cryptographic service may be operable to provide digital rights management services for content.

[0098] As described above, various embodiments of the present disclosure enable rich policy enforcement and configurability. Many cryptographic systems provide authenticated encryption modes of operation in which cryptographic operations can be performed to simultaneously provide confidentiality, integrity, and authenticity assurances to data. Confidentiality can be provided by encryption of plaintext data. Authenticity can be provided for both the plaintext and associated data, which may remain unencrypted. In such systems, modifications to either the ciphertext or the associated data can cause failure of decryption of the ciphertext.

[0099] In some embodiments, data associated with the plaintext is used in policy enforcement. Accordingly, FIG. 19 shows an illustrative example of a process 1900 for encrypting data in a manner that enables policy enforcement using the associated data in accordance with various embodiments. Process 1900 may be performed by any suitable system, such as a cryptographic service and / or security module. As illustrated, process 1900 includes obtaining 1902 plaintext. The plaintext may be obtained in any suitable manner. For example, in a service provider environment as described above, a user (e.g., a customer) may provide data to be encrypted. As another example, obtaining 1902 may include generating a key (to be encrypted) and / or obtaining a key to be encrypted. The key may be used as described above.

[0100] As shown, process 1900 includes obtaining associated data. The associated data may be any data associated with or to be associated with the plaintext. The associated data may be any data on which one or more policies are based, at least in part. Examples are provided below. Furthermore, the associated data may be encoded in any suitable manner, such as eXtensible Markup Language (XML), JavaScript Object Notation (JSON), Abstract Syntax Notation One (ASN1), YAML Ain't Markup Language (also known as Yet Another Markup Language) (YAML), or another structured extensible data format. In one embodiment, process 1900 includes generating 1906 a message authentication code (MAC) and ciphertext based, at least in part, on the plaintext and associated data. The combination of the MAC and ciphertext, such as the output of an AES-GCM cipher, may be referred to as authenticated ciphertext. Generating the MAC and ciphertext may be performed in any suitable manner, and the generation of the MAC and ciphertext may depend on which cryptosystem(s) are used. For example, in one embodiment, the Advanced Encryption Standard (AES) supports associated authenticated data (AAD) when operated in either CCM mode or GCM mode, where CCM stands for Counter with CBC-MAC, GCM stands for Galois / Counter Mode, and CBC stands for cipher block chaining. When using AES in either CCM or GCM mode, plaintext and associated data may be provided as inputs to obtain a concatenated pair output of ciphertext and MAC for both the plaintext and associated data. Note that while AES-CCM and AES-GCM are provided for illustrative purposes, other authenticated encryption schemes may also be used, and the techniques explicitly described herein may be modified accordingly. For example, the techniques of this disclosure are generally applicable to symmetric block ciphers supporting authenticated encryption modes.Additionally, other encryption schemes can be combined with MAC functions in accordance with various embodiments of the present disclosure. Suitable encryption scheme and MAC function combinations include, but are not limited to, those in which the encryption scheme is secure under chosen-plaintext attacks and the MAC function is unforgeable under chosen-message attacks. Furthermore, while various embodiments of the present disclosure utilize ciphers that produce a single output that encodes both the ciphertext and the MAC, the MAC and ciphertext may be generated using different ciphers. Furthermore, while a MAC is used as an illustrative example, other values ​​not typically referred to as MACs may also be used, such as common hashes, checksums, signatures, and / or other values ​​that can be used in place of a MAC. Thus, ciphers with automated encryption modes that support associated data include ciphers that use other cryptographic primitives in addition to or as a substitute for a MAC.

[0101] Furthermore, generating the MAC and ciphertext may be performed in various ways according to various embodiments. For example, in some embodiments, the plaintext is provided to a security module, as described above. The security module may be configured to generate the MAC. In other embodiments, a component of the electronic environment other than the security module generates the MAC and ciphertext. In such embodiments, the security module may be used to decrypt the key used to generate the MAC and ciphertext when it is in plaintext form. Once generated, the MAC and ciphertext (i.e., authenticated ciphertext) are provided 1908. In some embodiments, associated data is also provided. The MAC and ciphertext may be provided in various ways in various implementations utilizing process 1900 and variations thereof. For example, in some embodiments, the MAC and ciphertext are provided to a user, as described above, or provided to a data service, as described above, for processing by the data service. Furthermore, while the associated data may be provided as noted, in various embodiments, the associated data is not provided and / or is generally maintained in plaintext form. As one example, the associated data may not be provided if it is independently obtainable. As an illustrative example, if the associated data is a persistent identifier for the device (e.g., an identifier for a storage device), the associated data may be retrieved later when needed for policy enforcement and / or other purposes.

[0102] As described above, various embodiments of the present disclosure utilize security modules to provide enhanced data security. FIG. 20 shows an illustrative example of a process 2000 that may be used to encrypt data in a manner that enables novel and rich policy enforcement, according to various embodiments. Process 2000 may be performed by any suitable system, such as a cryptographic service and / or security module. As illustrated in FIG. 20, process 2000 includes obtaining plaintext and associated data. As above, the plaintext and associated data may be received in a single communication, in separate communications, and / or from separate entities. Once obtained, the plaintext, associated data, and KeyID are provided to a security module 2004. The security module may be as described above. Further, the security module may be selected from multiple security modules participating in an electronic environment, such as an environment supporting a cryptographic service, as described above. The KeyID may be as described above and may be specified in a request to encrypt plaintext submitted to a cryptographic service, or may be specified in another manner. Further, in an alternative embodiment of process 2000, the KeyID may not be specified. For example, in some embodiments, a security module may select a KeyID and / or generate a key that is later assigned a KeyID. In such embodiments, process 2000 may be modified to provide the KeyID from the security module.

[0103] Returning to the illustrated embodiment, process 2000 may include receiving 2006 a ciphertext and a MAC from a security module. The ciphertext may be encrypted under a key identified by KeyID. Because the MAC may be a MAC for a combination of both the plaintext and the associated data, any modifications to the ciphertext or the associated data will cause the MAC to fail checking. Note that, as above, variations include those in which the MAC is based at least in part on the associated data but is generated independently of the plaintext. Furthermore, as described above, the ciphertext and MAC may be provided together (such as from the output of using an AES-CCM or AES-GCM cipher) or separately. Once received from the security module, the MAC and ciphertext are provided 2008 to an appropriate entity, such as a user of the cryptographic service or a data service operating in conjunction with the cryptographic service, as described above.

[0104] As discussed above, security modules can be used in a variety of ways to enhance the protection of data. As discussed above, in some embodiments, a security module is used to encrypt a key that is used (in plaintext form) to encrypt other data. Accordingly, FIG. 21 shows an illustrative example of a process 2100 that can be used in such a situation. Process 2100 is performed by any suitable system, such as a cryptographic service and / or security module. In one embodiment, process 2100 includes obtaining 2102 plaintext and associated data, as described above. As illustrated, process 2100 includes providing 2104 to the security module the encrypted key, the associated data, and a KeyID that identifies a key usable by the security module to decrypt the encrypted key. Thus, process 2100 includes obtaining a decrypted key from the security module using the key identified by the KeyID to decrypt the encrypted key. The obtained key can be used to encrypt the plaintext, thereby computing 2108 the ciphertext and MAC. The ciphertext may be an encryption of the plaintext, and the MAC may be for (i.e., based at least in part on) the associated data, or both the associated data and the plaintext, as described above. Once encrypted, process 2100 may include providing 2110 the MAC and ciphertext, as described above. Additionally, the process may also include losing access to the decrypted key 2112, which may be performed in any suitable manner, such as by a SecureErase operation, overwriting memory storing the decrypted key, removing power to volatile memory storing the key, and / or any other manner in which the system performing process 2100 (e.g., some cryptographic systems lack a security module). Although illustrated in parallel, providing the associated data, MAC, and / or ciphertext, and losing access to the key may be performed sequentially, in an order that may vary among various embodiments.

[0105] FIG. 22 shows an illustrative example of a process 2200 that may be used to enforce a policy using associated data, according to various embodiments. Process 2200 may be performed by any suitable system, such as a cryptographic service and / or security module. In one embodiment, process 2200 includes receiving 2202 a request to perform an operation. The request may be any request submitted to a service that processes requests. In one embodiment, the request is a request to perform a cryptographic operation submitted to a cryptographic service. In response to receiving 2202 the request, process 2200 may include obtaining 2204 a ciphertext, a MAC, and expected associated data. Obtaining 2204 the ciphertext, the MAC, and expected associated data may be performed in any suitable manner. For example, in some embodiments, one or more of the ciphertext, the MAC, and the expected associated data are received within the request. Two or more of the ciphertext, the MAC, and the expected associated data may be received in separate requests or other communications and / or may be accessed from a data store, such as a local data store. For example, in one embodiment, the ciphertext and MAC are received as part of the request as a concatenated pair (perhaps generated from the output of an AES-GCM or AES-CCM cipher). The expected associated data may also be part of the request or may be identified in other ways. For example, the requester's identity may be used directly or indirectly to determine the associated data. As a specific example, if the request is to perform an operation related to data stored on a storage device, obtaining the associated data 2204 may include obtaining an identifier for the data storage device. The identifier may be identified explicitly (e.g., as part of the request) or implicitly (e.g., because other information can be utilized to determine that the data is stored in the data storage device). The associated data may be, or may be based at least in part on, the identifier for the data storage device. As noted above, the associated data may vary significantly among various embodiments.

[0106] In one embodiment, process 2200 includes generating 2206 a reference MAC that can be used to determine the authenticity of the expected associated data. For example, the reference MAC is generated 2206 using the ciphertext, the associated data, and an appropriate key (which may be identified in the request or determined in another manner). Generating the MAC may be performed in any suitable manner, such as by using the same cipher as used to obtain the ciphertext. A determination may be made 2208 whether the reference MAC and the obtained MAC match. For example, in many cryptosystems, MACs match when they are equal, although it is contemplated that other types of matches may be used in various embodiments. If it is determined 2208 that the reference MAC and the obtained MAC match, in one embodiment, process 2200 includes accessing 2210 policy information based at least in part on the associated data. Accessing 2210 policy information may include accessing one or more policies (i.e., electronic representations of one or more policies) from a remote or local data store based at least in part on one or more policies associated with the KeyID used to generate the reference MAC and / or perform another cryptographic operation.

[0107] A determination may then be made 2212 based at least in part on the accessed policy information as to whether the policy permits the requested operation to be performed (e.g., whether the policy permits the request to be carried out). Determining whether the policy permits the requested operation to be performed may include determining whether ciphertext is tagged with associated data specified by the accessed policy information. Additionally, although not illustrated, policy information not based at least in part on associated data (e.g., a policy based on information other than the associated data) may also be used to determine whether the policy permits the operation to be performed. If the policy is determined to permit the operation 2212, process 2200 may include performing 2214 the operation. However, if the policy is determined to not permit the operation 2212 and / or if it is determined that the reference MAC and the obtained MAC do not match 2208, process 2200 may include denying 2216 the request, as described above.

[0108] Various policies can be enforced using the techniques described above. For example, as noted, a policy can be associated with a key to determine what can and / or cannot be done with the key when the policy is enforced. As one example, a policy may state that a data service can use a key only for certain types of operations specified by the policy (or alternatively, certain operations are prohibited for the data service). A policy may also specify conditions on use, time of use, IP addresses, what can be encrypted, what can be decrypted, etc. As one illustrative example, a policy may specify that providing a decrypted result is only permitted if the hash of the decryption matches a specified value. Thus, a cryptographic service or other service enforcing the policy will not provide the plaintext if its hash does not match the policy. As another example, a policy may specify that decryption of ciphertext is only permitted if the ciphertext is tagged with associated data that is equal to or begins with a specified value. As yet another example, a policy may specify that decryption of ciphertext is only permitted if the ciphertext is tagged with an identifier for the storage device that is encoded within the associated data.

[0109] In general, a policy may specify restrictions and / or privileges based at least in part on the value of data associated with a ciphertext (i.e., authenticated associated data). Some additional policies include policies specifying that decryption is permitted only for ciphertext tagged with an identifier of the computer requesting decryption, for ciphertext tagged with an identifier of a storage volume attached to (operably connected to) the computer requesting decryption, and / or for ciphertext tagged with an identifier of another computing resource. The computing resource may also be a computing resource hosted by a computing resource provider that enforces the policy. Other policies are considered within the scope of this disclosure, such as policies based at least in part on the input and / or output of a cryptographic algorithm before the output of the cryptographic algorithm is revealed to entities other than the entity executing the cryptographic algorithm (e.g., revealed to users and / or other data services other than the cryptographic service enforcing the policy). As noted above, a policy may also specify conditions under which the policy may be modified, which may be based at least in part on associated data.

[0110] FIG. 23 shows an illustrative example of process 2300, which is a variation of process 2200 described above in connection with FIG. 22, where the variation illustrates the use of a security module in policy enforcement, according to various embodiments. In one embodiment, process 2300 includes receiving 2302 a request to decrypt ciphertext, which may be an encrypted key or other encrypted data. Process 2300 also includes obtaining 2304 the ciphertext, a MAC, and expected associated data, as described in connection with FIG. 22. As illustrated in FIG. 23, in one embodiment, process 2300 includes using 2306 a security module to decrypt the ciphertext. Using 2306 may also include selecting a security module from a plurality of security modules operable to decrypt the ciphertext, thereby yielding plaintext. The security module may also be used to generate 2308 a reference MAC based at least in part on the plaintext and the expected associated data. Note that although shown as two separate steps in Figure 23, decrypting the ciphertext using a security module and generating the reference MAC may be performed in a single operation (e.g., a single request to the security module). Once obtained from the security module, process 2300 includes determining 2310 whether the reference MAC and the obtained MAC match, as described above in connection with Figure 22. Note, however, that in some embodiments, process 2300 may be modified so that the security module is provided with the reference MAC and determines whether the reference MAC and the obtained MAC match. In this variation, the security module may provide a response indicating whether there is a match.

[0111] Returning to the embodiment illustrated in Figure 23, if it is determined 2310 that the reference MAC and the obtained MAC match, process 2300 includes accessing 2312 policy information based at least in part on the associated data, as described above in connection with Figure 22. Also, as above, although not illustrated as such, additional policy information relating to policies not based at least in part on the associated data may also be accessed. A determination may be made 2314 whether the policy permits the operation. If it is determined 2314 that the policy permits the operation, cleartext may be provided 2316. As above in connection with Figure 22, if it is determined 2314 that the policy does not permit the operation and / or if it is determined that the reference MAC does not match the obtained MAC, the process may include denying 2318 the request, as described above.

[0112] While various embodiments of the present disclosure are illustrated using associated data of a cryptographic authentication mode, other embodiments are also considered within the scope of the present disclosure. For example, embodiments of the present disclosure generally apply to the use of cryptographically verifiable data to enforce a policy. As an illustrative example, an indication of the policy can be combined with a first plaintext to generate a new plaintext (e.g., the new plaintext includes the plaintext and the policy). The new plaintext can be encrypted using a suitable cipher, such as AES, to produce a ciphertext. When a request to decrypt the ciphertext is received, the system receiving the request can decrypt the ciphertext, extract the policy from the new plaintext, and check whether the policy allows the first plaintext to be provided. If the policy does not allow the first plaintext to be provided, the request can be denied. Such embodiments can be used instead of or in addition to the embodiments described above in connection with associated data of a cryptographic authentication mode.

[0113] Various embodiments of the present disclosure also allow policies on keys to specify conditions on how auditing occurs. For example, a policy on a key may specify an audit level for the key, where the audit level is a parameter of the cryptographic service that governs how the cryptographic service audits the use of the key. Auditing may be performed by any suitable system. For example, with reference to FIG. 16 , the request processing unit may communicate with an audit system (not shown), which may be part of or separate from the cryptographic service. When an event occurs in connection with the performance of a cryptographic operation, relevant information may be provided to a monitoring system that records the information. The event may be a request to perform a cryptographic operation and / or information indicating whether the requested operation was performed. For example, if a user successfully requests a cryptographic service to perform a decryption operation, the cryptographic service may provide information to the audit system to enable the request and that the operation was performed. Administrative access events, and generally, any interaction or operation of a cryptographic service, may be logged along with relevant information that may identify the entity involved in the event, information describing the event, a timestamp of the event, and / or other information.

[0114] In one embodiment, audit levels include a high durability level and a low durability level. At the low durability level, key audit operations may be performed on a best-effort basis by the cryptographic service. Auditing according to the low durability level audits all operations during normal operation, but in the event of a failure of a cryptographic service component, some audit data may be lost. Auditing according to the high durability level provides assurance that an audit record that the operation occurred has been durably committed to memory before revealing the result of the cryptographic operation. Because confirmation is required, operations in the high durability audit mode are slower than operations in the low durability audit mode. Assurance that the audit record has been durably committed to memory may include confirmation from one or more other systems used to store the audit record. Thus, referring to the previous paragraph, the cryptographic service may delay providing the plaintext to the user until confirmation from the audit system that the record of the decryption resulting in the plaintext has been durably committed to memory. Committing durably to memory may mean that the data is stored in accordance with one or more conditions for durability. For example, data may be durably delivered to memory when the data is written to non-volatile memory and / or when the data is stored redundantly across multiple data storage devices (e.g., using erasure coding or other redundancy encoding schemes).

[0115] In some embodiments, the cryptographic service uses sublevels of low-durability and high-durability audit levels. For example, in some embodiments, each level corresponds to two distinct states: an immutable state and a mutable state. Whether a state is immutable or mutable may determine how and whether transitions between states occur. For example, using the illustrative example of audit durability, the policy on a key may be able to change between low-durability mutable and high-durability mutable, from low-durability mutable to low-durability immutable, and from high-durability mutable to high-durability immutable. However, the cryptographic service may be configured such that once a key's policy is placed in either low-durability immutable or high-durability immutable, transitions are prohibited. Thus, once a key's policy is placed in the immutable state, the policy cannot be changed.

[0116] FIG. 24 shows an illustrative example of a state diagram for such a system generalized to policies that can be on (enforced) and off (not enforced). As illustrated in FIG. 24, a policy for a key can be on or off. When on and immutable, the policy can be changed to on and immutable (immutable) or off and mutable (mutable). Similarly, when a policy is off but mutable, the policy can be changed to on but mutable or off but immutable. Note that other transitions are also available, such as a direct transition from an off but mutable policy to on and immutable. Furthermore, not all transitions shown may be available. For example, a key may not have an off and immutable state in some cases.

[0117] FIG. 25 shows a generalized state diagram illustrating how the system may allow transitions between various policies applicable to a key. In this example, three policies are shown: Policy A, Policy B, and Policy C. Each of these policies has mutable and immutable states, and allowable transitions between the states and policies are shown. For example, transitions from the immutable state are not allowed. However, a policy in a mutable state can be changed to another policy in a mutable state. For example, a policy on a key may be changed from Policy A (mutable) to Policy B (mutable). As exemplified by Policy B, there may be transitions available for multiple policies. For example, from Policy B, the policy can be changed to either Policy C or Policy A. As with FIG. 24, other transitions and policies may be included, and not all policies may have all states. Furthermore, while various examples show policies with immutable and mutable states, a policy may have more than two states, where each state corresponds to a set of actions that can or cannot be performed. For example, a semi-mutable state may allow some, but not all, of the transitions available under the mutable state.

[0118] As noted, policies can be used for various operations in addition to auditing. For example, the above constraints on policy transitions can be applied to key frangibility. For example, a policy can indicate whether a key can be frangible (irrevocably lost). The policy can have four states: frangible-mutable, frangible-immutable, unfrangible-mutable, and unfrangible-immutable. As above, when in the immutable state, the policy cannot be changed. As another example, a policy regarding whether a key can be exported from a security module can also have such a four-state policy.

[0119] Policies may also be associated with keys to prevent key usage that allows vulnerability to security attacks. For example, in some embodiments, one or more keys are associated with an automatic rotation policy that retires the key (e.g., marks it as no longer usable for encryption) after a certain number of uses. Such a policy may be a user-configurable (e.g., customer-configurable) policy, with parameters activated and / or provided by a user (e.g., a customer). The policy may also be a global policy applicable to a larger set of keys (such as a set including at least all keys managed by the cryptographic service on behalf of the customer). In this manner, a key may be retired before it has been used long enough to enable a cryptographic attack where knowledge of sufficient plaintext and corresponding ciphertext provides the ability to determine the key.

[0120] FIG. 26 shows an illustrative example of a process 2600 used to rotate keys at appropriate intervals, according to various embodiments. Process 2600 may be performed by any suitable device, such as the security module described above. In one embodiment, process 2600 includes receiving 2602 a request to perform a cryptographic operation using a key identified by a KeyID. The request may be a request received from a cryptographic service request processor, as described above. The request may be a request to encrypt or decrypt data, or generally to perform any cryptographic operation using the key identified by the KeyID, such as generating a digital signature, another key, or other information based at least in part on the key. Upon receiving 2602 the request, process 2600 includes performing 2604 the requested operation. Performing the requested operation may include additional operations, such as selecting an appropriate version of the key to perform the operation. For example, if the operation is encryption, a key marked as active may be used for encryption. If the operation is decryption, performing the operation may include selecting and decrypting the appropriate version of the key identified by the KeyID, which in various embodiments is the key originally used to encrypt the data. The key may be selected in various ways. For example, in some embodiments, the ciphertext may include metadata identifying a version, serial number, date, or other information that enables key selection. In some embodiments, each possible key may be tried until the data is correctly decrypted, and correct decryption may be determined by a hash of the plaintext output associated with the ciphertext or by the authenticity of the associated data.

[0121] Once the cryptographic operation has been performed 2604, process 2600 includes updating 2606 a key usage counter for the active key identified by the KeyID. For example, if the cryptographic operation results in one key usage, the counter may be incremented by 1. Similarly, if the cryptographic operation results in N key usages, where N is a positive integer, the counter may be incremented by N. A determination is made 2608 whether the counter exceeds a threshold. The threshold may be the number of usages assigned to the version of the key identified by the KeyID. The threshold may be provided by a component of the cryptographic service that manages the allocation of operations for the key. The threshold may also be a default number of operations. If it is determined 2608 that the counter exceeds the threshold, in one embodiment, process 2600 includes acquiring 2610 a new key. Acquiring a new key may be performed in any suitable manner. For example, if process 2600 is performed by a security module, acquiring a new key may include generating a new key or acquiring a new key from another security module, which may be orchestrated by an operator of the cryptographic service. Passing a key from one security module to another may be performed by encrypting the key with a key to which the providing and receiving security modules have access. The security module performing process 2600 may obtain and decrypt the encrypted key. Public key key exchange techniques may also be used.

[0122] Once the new key is obtained, in one embodiment, process 2600 may include marking 2612 the currently active key as retired. Marking the currently active key as retired may be performed in any suitable manner, such as by changing an appropriate value in a database maintained by the security module. Further, process 2600 includes associating 2614 the new key with a KeyID and marking the new key as active, such as by updating a database maintained by the security module. Although not illustrated, process 2600 may also include providing the new key for use by another security module. As indicated by the dashed line, at some point after the new key is ready for use by the security module (or other system) executing process 2600, the process may include receiving 2602 a request to perform another cryptographic operation, and process 2600 may proceed as described above. Further, if it is determined 2608 that the counter does not exceed the threshold, process 2600 may terminate and / or repeat 2602 when another request is received.

[0123] FIG. 27 shows an illustrative example of a process 2700 that may be used to perform automated rotation of keys in a cryptographic service or other environment, according to various embodiments. Process 2700 may be performed by any suitable system, such as a component of a cryptographic service that tracks key usage and organizes key rotation according to various embodiments. As illustrated in FIG. 27, process 2700 includes assigning 2702 a number of key operations for a key (e.g., a number of operations for each of a plurality of keys) to one or more security modules. As a specific example, in an environment utilizing five security modules to redundantly store / use a set of keys, each security module may be assigned 1 million operations for each key it manages. The security modules (or other computer systems) to which operations are assigned may be hosted in the same data center among multiple data centers. For example, in some embodiments, a computing resource provider utilizes security modules in multiple data centers in multiple geographic regions to implement a geographically distributed cryptographic or other service.

[0124] Note, however, that the assignment may be for some, but not all, keys, and that the assignment for each key may not be equal. Assigning key operations may include providing notification of the assignment to each security module, including which key operations have been assigned. The notification may specify the number assigned to each key, or in some embodiments, the notification to the security module may indicate to the security module to reinitialize a preprogrammed counter within the security module or to add a preprogrammed number to the counter. Assigning 2702 key operations to a security module may update a key usage counter for each key to which an operation has been assigned. Continuing with the specific example above, if each of five security modules has assigned 1 million operations to a key identified by a particular KeyID, the counter for the KeyID may be incremented by 5 million (up or down, depending on whether the counting is performed upward or downward).

[0125] When key operations are assigned, security modules may perform cryptographic operations as described above. Security modules may maintain their own counters based at least in part on the assignments made. In the example above, if a security module was assigned 1 million operations to a key identified by a particular KeyID, the security module may set a counter to 1 million (or greater than 1 million if the existing counter has remaining operations). When performing cryptographic operations using the key, the security module may increment its own counter accordingly.

[0126] At some point, an allocation depletion event for one or more KeyIDs may be detected 2706. An depletion event may be any event in which one or more security modules lose or become depleted of their allocation. As one example, a security module may use its allocation of operations on keys identified by a particular KeyID, and detecting an depletion event may include receiving notification from the security module that the security module has depleted its allocation for the KeyID by performing a corresponding number of operations (or is within some specified threshold indicating that it has depleted its allocation, or is otherwise predicted to soon deplete its allocation). As another example, in some embodiments, a security module is configured to lose access to keys (and data associated with the keys, such as counters) stored therein upon certain events, such as the detection of a failure, intrusion, or other tampering, or when an operator requires access to the security module for maintenance. Thus, depletion events may include the loss (possibly temporary) of a security module due to a failure or the detection of tampering / intrusion, as well as an internal action (such as temporarily disabling the security module for maintenance). In this example, a security module may be treated as if it has used its allotted number of operations, even though it has not necessarily performed its allotted number of operations. Note, however, that all such events may not include exhaustion events in certain embodiments, such as when counters are persistently stored and therefore recoverable even upon loss of access to the corresponding key. Note also that an exhaustion event may affect more than one security module. For example, a power outage affecting multiple security modules in a data center may result in an exhaustion event affecting multiple security modules.

[0127] Upon detection of an exhaustion event, a determination may be made 2710 whether the counter exceeds a threshold for any of the keys associated with the exhaustion event. The threshold may be a specified number of operations based at least in part on the mathematical properties of the cipher used to perform the cryptographic operations. For example, for a cipher using CBC mode, the number of operations may be, or may be based at least in part on, the size of the key space divided by the product of (1) the length of the ciphertext represented in the block and (2) the square of the number of ciphertexts. For a cipher using CTR mode (such as AES-GCM), the number of operations may be, or may be based at least in part on, the size of the key space divided by (1) the square of the length of the ciphertext in the block and (2) the number of ciphertexts. If it is determined 2710 that the counter exceeds a threshold for any of the keys affected by the exhaustion event, process 2700 may include instructing 2712 one or more security modules (i.e., one or more security modules associated with the exhaustion event) to obtain one or more new keys whose allocation of operations has been exhausted and replace the affected key(s) with the new key(s). For example, if a security module goes temporarily offline (thereby causing an exhaustion event) and, as a result, the counter for a KeyID (but not necessarily all KeyIDs) exceeds a threshold, the security module may be instructed to acquire a new key as described above (e.g., by creating a new key, accessing a pre-generated key from data storage, or obtaining a new key from another security module). Note, however, that a security module different from the security module affected by the exhaustion event may be instructed to acquire a new key, such as when one security module is taken offline and a new security module is brought online. Replacing the affected key (identified by a KeyID) with a new key may include marking the affected key as retired, associating the new key with the KeyID (e.g., in a database), and marking the new key as active.Replacing the affected key with a new key may also include initializing a counter for the new key (maintained by the security module replacing the affected key with the new key), which may be a pre-programmed value or may be a value obtained from the system executing process 2700. Process 2700 may also include marking 2714 the affected key(s) as retired and the new key(s) as active, such as by updating a database accordingly. Note that the system executing process 2700 may not have access to the affected key(s) and / or the new key(s), and thus marking the affected key(s) as retired and the new key(s) as active may include associating the key's identifier with a value indicating retired or new, as appropriate.

[0128] In one embodiment, if, upon marking 2714, it is determined 2710 that none of the affected keys have counters exceeding the threshold, process 2700 may include assigning 2716 additional key operations to the still-active affected key(s) and / or any new key(s) obtained as a result of performing the operations of process 2700. Upon assignment of the additional key operations, the appropriate key usage counter(s) may be updated 2704, as described above.

[0129] As with all processes described herein, variations are considered within the scope of this disclosure. For example, in some embodiments, a security module does not track its use of a key, but another component of a cryptographic or other service updates a counter for the key for each request submitted to any security module to perform one or more operations using the key. In such embodiments, for each key of a plurality of keys, a component of the security module may track requests to perform operations using the key (or track the operations performed, e.g., by confirmation or other indication that the request was successfully fulfilled) and update the counter for the key accordingly. When the counter reaches a threshold, the system maintaining the counter may cause all appropriate security modules to retire the key and replace it with a new key (or perform some other operation that causes the key to be retired, such as causing the security module having the key to retire the key and one or more other security modules to begin using the new key). As another example of a variation within the scope of this disclosure, in some embodiments, when a security module uses its allotment of key operations and causes the counter to exceed a threshold, the security module may be instructed to obtain a new key, as described above. Other security modules may continue to use the key until they use their allotment. When a security module uses its allocation, it can acquire a new key to replace the key in the security module that caused the counter to exceed the threshold. In other words, security modules can be allowed to exhaust their allocation of key operations before needing to acquire a new key.

[0130] FIG. 28 shows an exemplary representation of a database used to keep track of key usage. The database may be maintained by a suitable system, such as a system executing process 2700. In the illustrated database, the columns correspond to KeyID, KeyVersion, Usability, and Counter. KeyID and KeyVersion may be as described above. The value in the Usability column may indicate whether the key is retired or active (or whether the key has another state, if such other states are supported by various embodiments of the present disclosure). As illustrated in FIG. 28, the database has a column for each version of a key identified by KeyID, including all retired and active versions. Note, however, that the database may lack all versions of a key. For example, a key may be permanently deleted from storage for various security reasons. Deletion may be pursuant to customer request or policy enforcement, for example.

[0131] As illustrated in Figure 28, the illustrated database also includes a counter for each active key. In this particular example, the database also includes a counter for inactive keys (e.g., indicating the value of each key that exceeds a threshold, thereby resulting in a new key being acquired). However, counter values ​​for inactive keys may not be maintained in some embodiments. The counter may be updated by a system maintaining the database when a key operation is assigned to a security module. When the value of the counter column exceeds a threshold value, a new column may be added to the database to accommodate a new key to replace the key whose counter exceeded the threshold.

[0132] Security modules may maintain similar databases for their own purposes. For example, a security module may track its own usage of keys, and when a security module's use of a key exhausts the number assigned to the security module, the security module may notify a key rotation management component of a cryptographic service (or another service that uses the security module), which may perform a process such as process 2700 described above to either reallocate additional operations to the security module or, if the number of key operations available for the key has been exhausted, have the security module obtain a new key.

[0133] The database used to track key usage may differ from that illustrated in Figure 28 and described above. Additional information may be included in the database, such as metadata associated with the keys, such as time of creation, time of retirement, information about the user using the key, and / or other information that may be useful in various embodiments. Additionally, while a relational table is provided for purposes of illustration, other methods of storing data may be used to support various embodiments.

[0134] The information used to enforce the policy may be obtained by the cryptographic service in various ways. FIG. 29 shows an illustrative example of an environment 2900 in which various embodiments of the present disclosure may be practiced. Components of environment 2900 may include components such as those described above. For example, as illustrated, environment 2900 includes a user interacting with a data services front-end system (data services front-end) via a user device, but may also be any computer system configured to interact with the data services front-end on behalf of the user. Further, as illustrated, the environment includes a data services back-end storage system and an authentication service, which may be as described above. Additionally, the environment includes a cryptographic service, referred to in FIG. 29 as an internal cryptographic service to distinguish it from another cryptographic service, referred to in the figure as an external cryptographic service. Either or both of the internal and external cryptographic services operate as cryptographic services, as described above. As with all environments described herein, variations are considered within the scope of the present disclosure. For example, while FIG. 29 shows a user communicating with a data services front-end, the user may communicate with the cryptographic service without the data services front-end, as described above.

[0135] Also included in environment 2900 is a message service, which in one embodiment is a computer system (e.g., a computer or network of computers) at least configured to issue messages to one or more subscribers in response to requests from an internal cryptographic service. As discussed in more detail below, some requests may trigger components within environment 2900 to operate to send messages related to the request using the message service. For example, some data may be encrypted and stored under a key with an associated policy that requires a response to a decryption request to be delayed a specified amount of time. When a request to decrypt the data is submitted, enforcement of the policy may result in a delayed response and a notification being sent by the message service. In this manner, a user or a computer system monitoring the messages may have the opportunity during the delay to submit a request to cancel the decryption request or otherwise have the decryption request canceled. The message service may send messages to one or more subscribers using one or more techniques, including, but not limited to, email, short message service (SMS), telephone, pager, facsimile, and / or any suitable technique available for transmitting information from a message service to another entity.

[0136] As illustrated in FIG. 29 , a request submitted to the data service front end may include a key access annotation. For example, as shown, a GET request submitted by a user includes a key access annotation. The key access annotation may include information necessary for policy enforcement by one or more components of environment 2900. The key access annotation may include a digital signature generated using a key, or may be provided separately. The key used to generate the signature may be a key shared between the user and the component of policy-enforcing environment 2900, or in some embodiments utilizing a public key digital signature scheme, the key may be the user's private key, thereby allowing the signature to be verified using the corresponding public key. The component of policy-enforcing environment 2900 may use the digital signature to verify the authenticity of the information in the key access annotation and may use the information in the key access annotation to determine whether the policy allows the request to be fulfilled.

[0137] As illustrated in FIG. 29 , any of several components of environment 2900 may receive the key access annotation and use the key access annotation for enforcement in policies. For example, a data services front end may pass the key access annotation to an internal cryptographic service along with a ciphertext and authorization certificate that may be used as described above. The internal cryptographic service may use the key access annotation to validate policies on keys managed by the internal cryptographic service. In some embodiments, the key access annotation includes information that identifies another service, such as an external cryptographic service. Upon detecting the information that identifies the external cryptographic service, the internal cryptographic service may provide the key access annotation to the external cryptographic service, which may be one of multiple cryptographic services or another service that uses the key access annotation, although such other services are not illustrated in FIG. 29 .

[0138] As described above, keys managed in accordance with various embodiments may be associated with policies that encode constraints and / or privileges on the use of the key. Other information related to policy enforcement may also be associated with such keys in accordance with various embodiments. FIG. 30 shows an illustrative example of a key 3000 (such as a key managed by a cryptographic service, as described above) and example information that may be maintained in association with the key 3000 (e.g., by the cryptographic service). As illustrated, policy information encoding one or more policies for the key 3000 is maintained in association with the key 3000, as described above. In one embodiment, a set of keys is also maintained in association with the key 3000 (e.g., associated with the key 3000 by a database or other data storage system). The association may be maintained in any suitable manner. For example, a relational table or other mechanism may directly associate the key 3000 with a key in the set of keys. As another example, a relational table or other mechanism may associate key 3000 with identifiers of keys in the set associated with key 3000 and / or references to keys in the set associated with key 3000.

[0139] For example, in some embodiments, one or more keys from the Usage Key Set and one or more keys from the Management Key Set are maintained in association with key 3000. In certain embodiments, a cryptographic service is configured such that a key in the Usage Key Set is required for at least some requests to be fulfilled in some embodiments. Specifically, in some embodiments, a request to perform an operation using a key identified by a KeyID requires, possibly among other things, that the Key Access Annotation be electronically (i.e., digitally) signed by a key corresponding to the key in the Usage Key Set (e.g., any key in the Usage Key Set, or a key in the Usage Key Set specified by or otherwise associated with the Key Access Annotation). If such a signature does not exist, the request may be rejected. The key corresponding to a key in the Usage Key Set may be a key in the Usage Set or a reference to it, or may be a private key corresponding to a public key in the Usage Key Set (where public and private keys are used in a public key digital signature scheme).

[0140] In some embodiments, a key in the management key set is used for the purpose of modifying the set of keys associated with key 3000. For example, in some embodiments, a request to modify either the usage key set or the management key set (or both) may require a digital signature using a key corresponding to a key in the management key set in order to be fulfilled. Modifications may include adding a key to the key set, removing a key from the key set, replacing a key in the key set with another key, reassociating a key in the key set with another entity, and / or other modifications. In other words, proof of access to the management key is required to modify the usage key set and / or the management key set. Management keys may also be used in a similar manner for other purposes, such as modifying policies and / or other management actions applicable to key 3000. As illustrated in FIG. 30, key 3000 may also be associated with an operation bit mask. The information bit mask may be information encoding the set of operations for which key 3000 may be used, although such information may be encoded by the policy.

[0141] The use of various key sets associated with keys managed by the security module provides many technical advantages. For example, with reference to Figure 30, if a key in a key set associated with key 3000 is compromised, the key set can be altered to prevent data compromise without requiring a change of key 3000. As another example, a third-party key can be used such that a single entity does not possess both the ciphertext and the key needed to decrypt the ciphertext, thereby requiring collusion between entities to access the plaintext.

[0142] Figure 31 shows an exemplary representation of an example key access annotation 3100, according to an embodiment. In Figure 30, the key access annotation 3100 includes information related to the enforcement of a policy associated with the request in which the key access annotation is included. In this example, the key access annotation includes a timestamp (TimeStamp), an operation descriptor (OperationDescriptor), a key holder identifier (KeyHolderID), a KeyID, and an identifier of a key from the usage key set or management key set, although less or more information may be included.

[0143] In some embodiments, the information in the key access annotation 3100 is used to determine whether the request can be fulfilled. Specifically, in some embodiments, the information in the key access annotation 3100 must satisfy one or more conditions (in addition to the mandatory presence of a digital signature) for the request to be fulfilled. For example, in some embodiments, the timestamp must indicate a time that is within some threshold amount of time when the request is received. As another example, the key access annotation must be within an operation count window, must authorize a specific operation associated with specific data, or must otherwise satisfy one or more conditions enforced by the entity that received the key access annotation.

[0144] The KeyHolderID enables federated key management in accordance with various embodiments of the present disclosure. With reference to FIG. 29 , for example, the KeyHolderID may be information that identifies or otherwise allows identification of the key identified by the KeyID. The KeyHolderID may be, for example, a uniform resource locator (URL), an Internet Protocol (IP) address, or other information that allows use of the KeyHolderID to provide key access annotations to a corresponding entity (e.g., by forwarding a request including the annotations). In some embodiments, the KeyHolderID is encoded within the KeyID such that the recipient of the request can extract the KeyHolderID and, if appropriate, forward the request to an appropriate third party. An internal cryptographic service of environment 2900 may be configured, for example, to detect whether the KeyHolderID of a request specifies a different entity and, upon detection of a KeyHolderID specifying a different entity, forward the request (or other information based at least in part on the request) to a different entity, which may be an external cryptographic service (e.g., a cryptographic service of a different computing resource provider) as described above. Different entities may utilize various embodiments of the present disclosure to determine whether to respond to the request and, if appropriate, provide a response to the request, which may be provided via a cryptographic service. If the key-access annotation lacks a KeyHolderID (or the KeyHolderID specifies an internal cryptographic service), the internal cryptographic service may fulfill the request itself, assuming compliance with policies and other requirements for fulfilling the request.

[0145] 32 shows an illustrative example of a process 3200 that may be used to enforce a policy in connection with a request submitted in connection with a key access annotation as described above. Process 3200 may be performed by any suitable device, such as a device of a cryptographic service involved in request processing (e.g., a device that implements a front-end API for the cryptographic service). The cryptographic service may be an internal or external cryptographic service as described above.

[0146] In one embodiment, process 3200 includes receiving 3202 a key access annotation in association with the request. The key access annotation may be an annotation included with the request or may be received in other ways. For example, a request with a key access annotation may be processed, and as part of the processing, the key access annotation may be provided to a device performing process 3200 (or a variant thereof). Once the key access annotation is received, in one embodiment, process 3200 includes generating 3204 a reference signature using the annotation, as described above. A determination may be made 3206 whether the reference signature matches the signature of the annotation. In an alternative embodiment, process 3200 includes providing the key access annotation to a security module along with information that enables the security module to generate a reference signature and check whether the reference signature matches the signature of the key access annotation. In other words, determining whether the signature of the key access annotation is valid may be performed by obtaining such a determination from the security module.

[0147] If it is determined 3206 that the reference signature matches the signature of the annotation, process 3200 may include accessing 3208 any policy associated with the KeyID specified in the request. Assuming a policy exists for the KeyID, process 3200 includes determining 3210 whether the accessed policy permits fulfillment of the request. If it is determined 3210 that the policy permits fulfillment of the request, process 3200 may include determining 3212 whether the KeyHolderID (as described above) identifies an external entity. Determining 3212 whether the KeyHolderID identifies an external entity may be performed in various manners according to various embodiments. For example, the absence of a KeyHolderID in the key access annotation may indicate a negative determination, while the presence of a KeyHolderID in the key access annotation may indicate a positive determination. As another example, the KeyHolderID may be required to have a value that indicates either an internal entity (e.g., an internal cryptographic service) or an external entity (e.g., an external cryptographic service).

[0148] If it is determined 3212 that the KeyHolderID does not identify an external entity, the process 3200 may include fulfilling the request 3214, as described above. However, if it is determined 3212 that the KeyHolderID does identify an external entity, the process 3200 may include forwarding the request to the identified external entity 3216 and, in response, receiving 3216 information enabling request fulfillment. The information may be, for example, information based at least in part on plaintext obtained by decrypting ciphertext by the external entity and / or cryptographic operations performed by the external entity. Although not illustrated, other information may also be received in addition or alternatively. For example, if the external entity independently determines not to allow fulfillment of the request (e.g., because a policy enforced by the external entity does not allow the request to be fulfilled), information indicating a denial may be provided. Assuming that information enabling request fulfillment is received 3216, the process may include fulfilling the request 3214, as described above. For example, the received information enabling request fulfillment may be provided to the requester.

[0149] Variations in addition to those explicitly described above are also considered within the scope of this disclosure. For example, FIG. 32 illustrates verifying a digital signature and policy for a request and then forwarding the request (or information based at least in part thereon) to an external entity. As with all processes illustrated herein, the order of operations may vary. For example, process 3200 may be modified so that the request is forwarded before any signature and / or policy verification occurs. An external entity may perform signature and / or policy verification in addition to or instead of the system performing process 3200. For example, in some embodiments, the system performing the operations of process 3200 does not perform signature and / or policy verification but delegates such verification to an external entity. In other embodiments, the system performing the operations of process 3200 performs signature and / or policy verification, and the external entity performs additional signature and / or policy verification. The external entity may, for example, have different keys and / or different policies in place that are checked before the request is fulfilled.

[0150] Embodiments of the present disclosure also utilize techniques that provide enhanced data security. For example, despite best efforts, security breaches often occur in connection with various systems. To mitigate the impact of such breaches, various embodiments of the present disclosure enable request processing in a manner that provides time to detect the breach and respond accordingly. For example, in some embodiments, decryption of encrypted data and / or access to decrypted data requires a delay. The delay may be required, for example, by the configuration of the system or by policies enforced by the system, where the policies are configured in accordance with various embodiments described herein. Such a delay may be useful in situations where quick access to encrypted data is not necessary, such as when regulatory or other requirements require certain data to be archived but do not necessarily require the data to be immediately available.

[0151] FIG. 33 shows an illustrative example of a process 3300 for providing such a delay according to various embodiments. Process 3300 may be performed by a cryptographic service, such as an internal or external cryptographic service as described above. In one embodiment, process 3300 includes receiving 3302 a request to decrypt ciphertext using a key identified by a KeyID. The request may be received in any suitable manner. For example, the request may be received from a user or from a data service, as described above. In one embodiment, a policy associated with the KeyID is accessed 3304. Note, however, that policies may be automatically enforced in some embodiments, and as a result, policies may not be accessed in some implementations. For the embodiment illustrated in FIG. 33, process 3300 includes determining 3306 whether policies allow the request to proceed. Determining 3306 whether policies allow the request to proceed may be performed in any suitable manner, as described above.

[0152] If it is determined 3306 that the accessed policy allows the request to be fulfilled, process 3300 may include detecting 3308 a time delay policy from among one or more of the accessed policies. However, as described above, in some embodiments, the time delay may be automatic, such that detection of such a policy may not occur. Process 3300 may include initializing 3310 a timer and executing an alarm process. The timer may be a timer of a defined amount of time, which in some embodiments may be a configurable amount and may be configured, for example, as part of a time delay policy. The timer may also be defined in system configuration settings for the system executing process 3300. The alarm process may include executing a workflow configured to result in the execution of various alarm actions. The alarm actions may include, for example, causing a notification system (as described above) to send one or more messages to one or more individuals or systems. For example, a compliance officer for an organization associated with the encrypted data may be notified. As another example, the alarm action may include causing an audit system to perform an enhanced audit, for example, in which more information is collected in connection with various accesses to the system. In some embodiments, the alarm action may also include alarm signaling, which may include an audible and / or visual indication of the alarm. Other alarm actions are considered within the scope of this disclosure.

[0153] Upon initialization of the timer, process 3300 may include performing 3312 a check to see if the timer has expired, until a determination is made 3312 that the timer has actually expired. In some embodiments, the request may be canceled prior to its fulfillment. Canceling a request may require less stringent requirements than the requirements for decrypting the information. For example, in some embodiments, the request may be trivially canceled by anyone with access to the system. As another example, the alarm action, when selected, may include sending a message including a hyperlink that allows the request to be canceled, in some embodiments, without authentication of the recipient of the message. Other methods that allow a request to be canceled may also be used. Thus, in some embodiments, once the timer has expired (or at some other time, such as before the timer has expired), a determination 3314 may be made whether the request has been canceled. If the request is determined to be canceled 3314, process 3300 may include fulfilling 3316 the request, for example, by decrypting the ciphertext using the key identified by the KeyID and providing the resulting plaintext, or by having the security module decrypt the ciphertext and provide the corresponding plaintext, and then forwarding the plaintext to the requestor or otherwise providing access to the plaintext. However, if the request is determined to not be canceled 3314 and / or if policy is determined to not allow fulfillment of the request 3306, process 3300 may include denying the request, as described above.

[0154] Many other variations are within the scope of this disclosure. For example, in some embodiments, a key is associated with a policy that specifies an expiration date or otherwise indicates some determined validity period that is not indefinite. For example, in some embodiments, a key may be associated with a policy that specifies that the key should be destroyed after a certain time, on a specific date, or when one or more conditions are met. As an example, organizational and / or government rules, laws, policies, or regulations may specify that data should be retained for a certain amount of time. A policy on a key used to encrypt such data (e.g., a key used in a cipher to encrypt the data, or a key used in a ciphertext to encrypt another key under which the data is encrypted) may specify that the key should be destroyed (i.e., irrevocably made inaccessible to anyone) upon the expiration of the required time. A cryptographic service or other system may detect the expiration of the required time and destroy the key accordingly. A cryptographic service may detect the expiration of the required time in a number of ways. For example, in some embodiments, the cryptographic service maintains a database having stored therein information indicating the time for key destruction. A periodic process performed by the cryptographic service may destroy keys that are indicated in the database as destructible.

[0155] The policy effective date may also be used in other ways. For example, the time delay enforced for decrypting data may vary over time. For example, as data encrypted under a key ages, the time delay enforced for decrypting the data may decrease. As another example, a principal may have the privilege to perform cryptographic operations using a key only for a specified period of time, which may be renewable via the cryptographic service's API. In this manner, an individual's ability to perform cryptographic operations associated with a key may automatically expire.

[0156] In some embodiments, a request may be made for another purpose in addition to or as an alternative to a request to decrypt ciphertext. For example, the various techniques described above may be suitable for various types of policy enforcement. For example, policies utilized in connection with various embodiments of the present disclosure may utilize a policy effective time. A policy update may have an effective time that indicates a future point in time at which the policy update will take effect in a system enforcing the policy. An existing policy may require that some or all policy changes be allowable under certain conditions, one of which conditions being that the policy update has an effective time that is a specified time in the future (e.g., 48 hours). A request may be made to modify a policy to allow retrieval of data that may be involved in decrypting the data. The request may, for example, be a request to weaken a condition that needs to be met before the data can be retrieved. The request may specify an effective time for the policy change. A system enforcing a policy in connection with a principal to which the policy applies may approve or deny the request based at least in part on whether the effective time complies with the existing policy. If the system approves the policy change, the system may start a timer (which may be based at least in part on the effective time) and execute an alarm process, as described above. Additionally, policy changes may be cancelable until the request is fulfilled, as described above. In this manner, interested parties may be provided with notice and an opportunity to prevent unauthorized access to data.

[0157] Other variations are also considered within the scope of this disclosure. For example, in some embodiments, a data storage system may have an inherent latency for request processing sufficient to provide time to cancel a request and / or otherwise prevent a potential security breach. For example, an archival data storage system may utilize asynchronous request processing, where data responsive to a request may be available several hours after the request is submitted. Furthermore, data responsive to a request may be available after a different amount of time, which may depend on factors such as the system. In such systems, timers may be unnecessary due to the inherent latency. Embodiments of the present disclosure can be described in light of the following remarks. 1. A computer-implemented method comprising: Under the control of one or more computer systems, which are comprised of executable instructions receiving a request to perform a cryptographic operation from a requestor, the request including information and a digital signature generated at least in part based on the information, the digital signature being verifiable with a first key of a set of one or more keys corresponding to a second key; Detecting whether the request specifies a key owner of a plurality of key owners; The request finds a specific key owner among multiple key owners, and the specific key owner receives at least determining whether the digital signature is valid based at least in part on the information and the first key; determining, based at least in part on the information, whether the information satisfies one or more conditions for fulfilling the request; obtaining, from the identified key holder, response information necessary to fulfill the request as a result of the identified key holder determining that the digital signature is valid and that the information satisfies one or more conditions, the response information being generated at least in part based on one or more cryptographic operations performed using the second key; and providing the requestor with a response to the request using the obtained response information. 2. The computer-implemented method of claim 1, wherein the particular key holder is a computer system hosted by a third party. 3. The computer-implemented method of claim 1 or 2, wherein the set of one or more keys corresponding to the second key includes a plurality of keys, each of which can be used to verify satisfaction of a condition required for fulfillment of the request. 4. Receiving a second request to perform a cryptographic operation, the second request including second information and a second digital signature based at least in part on the second information, the digital signature being verifiable with a third key of a second set of one or more keys corresponding to the fourth key; determining whether the second digital signature is valid based at least in part on the second information and the third key; determining, based at least in part on the second information, whether the information satisfies one or more second conditions for fulfilling the second request; 4. The computer-implemented method of any one of claims 1 to 3, further including: performing one or more cryptographic operations to fulfill the second request using a fourth key as a result of determining that the second digital signature is valid and the second information satisfies one or more second conditions. 5. The computer-implemented method of any one of appendices 1-4, wherein one or more conditions for fulfilling the request are defined by one or more policies corresponding to the second key. 6. The computer-implemented method of any one of clauses 1-5, wherein the second key is inaccessible to one or more computer systems in plaintext form. 7. A computer-implemented method comprising: Under the control of one or more computer systems, which are comprised of executable instructions receiving information and an electronic signature associated with the request, based at least in part on the information; Detecting an owner of a second key from a plurality of key owners, the owner being specified in the information; As a result of detecting the owner of the second key, the owner of the second key determining whether the digital signature is valid based at least in part on the portion of the information and the first key associated with the second key; and performing one or more cryptographic operations using a second key as a result of determining that the signature is valid; and and fulfilling the request using one or more results of the one or more cryptographic methods obtained from the holder of the second key. 8. The computer-implemented method of claim 7, wherein the first key is a member of a set of one or more keys that correspond to the second key, and each key of the set of one or more keys can be used to verify a digital signature that is required to be valid for a corresponding request to be fulfilled. 9. The computer-implemented method of claim 7 or 8, wherein the owner of the second key is a third party. 10. The computer-implemented method of any one of Clauses 7-9, wherein one or more computer systems lack access to the second key in plaintext form. 11. The information includes one or more values; the method further comprising determining whether the one or more values ​​satisfy one or more conditions; 11. The computer-implemented method of any one of Clauses 7-10, wherein fulfilling the request depends on determining that one or more values ​​satisfy one or more conditions. 12. The computer-implemented method of any one of clauses 7-11, wherein the owner of the second key is one or more computer systems. 13. A system comprising: one or more processors; a memory that, when executed by one or more processors, provides a computer system with: storing a set of one or more keys associated with the first key; receiving a request that requires use of the first key for fulfillment; and As a result of the first key being held by a third party, using a second key from the set of one or more keys to determine whether the request should be fulfilled; and and memory containing instructions that, upon determining that the request should be fulfilled, cause one or more cryptographic operations to be performed using a first key. 14. The system of claim 13, wherein the owner of the first key is a third-party system. 15. The system of claim 13 or 14, wherein one or more sets of keys include a subset of the administrative keys, each usable for verifying electronic signatures required for changes to one or more sets of keys. 16. The system of any one of appendices 13 to 15, wherein the system is hosted by an entity, and the entity lacks access to the first key in plaintext form. 17. The system of any one of appendices 13 to 16, wherein the request specifies a first key. 18. The system of any one of appendices 13 to 17, wherein determining whether the request should be fulfilled using a second key from the set of one or more keys includes detecting an electronic signature submitted in association with the request using the second key. 19. One or more computer-readable storage media that, when executed by one or more processors of a computer system, Associating a set of one or more keys with the first key; and A computer-readable storage medium having stored thereon instructions for determining whether to use a second key from the set of one or more keys to enable fulfillment of a request by at least having a holder of a first key use the first key in one or more cryptographic operations. 20. One or more computer-readable storage media according to claim 19, wherein the owner of the first key is a third party. 21. A request is submitted in relation to the requested information, The instructions further cause the computer system to verify that one or more conditions on the requested information are satisfied; 21. One or more computer-readable storage media according to claim 19 or 20, wherein satisfaction of one or more conditions is required to enable fulfillment of the request. 22. One or more sets of keys contain a subset of the administrative keys; 22. One or more computer-readable storage media according to any one of claims 19 to 21, wherein each management key in the subset of management keys can be used to determine whether to fulfill a request to change the set of one or more keys. 23. One or more computer-readable storage media of Clause 22, wherein modifying the one or more sets of keys includes adding a key or removing a key from the one or more sets of keys. 24. One or more computer-readable storage media according to any one of appendices 19 to 23, wherein the request is submitted in association with information identifying the owner of the first key. 25. One or more computer-readable storage media according to any one of appendices 19 to 24, wherein the owner of the first key is a computer system.

[0158] FIG. 34 illustrates aspects of an example environment 3400 for implementing aspects according to various embodiments. As will be appreciated, a web-based environment is used for illustrative purposes, but different environments may also be used to implement various embodiments, if desired. The environment includes an electronic client device 3402, which may include any suitable device operable to send and receive requests, messages, or information over a suitable network 3404 and to transmit information back to a device user. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, set-top boxes, personal digital assistants, e-readers, etc. The network may include any suitable network, including an intranet, the Internet, a cellular network, a local area network, or other such network, or a combination thereof. The components used in such a system may depend at least in part on the type of network and / or environment selected. Protocols and components for communication over such networks are well known and will not be discussed in detail herein. Communication over the network may be enabled by wired or wireless connections, and combinations thereof. In this example, the environment includes a web server 3406 for receiving requests and providing content in response, and therefore the network includes the Internet, although it will be apparent to those skilled in the art that in other networks alternative devices serving similar purposes may be used.

[0159] The exemplary environment includes at least one application server 3408 and a data store 3410. It should be understood that there may be several application servers, layers, or other elements, processes, or components that may be coupled or otherwise configured and that may interact to perform tasks, such as obtaining data from an appropriate data store. As used herein, the term “data store” refers to any device or combination of devices capable of storing, accessing, or retrieving data and may include any combination and number of data servers, databases, data storage devices, and data storage media in any standard, distributed, or clustered environment. The application server may include any suitable hardware and software for integrating with the data store as needed to run aspects of one or more applications for client devices and handles much of the application's data access and business logic. The application server may cooperate with the data store to provide access control services and generate content, such as text, graphics, audio, and / or video, that is sent to users, which may be served to users by a web server in the form of Hypertext Markup Language (“HTML”), Extensible Markup Language (“XML”), or another suitable structured language in this example. All request and response processing, as well as delivery of content between client device 3402 and application server 3408, may be handled by a web server. It should be understood that the structured codes discussed herein may be executed on any suitable device or host machine, as discussed elsewhere herein, and therefore web and application servers are not required and are merely example components.

[0160] The data store 3410 may include several separate data tables, databases, or other data storage mechanisms and media for storing data related to particular aspects. For example, the illustrated data store includes mechanisms for storing production data 3412 and user information 3416, which can be used to serve production content. The data store is also shown to include mechanisms for storing log data 3414, which can be used for reporting, analysis, or such purposes. It should be understood that there may be many other aspects that need to be stored in the data store, such as for page image information and for accessing the correct information, and that this information can be stored in the mechanisms listed above or in additional mechanisms within the data store 3410, as needed. The data store 3410, via its associated logic, is operable to receive instructions from the application server 3408 and, in response, retrieve, update, or otherwise process data. As an example, a user may submit a search request for a particular type of item. In this case, the data store may access the user information to verify the user's identity and access catalog details to retrieve information about that type of item. The information may then be returned to the user, such as in a results listing on a web page that the user can view via a browser on the user device 3402. Information for a particular item of interest may be viewed in a dedicated page or window in the browser.

[0161] Each server typically includes an operating system that provides executable program instructions for the general management and operation of that server, and typically includes a computer-readable storage medium (e.g., a hard disk, random access memory, read-only memory, etc.) that stores instructions that, when executed by the server's processor, allow the server to perform its intended functions. Suitable implementations of operating systems and the general functionality of servers are known or commercially available, and would be readily implemented by one of ordinary skill in the art, especially in light of the disclosure herein. In some embodiments, the operating system may be configured according to or under one or more validation regimes, such as Evaluation Assurance Level (EAL) Level 4.

[0162] In one embodiment, the environment is a distributed computing environment utilizing several computer systems and components interconnected through communication links, using one or more computer networks or direct connections. However, those skilled in the art will appreciate that such a system may operate equally well in systems having fewer or more components than illustrated in Figure 34. As such, the depiction of system 3400 in Figure 34 should be considered exemplary in nature and not limiting on the scope of the present disclosure.

[0163] Various embodiments may also be implemented in a wide variety of operating environments and, in some cases, may include one or more user computers, computing devices, or processing devices that can be used to operate any of numerous applications. User or client devices may include any of numerous general-purpose personal computers, such as desktop or laptop computers running standard operating systems, as well as mobile, wireless, and handheld devices that run mobile software and can support numerous networking and messaging protocols. Such systems may also include numerous workstations running any of numerous commercially available operating systems and other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as dummy terminals, thin clients, gaming systems, and other devices capable of communicating over a network.

[0164] Most embodiments utilize at least one network familiar to those skilled in the art for use and support using any of a variety of commercially available models and protocols, such as Transmission Control Protocol / Internet Protocol ("TCP / IP"), Open System Interconnection ("OSI"), File Transfer Protocol ("FTP"), Universal Plug and Play ("UpnP"), Network File System ("NFS"), Common Internet File System ("CIFS"), and AppleTalk. The network may be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

[0165] In embodiments utilizing web servers, the web servers may operate any of a variety of server or middle-tier applications, including a Hypertext Transfer Protocol ("HTTP") server, an FTP server, a Common Gateway Interface ("CGI") server, a data server, a Java server, and a business application server. The server(s) may also be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more web applications, which may be implemented as one or more scripts or programs written in any programming language, such as Java, C, C#, or C++, or any scripting language, such as Perl, Python, or TCL, and combinations thereof. The server(s) may also include database servers, including, but not limited to, those commercially available from Oracle, Microsoft, Sybase, and IBM.

[0166] The environment may include a variety of data stores and other memory storage media, as described above. These may reside in a variety of locations, such as on storage media local to (and / or residing within) one or more of the computers or remote from any or all of the computers across a network. In a particular set of embodiments, information may reside within a storage area network ("SAN"), familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally and / or remotely, as needed. Where the system includes computerized devices, each such device may include hardware elements that may be electronically coupled via a bus, including, for example, at least one central processing unit ("CPU"), at least one input device (e.g., a mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, solid-state storage devices such as random access memory (“RAM”) or read-only memory (“ROM”), as well as removable media devices, memory cards, flash cards, etc. Various embodiments of the present disclosure may also be implemented using custom hardware, including, but not limited to, custom cryptographic processors, smart cards, and / or hardware security modules.

[0167] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network cards (wireless or wired), infrared communication devices, etc.), and working memory as described above. The computer-readable storage medium readers may be connected to or configured to receive computer-readable storage media, which refer to remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. The systems and various devices also typically include numerous software applications, modules, services, or other elements, including operating systems and application programs such as client applications or web browsers, that are located within at least one working memory device. It should be understood that alternative embodiments may have numerous variations from those described above. For example, customized hardware may be used, and / or particular elements may be implemented in hardware, software (including portable software such as applets), or both. Additionally, connections to other computing devices, such as network input / output devices, may be used.

[0168] Storage media and computer-readable media for containing the code or portions of the code may include any suitable media known or used in the art, including storage media and communication media such as volatile and non-volatile, removable and non-removable media implemented in any method and technology for storing and / or transmitting information, such as computer-readable instructions, data structures, program modules, or other data, including, but not limited to, RAM, ROM, Electronically Erasable Programmable Read-Only Memory ("EEPROM"), flash memory, or other memory technology, Compact Disc Read-Only Memory ("CD-ROM"), Digital Versatile Disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the system devices. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other means and / or methods for implementing the various embodiments.

[0169] The specification and drawings are accordingly to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

[0170] Other variations are within the spirit of the present disclosure. Accordingly, while the disclosed technology is susceptible to various modifications and alternative constructions, specific illustrated embodiments thereof are shown in the drawings and have been described in detail above. It is to be understood, however, that there is no intention to limit the invention to the particular form(s) disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents included within the spirit and scope of the invention as defined by the appended claims.

[0171] The use of the terms "a," "an," and "the" and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) are to be construed as covering both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to") unless otherwise indicated. The term "connected" is to be construed as partially or wholly contained within, attached to, or joined together, even if there are intervening components. The recitation of ranges of values ​​herein is intended to serve merely as a shorthand method of individually referring to each separate value falling within that range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. Any and all examples provided herein, or the use of exemplary language (e.g., "etc.") are intended merely to better illuminate embodiments of the invention and do not impose limitations on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0172] Preferred embodiments of the present disclosure are described, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors anticipate that skilled artisans will employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Furthermore, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

[0173] All references, including publications, patent applications, and patents, cited in this specification are herein incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. one or more processors; When executed by one or more of said processors, the system is provided with: In response to the first request, associating a key with a policy associated with the system, the policy specifying an audit level for use of the key, and an external cryptographic service storing one or more keys including the key; receiving a second request from an external computer system for authorization to access the key to perform a cryptographic operation; The external cryptographic service, determining that the system has authorized access to the key based at least in part on the policy associated with at least one key identifier; granting the external computer system the authorized access to the key based at least in part on the determination; and and a memory containing instructions for performing the A system comprising:

2. the key is a master key that can be used to decrypt encrypted keys; The system of claim 1 , wherein the encrypted key is associated with the external computer system that sent the second request.

3. The system of claim 1 , wherein the second request includes a KeyId indicating the key.

4. The system of claim 1 , wherein the cryptographic operation includes creating a digital signature using the key.

5. The system of claim 1 , wherein the external cryptographic service includes a hardware security module (HSM) for storing the key.

6. The system of claim 1 , wherein the encryption operation is performed using the Advanced Encryption Standard (AES).

7. 1. A computer-implemented method comprising: receiving a first request from an external computer system to associate a key with a policy, the policy specifying an audit level for use of the key, and an external cryptographic service storing one or more keys including the key; receiving a second request from the external computer system to access the key to perform a cryptographic operation; causing the external cryptographic service to grant the external computer system authorized access to the key based at least in part on a determination that the external computer system has permission to access the key according to the policy, the policy being associated with at least one key identifier; A computer-implemented method comprising:

8. the key is a first key, the encryption operation includes decrypting a second key using the first key; The computer-implemented method of claim 7 , wherein the second key is associated with the external computer system.

9. 8. The computer-implemented method of claim 7, wherein the external cryptographic service includes one or more hardware security modules (HSMs) for storing multiple keys, including the key.

10. 8. The computer-implemented method of claim 7, wherein the encryption operation is performed using the Advanced Encryption Standard (AES).

11. the key is a first key, the cryptographic operation includes generating a second key based at least in part on the first key; 8. The computer-implemented method of claim 7, wherein the second key is usable by the external computer system.

12. 8. The computer-implemented method of claim 7, further comprising causing the external cryptographic service to obtain a new key based at least in part on the exhaustion of a number of key operations available for the key.

13. The computer-implemented method of claim 7 , wherein the second request includes a key identifier that indicates the key.

14. When executed by one or more processors of a computer system, the computer system: creating a policy corresponding to a key stored in an external cryptographic service, the policy specifying an audit level for use of the key; to the external cryptographic service in response to a request from an external computer system to perform one or more cryptographic operations using the key; determining that the computer system has authorized access to the key based at least in part on the policy, the policy being associated with at least one key identifier; granting the external computer system the authorized access to the key based at least in part on the determination; and and A non-transitory computer-readable medium having stored thereon executable instructions for causing a

15. 15. The non-transitory computer-readable medium of claim 14, wherein the one or more cryptographic operations include creating a digital signature using the key.

16. 15. The non-transitory computer-readable medium of claim 14, wherein the one or more cryptographic operations are performed using the Advanced Encryption Standard (AES).

17. The non-transitory computer-readable medium of claim 14 , wherein the request includes a key identifier that indicates the key.

18. one or more of the cryptographic operations includes generating an additional key based at least in part on the key; 15. The non-transitory computer-readable medium of claim 14, wherein the additional key is made available by the external computer system that sent the request.

19. 15. The non-transitory computer-readable medium of claim 14, wherein the external cryptographic service includes a hardware security module (HSM) for storing the key.

20. 15. The non-transitory computer-readable medium of claim 14, wherein the key is a master key usable to decrypt an encrypted key associated with the external computer system that sent the request.

Images