Data security service

0001Cross-reference of related applications This application claims the priority of US Patent Application No. 13 / 764,963 filed February 12, 2013, the contents of which are incorporated herein by reference in their entirety. This application is co-pending U.S. Pat. No. 13 / 764,944 filed at the same time as this application, title "AUTOMATIC KEY ROTATION", co-pending U.S. Patent No. 13 / 764,995 filed at the same time as this application, title. "POLICY ENFORCEMENT WITH ASSOCIATED DATA", co-pending US patent No. 13 / 765,020 filed at the same time as this application, title "DATA SECURITY WITH A SECURITY MODULE", co-pending US patent filed at the same time as this application No. 13 / 765,209, title "FEDERATED KEY MANAGEMENT", US Pat. No. 13 / 765,239 pending at the same time as this application, title "DELAYED DATA ACCESS", pending at the same time as this application. U.S. Pat. No. 13,765,265, entitled "DATA SECURITY" SERVICE, and the full disclosure of the simultaneously pending US Pat. No. 13,765,283, entitled "SECURE MANAGEMENT OF INFORMATION USING A SECURITY MODULE," filed at the same time as this application, is incorporated for all purposes by reference.

0002Security of computing resources and related data is important in many contexts. For example, organizations often utilize networks of computing devices to provide users with a solid set of services. Networks often span multiple geographic boundaries and often connect with other networks. For example, an organization may use both the internal network of computing resources and the computing resources managed by others to support its operation. For example, a computer in that organization may communicate with a computer in another organization to access and / or provide data while using the services of another organization. In many examples, an organization uses hardware managed by another organization to configure and operate a remote network, thereby reducing equipment costs and achieving other benefits. Guaranteeing access to resources and the data they hold with such configurations of computing resources can become difficult, especially as the size and complexity of such configurations increase.

0003Various embodiments according to the present disclosure may be described with reference to the drawings.<figref num="1">Illustrative diagrams are shown showing different aspects of the disclosure according to different embodiments.</figref><figref num="2">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented are shown.</figref><figref num="3">An exemplary embodiment of an environment in which the various aspects of the present disclosure may be implemented, and an example of the flow of information between various components of the environment, according to at least one embodiment.</figref><figref num="4">An embodiment of the steps of an exemplary process for storing a ciphertext according to at least one embodiment is shown.</figref><figref num="5">An exemplary embodiment of an environment in which the various aspects of the present disclosure may be implemented, and an example of the flow of information between various components of the environment, according to at least one embodiment.</figref><figref num="6">An embodiment of an exemplary process step for responding to a request to read data according to at least one embodiment is shown.</figref><figref num="7">An exemplary embodiment of an environment in which the various aspects of the present disclosure may be implemented, and an example of the flow of information between various components of the environment, according to at least one embodiment.</figref><figref num="8">An embodiment of an exemplary process step for responding to a request for storing data, according to at least one embodiment, is shown.</figref><figref num="9">An exemplary embodiment of an environment in which the various aspects of the present disclosure may be implemented, and an example of the flow of information between various components of the environment, according to at least one embodiment.</figref><figref num="10">An embodiment of an exemplary process step for responding to a request to read data according to at least one embodiment is shown.</figref><figref num="11">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented are shown.</figref><figref num="12">An exemplary embodiment of an environment in which the various aspects of the present disclosure may be implemented, and an example of the flow of information between various components of the environment, according to at least one embodiment.</figref><figref num="13">An embodiment of an exemplary process step for responding to a request to read data according to at least one embodiment is shown.</figref><figref num="14">An embodiment of an exemplary process step for responding to a request for decoding data according to at least one embodiment is shown.</figref><figref num="15">An example of steps in an exemplary process for obtaining decrypted data according to at least one embodiment is shown.</figref><figref num="16">A graphical representation of an embodiment of a cryptographic service according to at least one embodiment is shown.</figref><figref num="17">An example of steps in an exemplary process for configuring a policy according to at least one embodiment is shown.</figref><figref num="18">An example of steps in an exemplary process for performing cryptographic operations while enforcing a policy, according to at least one embodiment, is shown.</figref><figref num="19">Illustrative examples of environments in which various embodiments can be implemented are shown.</figref>

0004In the following description, various embodiments will be described. For purposes of illustration, specific configurations and details are given to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that embodiments can be practiced without their specific details. In addition, known features may be omitted or simplified in order not to obscure the embodiments described.

0005The techniques described and proposed herein enable enhanced data security in environments that include distributed computing resources. In one embodiment, a distributed computing environment includes one or more data services that can be implemented by appropriate computing resources. Data services can allow various actions to be performed in connection with data. As one exemplary embodiment, a distributed computing environment includes one or more data storage services. The electronic request is transmitted to the data storage service and can perform the data storage operation. An example of the operation is to use the data storage service to store the data and to use the data storage service to read the data stored by the data storage service. Data services, including data storage services, can also perform operations that manipulate data. For example, in some embodiments, the data storage service can encrypt the data.

0006Various embodiments of the present disclosure include distributed computing environments, including cryptographic services implemented using appropriate computing resources. Cryptographic services can be implemented by distributed systems that receive and respond to electronic requests to perform cryptographic operations, such as plaintext encryption and ciphertext decryption. In some embodiments, the cryptographic service manages the key. In response to a request to perform a cryptographic operation, the cryptographic service may perform a cryptographic operation using a managed key. For example, a cryptographic service may respond to a received request, select the appropriate key to perform the cryptographic operation, perform the cryptographic operation, and provide one or more results of the cryptographic operation. it can. In an alternative configuration, the cryptographic service generates an envelope key (for example, the session key used to encrypt a specific data item), returns the envelope key to the system, and triggers the cryptographic action of the service. Can be done. The system can then use the envelope key to perform cryptographic operations.

0007In some embodiments, the cryptographic service manages keys for multiple tenants of a computing resource service provider. A tenant of a computing resource can be an entity (eg, an organization or an individual) that acts as a customer of a computing resource provider. Customers may remotely and programmatically operate resources that are physically hosted by a 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 the cryptographic service), the cryptographic service selects a key managed by the cryptographic service for the customer. Then, the cryptographic operation is executed. Keys managed by cryptographic services can be securely managed so that other users and / or data services do not have access to the keys. Lack of access to the keys of another entity by one entity (eg, user, customer, service) means that that entity has no authorized way to obtain the keys of others, and / or that entity It can mean that there is no authorized way to make a system manage the keys of others who use the keys in the direction of that entity. For example, in a cryptographic service, both the customer and other customers do not have access to the customer's key (s), and the cryptographic service uses the customer's key (s) to perform cryptographic operations. You can manage the keys so that they cannot be executed. As another embodiment, a cryptographic service may manage keys so that other services, such as data storage services, cannot perform cryptographic operations using some or all of the keys. .. Unauthorized access to a key can be prevented by appropriate security measures, for example, making unauthorized access difficult or impossible. Difficulties are impractical to use the computer and / or are not permitted due to access (eg, illegal, illegal, and / or compromise of the permit certificate, etc.) ) May be due to the need to occur. Systems according to various embodiments may be configured to guarantee an objective measure of computer impracticality for gaining access to keys. Such measures are measured, for example, with respect to the amount of time, and on average, a defined unit of computer capability (eg, time) to crack the encrypted information required for authorized access to the key. Can take a computer with a specific behavior per unit of.

0008As mentioned, cryptographic services may receive requests from various entities such as customers of computing resource providers. Cryptographic services can also receive requests from entities inside the computing resource provider. For example, in some embodiments, a data service implemented by a computing resource provider may transmit a request to a cryptographic service in order to force the cryptographic service to perform a cryptographic operation. In one embodiment, the customer may transmit a request to a data storage service to store the data object. The request may indicate that the data object must be encrypted when it is stored. The data storage service may communicate the request to the cryptographic service in order to perform the cryptographic operation. The cryptographic operation can be, for example, encrypting the key used by the data storage service to encrypt the data object. The cryptographic operation can be the encryption of the data object itself. A cryptographic operation can be to generate an envelope key that can be used by a data storage service to encrypt a data object.

0009Systems that follow different embodiments implement different security measures to provide enhanced data security. For example, in various embodiments, the modes in which the keys managed by the cryptographic service can be used are limited. For example, in some embodiments, the cryptographic service is only configured to use the key corresponding to the customer at the appropriate authorization. If the request to use the customer's key comes from the customer (ie, from a computing device acting on behalf of the customer), the cryptographic service provides proper proof that the request is owned by the customer. The book may be configured to require that it be signed electronically (digitally). If the request to use the customer's key comes from another data service, the cryptographic service provides proof that the data service was made by the customer for the signed request to the data service. It can be configured to require that you do. In some embodiments, for example, a data service is configured to obtain and provide a token that serves as proof of an authenticated customer request. Other security measures may also be incorporated into the configuration of the electronic environment, including cryptographic services. For example, in some embodiments, the cryptographic service is configured to limit the use of keys depending on the context. As one exemplary embodiment, the cryptographic service may be configured to use a key for encrypting a request from or from a data service acting on behalf of the customer. However, cryptographic services can be configured to use the key only to decrypt a request from a customer (rather than from another data service). In this way, if the data service is compromised, the data service may not be able to force the cryptographic service to decrypt the data.

0010Various security measures can be incorporated into cryptographic services and / or their electronic environment. Some security measures may be managed according to policy, which is configurable in some embodiments. As an embodiment, the cryptographic service may utilize an application programming interface (API) that allows the user to configure policies regarding keys. A key policy can be information that determines whether a key can be used in a particular situation when processed by a cryptographic service. A policy can, for example, direct the use of a key, limit the number of times a key can be used, limit the data that a key can be used to perform cryptographic operations, and provide other limits. It may limit the identification of users and / or systems. The policy may provide explicit limitations (eg, who cannot use the key) and / or explicit permissions (eg, who can use the key). In addition, policies can be structured in a complex way to generally provide conditions for when a key can be used and when it cannot be used. When a request to perform a cryptographic operation using a key is received, any policy on the key may be accessed and processed to determine if the request can be fulfilled in accordance with the policy.

0011FIG. 1 is an exemplary Figure 100 demonstrating the various embodiments of the present disclosure. In one embodiment, the cryptographic service performs a cryptographic operation that may include the application of one or more computations according to one or more cryptographic algorithms. As illustrated in Figure 1, cryptographic services allow users or services to generate plaintext from ciphertext. In a configuration embodiment, cryptographic services can be used to encrypt / decrypt keys, and these keys are used to encrypt / decrypt data, such as data stored within a data storage service. Can be done. For example, a cryptographic service receives a request to generate plaintext from a ciphertext encrypted under a key. The cryptographic service determines that the requester is an authorized entity, uses the master key to decrypt the key, and returns the decrypted key to the service, which encrypts using the decrypted key. Plaintext can be generated from sentences. In another configuration, the cryptographic service receives the ciphertext and processes the received ciphertext into plaintext provided as a service by the cryptographic service. In this embodiment, the ciphertext is from an authorized entity to the cryptographic service, which can be a customer of the compute resource provider running the cryptographic service and / or another service of the compute resource provider. It can be provided to cryptographic services as part of an electronic request. The cryptographic service illustrated in Figure 1 can encrypt data using one or more cryptographically strong algorithms. Such cryptographically strong algorithms may include, for example, Advanced Encryption Standard (AES), Blowfish, Data Encryption Standard (DES), Triple DES, Serpent, or Twofish, and depend on the specific implementation chosen. It can be either an asymmetric or symmetric key system. In general, cryptographic services may utilize any cryptographic and / or decryption algorithm (cryptographic), or a combination of algorithms that utilize the data managed by the cryptographic service.

0012Cryptographic services can be implemented in a variety of ways, as described in more detail below. In one embodiment, the cryptographic service is implemented by a computer system configured according to the following description. A computer system can itself include one or more computer systems. For example, cryptographic services can be implemented as a network of computer systems that are collectively configured to perform cryptographic operations according to various embodiments. Or, in other words, the computer system can be a distributed system. In one embodiment, the ciphertext is information encrypted using a cryptographic algorithm. In the embodiment of FIG. 1, the ciphertext is plaintext in encrypted form. Plaintext can be arbitrary information and its name contains word-free text, while plaintext and ciphertext can be information coded in any suitable format, not necessarily textual information, but characters. It may contain information. For example, as illustrated in FIG. 1, the plan and ciphertexts include an array of bits. Plaintext and ciphertext can also be represented in other ways as well as in any form in which encryption and decryption can be performed by a computer system.

0013FIG. 2 shows an exemplary example of an environment 200 in which a cryptographic service as illustrated in FIG. 1 can be implemented. In Environment 200, various components work together to provide secure data-related services. In this specific embodiment, 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 receives plaintext from the data service front end and provides the ciphertext in exchange so that the service can perform cryptographic operations using the envelope key. , Or by providing an envelope key to a service, etc., it is configured to perform cryptographic operations. Cryptographic services perform additional functions such as secure storage of keys for performing cryptographic operations, conversion of plaintext to ciphertext, and decryption of ciphertext into plaintext, as described below. obtain. Cryptographic services can also perform actions involved in policy enforcement, for example by enforcing a policy associated with a key stored therein. Examples of policies that can be enforced by cryptographic services are provided below. A data service front end in one embodiment is a system configured to receive and respond to requests transmitted over a network from various users. The request can be a request to perform an operation related to the data stored or to be stored in the data service backend storage system. In Environment 200, the authentication service, cryptographic service, data service front end, and data service back end storage system are computing resources that utilize the system to serve the customer represented by the user illustrated in Figure 2. It can be the provider's system. The network illustrated in FIG. 2 can be any suitable network or combination of networks, including those described below.

0014The authentication service in one embodiment is a computer system configured to perform an operation involved in authenticating a user. For example, the data service front end may provide information from the user to the authentication service and in exchange receive information indicating whether the user request is authentic. The determination of authenticity of a user request can be performed in any suitable manner, and the style in which authentication is performed can vary between different embodiments. For example, in some embodiments, the user digitally signs a message transmitted to the data service front end. The digital signature can be generated using secret information (eg, the private key of a pair of keys associated with the user) that is available to both the authenticating entity (eg, the user) and the authentication service. The request and the signature for the request can be provided to the authentication service, which uses confidential information to calculate the reference signature for comparison with the received signature and is the request authentic. You can judge whether or not. If the request is authentic, the authentication service may provide information that the request is authentic, which the data service front end can use to prove to other services such as cryptographic services, thereby. Allows other services to operate accordingly. For example, an authentication service may provide a token that another service can analyze to verify the authenticity of the request. Digital signatures and / or tokens can have limited validity in various ways. For example, digital signatures and / or tokens can be valid for a certain amount of time. In one embodiment, the digital signature and / or token is generated at least in part based on a time stamped function (eg, a hash-based message authentication code) that is included with the digital signature and / or token for verification. Will be done. The entity that validates the submitted digital signature and / or token checks that the time stamp received is sufficiently up-to-date (eg, within a given amount of time from the current time) and receives it. Can generate the reference signature / token used for the time stamp given. Authentication fails if the timestamp used to generate the submitted digital signature / token is not up-to-date and / or the submitted signature / token does not match the reference signature / token. obtain. In this way, if a digital signature is compromised, it can only be effective for a short amount of time, thereby limiting the potential damage caused by the risk. It should be noted that other methods of verifying authenticity are also considered to be within the scope of this disclosure.

0015The data service backend storage system in one embodiment is a computer system that stores data according to a request received through the data service frontend. As described in more detail below, the data service backend storage system may store data in encrypted form. Data in the data service backend storage system can also be stored in unencrypted form. In some embodiments, the API implemented by the data service front end allows the request to specify whether the data to be stored within the data service backend storage system should be encrypted. To do. The data that is encrypted and stored in the data service backend storage system can be encrypted in different ways according to different embodiments. For example, in various embodiments, the data is encrypted using a key that is accessible to cryptographic services but not to some or all of the other systems in Environment 200. The data can be coded by a cryptographic service for storage within the data service backend storage system, and / or, in some embodiments, the data is a user using a key decrypted by the cryptographic service. It can be encrypted by another system, such as a system or a data service front-end system. Examples of various methods by which the environment 200 can operate to encrypt data are provided below.

0016Numerous variants of Environment 200 (and other environments described herein) are considered to be within the scope of this disclosure. For example, Environment 200 may include additional services that may communicate with cryptographic and / or authentication services. For example, the environment 200 may include additional data storage services, each of which may have a front-end system and a back-end system, which may store data in different ways. For example, a data storage service may provide active access to data for which the data storage service performs the data storage service in a synchronous fashion (eg, a request to read the data responds synchronously with the read data. Can be received). Another data storage service may provide a data storage service for storage. Such a storage data storage service may utilize asynchronous request processing. For example, a request to read data may not receive a synchronization response containing the read data. Rather, the storage data storage service requires that a second request be submitted to obtain the read data when the storage data storage service is ready to provide the read data. obtain. As another embodiment, Environment 200 may include a weighing service that receives information from cryptographic services (and / or other services) and uses that information to generate account records. Account records may be used to charge customers for their use of cryptographic services (and / or other services). In addition, information from cryptographic services may provide instructions on how fees should be charged. For example, in some examples, the customer may be invoiced for the use of cryptographic services. In another example, charges for the use of cryptographic services may be matched to charges for the use of other services, such as data services that utilize cryptographic services as part of their operation. Use can be weighed and charged in a variety of ways, including per operation, per hour, and / or other methods. Other data services are also Environment 200 (or others described herein).

0017In addition, Figure 2 depicts a user interacting with a data service front end. It should be understood that the user can interact with the data service front end through a user device (eg, a computer) not illustrated in the drawing. In addition, the user depicted in Figure 2 (and elsewhere in the drawing) may also represent non-human entities. For example, an automated process running on a computer system may interact with the data service front end described herein. As an exemplary embodiment, the entity represented by the user in Figure 2 uses the data service front end to store data in and / or there in the data service backend storage system as part of its behavior. It can be a server that reads data from. As yet another embodiment, the entity represented by the user in FIG. 2 can be an entity provided as a service of a computing resource provider running one or more of the services in FIG. For example, the user in Figure 2 may represent a virtual or other computer system of program execution services provided by a computing resource provider. Other modifications, including other environmental variants described below, are also considered to be within the scope of this disclosure.

0018For example, FIG. 3 shows exemplary embodiments of 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. Authentication services, data service frontends, cryptographic services, and data service backend storage systems can be configured as described above in connection with FIG. For example, a user may access a data service front end via a suitable communication network, which network is not illustrated in the drawings. In Example 300 of the environment illustrated in FIG. 3, arrows representing the flow of information are provided. In this embodiment, the user transmits a PUT request to the data service front end. A PUT request can be a request to store specific data within a data service backend storage system. In response to a PUT request, the data service front end can determine if the PUT request is authentic, in a way that the user can perform the requested action according to the authentication policy enforced by the system. So, did you submit the request?

0019FIG. 3 illustrates an exemplary example of how such an authentication decision can be made. In this specific embodiment, the data service front end submits an authentication request to the authentication service. The authentication service can use the authentication request to determine if the PUT request from the user is authentic. If the request is authentic, the authentication service may provide proof of authentication to the data service front end. The proof of authentication can be an electronic token or other information that can be used by another service, such as a cryptographic service, to independently determine that a genuine request has been received. In one exemplary embodiment, the PUT request is transmitted with a signature for the PUT request. The PUT request and its signature are provided through an authentication service, which independently calculates what the signature should be if it is genuine. 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 respond and provide proof of authentication. Determining whether a PUT request is authentic can also include one or more actions related to policy enforcement. For example, if the signature is valid but the policy is different and indicates that the PUT request should not be completed (for example, the request was submitted at a time not permitted by the policy), the authentication service indicates that the request is not authentic. Can provide information to indicate. (However, it should be noted that the implementation of such a policy can be carried out by other components of the environment 300.) The authentication service, such as by using the authentication service and a key shared by the user. Can generate signatures. As stated, the proof of authentication can be information that another service, such as a cryptographic service, can then independently verify that the request is authentic. For example, using the cryptographic service embodiment illustrated in Figure 3, the certificate of authentication is at least a key shared by both the cryptographic service and the cryptographic service, such as a key that is inaccessible to other services. Partially based

0020As illustrated in Figure 3, the data service front end provides the cryptographic service with plaintext and the certificate upon receipt of the certificate from the authentication service. Plaintext and proof of authentication may be provided in response to API calls to crypto services or other electronic requests (eg, crypto API calls). Cryptographic services can analyze the certificate to determine whether to encrypt the plaintext.

0021It should be noted that additional information may be provided to the cryptographic service. For example, the key identifier used to encrypt the plaintext can be provided as an input parameter to an API call from the data service front end (which, in turn, may have received the identifier from the user). However, it should be noted that the identifier may not be transmitted to the cryptographic service. For example, in various embodiments, which key to use to encrypt the plaintext can be determined differently. For example, the information transmitted from the data service front end to the cryptographic service is the information associated with the user, such as the identifier of the customer who submitted the PUT request for it, and / or the identifier of the organization associated with the user. May include. Such information can be used by cryptographic services to determine the default key used. In other words, the key can be implicitly identified by information that is useful in determining the key. In general, the determination of the key to be used can be performed in any suitable manner. Further, in some embodiments, the cryptographic service may generate or select a key to provide an identifier for the generated or selected key that will be used later. Another embodiment of the API parameter can be a master key identifier for the customer account for which cryptographic operations are being performed.

0022As illustrated in Figure 3, a cryptographic service may perform one or more cryptographic operations if the certificate of authentication is sufficient for the cryptographic service to encrypt the plaintext. In one embodiment, one or more cryptographic actions may include an action for generating an envelope key used to encrypt plaintext. The envelope key can be a randomly generated symmetric key or a private key of a pair of keys. After the envelope key is generated, the cryptographic service can encrypt the envelope key with the master key identified in the API call, and the encrypted key is permanently stored (eg, the encrypted key). (By storing in a storage service or some other durable storage device) or can cause it to be discarded. In addition, the cryptographic service may send a plaintext version of the envelope key to the data service front end as well as the encrypted envelope key. The data service can then use the plaintext version of the envelope key to encrypt the plaintext (ie, the data associated with the encryption request), where the envelope key is the identifier of the master key used to encrypt the envelope key. In connection with, it can cause storage in a permanent storage device. In addition, the data service may discard the plaintext version of the envelope key. Thus, in one embodiment, after the data service discards the plaintext version of the envelope key, it can no longer decrypt the ciphertext.

0023In an alternative embodiment, cryptographic operations may include encrypting plaintext. For example, a cryptographic service encrypts plaintext and provides the ciphertext to a data service front-end storage system. The data service front end may then provide the ciphertext to the data service back end storage system for persistent storage that follows its behavior. Other information may also be transmitted from the data service front end to the data service back end storage system. For example, a key identifier used to encrypt plaintext to generate a ciphertext may be provided with a ciphertext for storage by a data service backend storage system. Other information, such as metadata that identifies the user and / or the user's organization, may also be provided.

0024As with all environments described herein, numerous modifications are considered to be within the scope of this disclosure. For example, the flow of information between the various components of the environment 300 can vary from what is shown. For example, information flowing from one component to another through an intermediate component (eg, data from an authentication service to a cryptographic service and / or data from a cryptographic service to a data service backend storage system) is destined for its destination. It may be provided directly and / or through other intermediate components of the environment 300 (not necessarily included in the drawing). As another embodiment, the PUT request (and the GET request below) is provided for exemplary purposes. However, any suitable requirement for performing the described operation may be used.

0025FIG. 4 shows an exemplary embodiment of process 400 that can be used to store data within a data storage service according to one embodiment. Process 400 can be executed, for example, by the data service front end illustrated in FIG. Some or all of Process 400 (or any other process described herein, or variants and / or combinations thereof) may be performed under one or more computer systems consisting of executable instructions. Obtained and implemented as code (eg, executable instructions, one or more computer programs, or one or more applications) that is collectively executed on one or more processors, either by hardware or in combination thereof. Can be done. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program containing multiple instructions that can be executed by one or more processors. The computer-readable storage medium can be non-transient.

0026As illustrated in FIG. 4, process 400 includes receiving a PUT request 402. The PUT request can be received electronically over the network and may include information associated with the request, such as the information required for authentication, such as the electronic signature of the PUT request. In response to receiving the PUT request, process 400 may include submitting an authentication request 404. For example, a system running in process 400 may submit an authentication request to a separate authentication service (eg, via a well-configured API call), as described above in connection with Figure 3. Similarly, a data service front end that performs its own authentication may submit an authentication request to an authentication module implemented by the data service front end. In general, certification requests can be submitted in any suitable format according to various embodiments.

0027When submitting an authentication request, the authentication response is received 406 by the entity to which the authentication request was submitted. For example, referring to Figure 3, the authentication service may provide a response to the 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 transmitted. It can be determined whether the request is authentic or not. The authenticity of a request can depend on one or more factors that are checked by an entity such as an authentication service or a combination of entities that collectively perform such checks. Authenticity, for example, means that the request provides valid proof that is required (eg, a digital signature generated by a private key shared by the entity being inspected), and / or the policy fulfills the request. It may be required to make it possible. From the perspective of a system that submits an authentication request and receives an authentication response, authenticity can depend on the authentication response received. As a result, in one embodiment, determining whether the request is authentic or not 408 can be performed at least in part based on the authentication response received. For example, if the authentication is not authentic, the authentication response may indicate so and make a decision 408 accordingly. Similarly, the response can implicitly indicate that the authentication request is authentic, for example by not including information that could be included if the request was authentic. If the PUT request is determined to be unauthentic 408, the PUT request may be rejected 410. Rejecting a PUT request can be performed in any suitable manner and can depend on the various embodiments in which Process 400 is running. For example, by rejecting 410, the PUT request may include transmitting a message to the user who submitted the PUT request. The message may indicate that the request has been rejected. Rejecting a request can be used to determine how to resolve any problem that resulted in the PUT request being incorrect or not permitted, such as an inaccurate digital signature or other reasons. Why the request was rejected

0028If the PUT request is determined to be genuine and permissible 408, in one embodiment, process 400 comprises performing 412 one or more cryptographic operations that result in the plaintext being encrypted. For example, a cryptographic service may be submitted with a request (eg, a well-configured API call) to provide a key used to perform one or more cryptographic operations. It is possible to independently determine whether a cryptographic service performs a cryptographic operation (eg, encrypting plaintext to provide ciphertext, or generating an envelope key that can be used to encrypt plaintext). As possible, the request provided to the cryptographic service may provide proof that the PUT request is authentic. However, in various embodiments, the certificate may not be provided to the cryptographic service, for example, the cryptographic service may operate according to the requirements it receives. For example, if the cryptographic service receives a request from the data service front end, the cryptographic service may rely on the fact that the data service front end has already independently verified the authentication of the request. In such and other embodiments, the data service front end may authenticate itself with cryptographic services to provide an additional layer of security. Cryptographic services are obtained in response to a request by generating or otherwise obtaining a key and encrypting the obtained key or obtaining another encrypted key (eg, from memory). It may provide a key and an encrypted key. The resulting key can be encrypted using the key identified in the request to the cryptographic service. The resulting key can be used to encrypt the plaintext, and after encrypting the plaintext, the resulting key can be discarded (eg, irrevocably removed from memory). In an alternative embodiment, the system performing process 400 obtains the key used to perform one or more cryptographic operations, either generating or otherwise obtaining the key obtained to encrypt it. Can be provided to cryptographic services.

0029In some embodiments, performing one or more cryptographic operations can result in the generation of ciphertext. The ciphertext generated as a result of one or more cryptographic operations can be stored 414 for later possible reads. As mentioned above, the storage of the ciphertext may include the storage of additional information that may allow the subsequent decryption of the ciphertext. The ciphertext is stored with the identifier of the key used to encrypt the plaintext, for example, so that the key with that identifier can later be used to decrypt the ciphertext to obtain the plaintext. obtain. Ciphertext storage can also be performed in any suitable format. For example, ciphertext storage can be performed by the data service backend storage system, as described above.

0030Therefore, FIG. 5 shows an exemplary embodiment of the flow of information exemplifying how the environment 500 and plaintext can be obtained. Environment 500 of this embodiment 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 can be such a system. As illustrated in Figure 5, the data service front end is configured to receive a GET request from a user and respond in response to provide plaintext. To do this, the data service front end may also be configured to provide a certificate to the data service front end, where appropriate, to submit an authentication request to the authentication service. Can be configured. The data service front end can also be configured to send a request to a cryptographic service to perform one or more cryptographic operations related to decrypting the data. In one embodiment in which an envelope key is used, the data service makes a request (eg, an API call) that includes or identifies a certificate of encryption for the encrypted envelope key (or an encrypted envelope key identifier). And the identifier of the master key used to encrypt the envelope key can be submitted to the cryptographic service. The cryptographic service can determine if the certificate is sufficient to enable operation and, if the certificate is sufficient, can decrypt the envelope key. The decrypted envelope key can be sent back to a data service that can use the key to decrypt the encrypted plaintext. The data service can then discard the decrypted plaintext key.

0031In an alternative embodiment, the data service front end may be configured to provide the cryptographic service with the received credentials, along with the ciphertext that the cryptographic service decrypts. As a result, the cryptographic service determines if the certificate is sufficient to allow the ciphertext to be decrypted, and if the certificate is sufficient, the appropriate key (by the data service front end). It can be configured to decrypt the ciphertext using (which can be identified by the cryptographic service) and provide the decrypted ciphertext (plain text) to the data service front end. To provide the ciphertext to the cryptographic service, the data service front end may be configured to obtain the ciphertext from the data service backend storage system (eg, via a well-configured API call).

0032FIG. 6 shows an exemplary embodiment of Process 600 that can be used to obtain plaintext according to various embodiments. Process 600 can be performed, for example, by a data service front-end system (data service front-end), exemplified above in connection with FIG. 5, while process 600 and its variants are performed by any suitable system. Good. In one embodiment, process 600 comprises receiving 602 a GET request (or other suitable request) from the user. Receiving a GET request can be performed as described above in connection with other types of requests. Upon receipt of the GET request 602, the authentication request may be submitted to the authentication service or in any form as described above. An authentication response can be received accordingly. Whether the GET request is authentic or not can be determined 608, at least in part, based on the authentication response received. If the GET request is determined to be unauthentic 608, process 600 may include rejecting the request, which may be executed in different ways according to different embodiments, as described above.

0033If the GET request is determined to be authentic 608, process 600 may include reading the ciphertext from the storage device. Recovering the ciphertext from the containment device 612 can be performed in any suitable manner. For example, referring to Environment 500 above in connection with FIG. 5, the data service front end may submit a request for the ciphertext to the data service backend storage system and may receive the ciphertext in response. In general, the ciphertext can be obtained from the storage device in any suitable format. Upon receiving the ciphertext, process 600 may include performing one or more actions related to decrypting the ciphertext. For example, in one embodiment, the data storage service may send a request to the cryptographic service to perform one or more cryptographic operations related to decrypting the ciphertext. In one embodiment of the configuration, the data service may send an API call to the cryptographic service that includes an encrypted envelope key (or an encrypted envelope key identifier) certificate and encrypt the envelope key. The identifier of the master key used to do so may be sent to the cryptographic service. The cryptographic service can determine if the certificate is sufficient to enable operation and, if the certificate is sufficient, can decrypt the envelope key. The decrypted envelope key can be sent back to a data service that can use the key to decrypt the encrypted plaintext.

0034In another configuration, the ciphertext may be provided to a cryptographic service, such as the cryptographic service described above in relation to FIG. Other information, such as proof of authentication that can be used by the cryptographic service to determine whether to break the ciphertext, may also be provided to the cryptographic service. Further, in some embodiments, the key identifier used by the cryptographic service to decrypt the ciphertext may be provided to the cryptographic service. However, in other embodiments, the key can be implicitly shown to the cryptographic service. For example, the cryptographic service may use the default key associated with the customer shown in the cryptographic service. In general, any form can be used that allows the cryptographic service to determine which key to use to break the ciphertext.

0035As illustrated in Figure 6, process 600 may include providing a response to a GET request after the ciphertext has been decrypted. Providing a response to a GET request can be performed in different ways according to different embodiments. For example, providing a response to a GET request can include providing plaintext. In other embodiments, the plaintext can be the key used to decrypt other encrypted information that is then provided in response to the GET request. In general, depending on the role of the plaintext in a particular embodiment of the present disclosure, providing a response to a GET request can be performed in a variety of ways.

0036As mentioned, various embodiments of the present disclosure allow data to be stored in various ways by a data storage service. FIG. 7 shows an exemplary embodiment of the 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 embodiment, the data service front end is a computer system configured to receive PUT requests from various users. The PUT request may include or specify a data object to be stored by the data service backend storage system. The PUT request can also identify the key identifier of the key used to encrypt the data object. To provide a certificate of authentication to a cryptographic service that is capable of receiving a key and a key identifier and acting in response to a key encrypted by a key identified by the key identifier. In addition, as mentioned above, it can also be configured to interact with the authentication service. The data service front end can then trigger storage within the data service back end storage system. The data that can be stored can include a data object encrypted by a key. The data that can be stored can also include a key that is encrypted by the key identified by the key identifier. Encrypted data objects and encrypted keys can be stored in different services, as described elsewhere herein.

0037As illustrated in FIG. 7, the data service front end is configured to provide encrypted information to the data service back end storage system for storage. In this embodiment, the data service front end is configured to provide a key-encrypted data object and another key-encrypted key having a key ID. It should be noted that for the purpose of illustration, curly braces are used to indicate encryption. In particular, the information in curly braces is the information encrypted under the key specified by the subscript. For example, the {data target} key indicates that the data "data target" is encrypted under the key "key". It should be noted that using this curly braces notation, key identifiers can also appear as subscripts. When a key identifier appears in the subscript, the information in curly braces is encrypted under the key identified by the key identifier. For example, the {data object} key ID indicates that the data object "data object" is encrypted under the key identified by the key identifier "key ID". Similarly, the {key} key ID indicates that the key "key" is encrypted under the key identified by the key identifier "key ID". In other words, the present disclosure makes use of both keys and key identifiers in subscripts, and the meaning of subscripts should be clear from the context. The ciphertext may contain additional metadata that can be used to determine the ID of the associated decryption key.

0038FIG. 8 illustrates an exemplary embodiment of process 800 that can be performed to store a data object within a data storage system, such as the data service backend storage system described above in connection with FIG. Process 800 can be performed by any suitable system, such as the data service front-end system described above in connection with FIG. 7. In one embodiment, process 800 comprises receiving 802 a PUT request for a data object. Receiving a PUT request for a data object can be performed in any suitable manner, eg, as described above. It should be noted that the data object can be received in connection with the request or from another service. For example, the request may include an identifier for the data object, which can be obtained from another service using the identifier. Similar to the other processes described above, process 800 in one embodiment includes submitting an authentication request 804 and receiving an authentication response 806. The authentication response received 806 can be used to determine if the PUT request is a genuine request. If the PUT request is determined to be unauthentic 808, process 800 may include rejecting the request 810 as described above. If the PUT request is determined to be authentic 808, process 800 may include obtaining a key identifier (key ID), such as the key ID of the master key used to encrypt the envelope key. Obtaining the key ID 812 can be performed in any suitable fashion, and the style in which the key ID is obtained can vary according to various embodiments. For example, as illustrated in Figure 7, a PUT request can identify a key ID. As another embodiment, the user's ID or otherwise associated with the user can be used to obtain an identifier or a default key. As another example, the ciphertext may provide an indication of the associated key ID. In yet another embodiment, one or more policy decisions may be used to determine which key identifier to obtain.

0039In one embodiment, process 800 also includes generating a key, such as an envelope key. Generating a key can be performed in any suitable manner, for example, by a cryptographic service or a service that requires cryptographic operations from a cryptographic service (eg, a data storage service). For example, a key can be generated using a key derivation function, using the appropriate input to the key derivation function. Examples of the key derivation function include KDF1 defined in IEEE standard 1363 2000, the key derivation function defined in ANSI X9.42, and the HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) specified in RFC5869. ) And other HMAC-based key derivation functions. As another example, the key is the National Institute of Standards and Technology Special Publication (NIST). It can be generated by a random or false random number generator, a hardware entropy source, or a definitive random bit generator, such as those specified by SP) 800-90A. It should be noted that while Figure 8 shows process 800 involving the generation of the key 814, the key can be obtained in other ways, such as by recovering from the containment device. In other words, the key may have been pre-generated.

0040Continuing with the process 800 illustrated in FIG. 8, in one embodiment the process 800 comprises using the generated key to encrypt the data object 816. For example, in an embodiment in which a cryptographic service generates a key, the cryptographic service may provide the data service with a key, a key ID, and an encrypted copy of the key. For example, referring to Figure 7, the data service front end provides the envelope key and the key ID of the master key used to encrypt the envelope key, along with any other relevant information such as credentials. Can be received from. A plaintext copy of the encryption key can then be used to encrypt the data object. A plaintext copy of the encryption key can be discarded, and the encrypted data object as well as the encrypted key can then be stored 818. For example, referring to FIG. 7, the data service front end may transmit an encrypted data object and an encrypted key to the data service back end storage system for storage. In a configuration where the service generates a key, the service may provide the key and key ID to the cryptographic service. For example, the data service front end may send the envelope key and the key ID of the master key used to encrypt the envelope key to the cryptographic service along with any other relevant information such as authentication authorization. A plaintext copy of the encryption key can then be used to encrypt the data object. The service may discard the plaintext copy of the encryption key and the encrypted data object, and the encrypted key may then be stored. For example, referring to FIG. 7, the data service front end may transmit an encrypted data object and an encrypted key to the data service back end storage system for storage.

0041Encrypted data objects and encrypted envelope keys can be stored without a plaintext version of the key, that is, the plaintext key is for the data service backend storage system and one or more other systems. It can be inaccessible. The key under which the data object is encrypted (eg, the master key) can be made inaccessible in any suitable manner. In some embodiments, this is achieved by storing it in memory that is only accessible to cryptographic services. In some other embodiments, this can be achieved by storing the master key within the hardware or other security module, or otherwise under the protection of the hardware or other security module. In some embodiments, the memory location that stores the plain envelope key (eg, the memory of the data service) can be overridden, or the memory location that stores the key is to the data service front end. It can be intentionally overwritten to make the key inaccessible. As another embodiment, the plaintext envelope key can be kept in volatile memory, which eventually no longer stores the key. In this way, the envelope key is separated, such as by cracking the key without using the key identified by the key ID, although it can be identified by the key ID or computer impractical. It is accessible only if it is decrypted using a key, obtained in an unauthorized format. In other words, the key identified by the key ID is required to have authorized access to the key under which the data object is encrypted. Therefore, if the data service backend storage system of Figure 7 is compromised, such compromise cannot provide access to the unencrypted data object, which can decrypt the data object. This is because it may require access to the key, which can only be obtained through decryption using the key identified by the key ID, or through other methods that are not computer feasible.

0042As mentioned, various embodiments of the present disclosure allow the user to store data objects and read them out in a secure manner. Therefore, FIG. 9 shows an exemplary embodiment of an environment 900 that can be used to obtain data objects from a storage device. 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, cryptographic service, data service front end, and data service back end storage system can be a computer system 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. In order to respond and provide a data object, the data storage front-end system of this embodiment interacts with an authentication service, a cryptographic service, and a data service back-end storage system, as illustrated in FIG. It is composed. For example, in various embodiments, the data service front-end system is configured to submit an authentication request to an authentication service and receive an authentication certificate in response to the request. As another embodiment, the data service front end now determines whether to provide a key and a key encrypted with a key identified by a key ID, at least in part based on the certificate. It is configured to provide the key to the data service front end if it is determined to provide the key to an operational cryptographic service. The data service front end may also be configured to provide other information, such as a key ID, to the cryptographic service. However, in some embodiments, the key ID may be implicitly presented to the cryptographic service, for example through association with other information provided to the cryptographic service. In some embodiments, the user provides the key ID to the data service front end in connection with submitting the request to the data service front end. It should also be noted that Further, as illustrated in FIG. 9, in one embodiment, the data service front end requests a data object from the data service back end storage system, and in response, the key-encrypted data object and It is configured to receive the key encrypted by the key identified by the key ID. In some embodiments, the cryptographic service may be able to act to refuse to perform decryption of ciphertext that was not generated using the key associated with the identified key ID.

0043In one embodiment, the data service front end is configured to use the key received from the cryptographic service to decrypt the data object and provide the user with the decrypted data object. Therefore, FIG. 10 shows an exemplary embodiment of Process 1000 that can be used to provide a decoded subject according to various embodiments. Process 1000 can be performed by any suitable system, such as the data service front-end system described in connection with FIG. In one embodiment, process 1000 comprises receiving 1002 a GET request for a data object. Receiving a GET request for a data object can be performed in any suitable manner, as described above in relation to other types of requests. For example, a GET request for a data object may include information used to authenticate the request and / or other information. Thus, in one embodiment, process 1000, like any other process described herein, includes submitting an authentication request to the authentication system 1004 and receiving an authentication response 1006. Submitting an authentication request and receiving an authentication response can be performed in any suitable manner as described above. The authentication response can be used to determine 1008 whether the GET request is authentic. If the GET request is determined to be unauthentic 1008, in one embodiment the process 1000 comprises rejecting the request 1010. However, if the GET request is determined to be authentic 1008, in one embodiment, process 1000 includes recovering the encrypted data object and the encrypted key from the storage device 1012. For example, a data service front-end system can obtain an encrypted data object and an encrypted key from the data service back-end storage system exemplified above in connection with FIG.

0044In one embodiment, process 1000 comprises providing an encrypted envelope key to a cryptographic service 1014. Providing an encrypted envelope key to a cryptographic service 1014 allows it to be performed in any suitable manner and to allow the cryptographic service to determine whether to decrypt the encrypted key. It may be provided with other information such as certification. In addition, providing the cryptographic service with an encrypted envelope key 1014 allows the cryptographic service to select a key identified by an identifier from among multiple keys managed by the cryptographic service. For this purpose, it may include providing the key identifier required for the authorized decryption of the encrypted envelope key. However, as mentioned above, the key can be implicitly identified. Therefore, the cryptographic service can choose the appropriate key to decrypt the encrypted key. Thus, in one embodiment, process 1000 includes receiving the decrypted envelope key from the cryptographic service 1016. For example, if the cryptographic service determines that the certificate is valid and / or that the decryption of the encrypted one is acceptable according to any applicable policy, the cryptographic service will decipher the decrypted key. It can be provided to the system trying to decrypt the data object. The data object can then be decrypted 1018 using the decrypted envelope key. The decrypted data object can then be provided to the user or requester, such as another system, who submitted the GET request 1020.

0045In many cases, it is desirable for the user (ie, the device that typically utilizes the cryptographic service) to interact directly with the cryptographic service. Therefore, FIG. 11 shows an exemplary example of environment 1100 that allows direct user access to cryptographic services. Environment 1100 includes 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 can be as described above. For example, a data service front end may be configured to receive and respond to a request from a user via a suitable network, as illustrated in FIG. As part of responding to requests from users over the network, the data service front end interacts with the authentication service to determine if the user request is authentic and / or to enforce the policy on the request. It can also be configured to do so. The data service front end may also be configured to interact with the data service back end storage system as part of fulfilling the user request. The user request may include, for example, a PUT request to store the data in the backend storage system and a GET request to read the data from the data service backend storage system. As described above, other requests such as, for example, 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, and the like. Can also be used according to various embodiments.

0046In the specific embodiment 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 crypto service front end is configured to receive and respond to requests from users over the network. The cryptographic service front end is also configured to interact with the authentication service to determine if the user request is authentic. Determining whether a user request is authentic can be performed in the simple manner described above. It should be noted that the cryptographic service frontend and the data service frontend interact with the same authentication service, but the cryptographic service frontend and the data service frontend can interact with different authentication services. In addition, cryptographic service frontends can be configured to enforce policies when responding to user requests.

0047In one embodiment, the cryptographic service frontend is configured to interact with the cryptographic service backend. The cryptographic service backend is configured to perform cryptographic operations according to instructions received from the cryptographic service frontend. Cryptographic operations include encryption, decryption, hash calculation, and the like. Environment 1100 may be used by a user to have plaintext encrypted by a cryptographic service, for example, so that encrypted data can be stored within a data service backend storage system. Examples of such use of Environment 1100 are provided below. In addition, detailed examples of cryptographic service embodiments are also provided below.

0048The data can be stored within the data service backend storage system in any suitable format as described above. For example, the technique for storing the above encrypted data in a backend storage system can be used in environment 1100. For example, although not illustrated, the data service front end can communicate with the crypto service front end to cause the crypto service backend to encrypt the data, which data is later stored in the data service backend storage system. Can be stored. The encrypted data can be the data object and / or the encrypted key used to encrypt the data object. In environment 1100, the data can be otherwise placed in the data service backend storage system. For example, a user may provide plaintext encrypted by a cryptographic service and may receive the ciphertext in response. The user may then submit a request to the data service front end requesting that the ciphertext be stored within the data service backend storage system. The data service front end may store the ciphertext in any format in this embodiment. For example, data service front-end and back-end storage systems can be configured to be irrelevant whether the data is encrypted or not.

0049In addition, as with all environments exemplified herein, additional front-end systems, such as users, data service front-ends, cryptographic service front-ends, and possibly others, to coordinate behavior between systems. Can be logically positioned between and the front-end system of. For example, in some embodiments, the user may interact with a front-end system that itself interacts with the cryptographic service front end and the data service front end so that it is easier to operate from the user's point of view. For example, a user may require that the data object be stored encrypted and that the front-end system responds to the request through appropriate interaction with the cryptographic service front-end and the data service front-end. However, from the user's point of view, this can be done with a single request. Other modifications are also within the scope of this disclosure.

0050FIG. 12 shows exemplary embodiments of the environment 1200 that can be used to implement the various embodiments of the present disclosure. In FIG. 12, environment 1200 is configured to allow users to store ciphertext within a data service backend storage system. Thus, as illustrated in FIG. 12, environment 1200 includes a data service front end, a data service back end storage system, an authentication service, a crypto service front end, and a crypto service back end. The data service backend storage system, data service frontend, authentication service, cryptographic service frontend, and cryptographic service backend can be such systems as described in connection with FIG. 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 implement policies regarding user requests. The data service front end may be configured to submit an authentication request to an authentication service and respond in response to receive an authentication certificate as part of responding to the request. Upon successful authentication, the data service front end further configures to interact with the data service backend storage system to obtain encrypted and possibly unencrypted data objects from the data service backend storage system. It can be provided to the user later.

0051As illustrated in FIG. 12, the cryptographic service front end is also configured to submit an authentication request to the authentication service and receive an authentication certificate in response. Proof of authentication can be used to obtain service from a cryptographic service backend. For example, a cryptographic service frontend may be configured to provide a ciphertext with a certificate to the cryptographic service backend, and a cryptographic service backend may be configured to decrypt the ciphertext and provide the ciphertext in exchange. obtain. As illustrated in Figure 12, the cryptographic text can be an encrypted key, and the cryptographic service backend decrypts the encrypted key and puts the decrypted key, the plaintext key, into the cryptographic service frontend. It can be provided, which is further configured to provide the plaintext key to the user. The user can then use the key to decrypt the encrypted data object received from the data service front end, or within the user's domain (eg, within the data center or computer system that the user operates or controls). The encrypted data object stored in can be decrypted. In this embodiment, the user may have obtained the encrypted key from the data service front end. For example, the user may have submitted a request to the data service front end for the data object and / or the key used to encrypt the data object. While illustrated in Figure 11 as a single request, separate requests can be made for both the data object and the key. As illustrated in FIG. 11, the data service front end obtains an encrypted data object and an encrypted key from the data service backend storage system, and the encrypted data object and the encrypted key. Can be provided to the user.

0052It should be noted that, as with all environments exemplified herein, modifications are considered to be within the scope of this disclosure. For example, FIG. 12 shows a data object encrypted under a key and a key encrypted by another key identified by a key identifier being provided to the user. Further levels of encryption can also be used. For example, the data object can be encrypted under a key that is only accessible to the user (and / or not accessible by other components of Environment 1200). The key used to encrypt the data object can also be encrypted under a key that is only accessible to the user. Unauthorized access to the components of Environment 1200 (user absent) is unencrypted for the data object, as in this embodiment it is still required for unauthorized decryption of the user's key. Does not provide access to content.

0053As another embodiment, in the environment 1200 illustrated in FIG. 12, the data service front end and the data service back end storage system do not have access to the plain text data stored by the data service back end storage system. This is because the data service front end and data service back end storage systems do not have access to the keys needed to decrypt the encrypted data. However, in some embodiments, access to the data service front end and / or data service back end storage system may be granted. For example, in one embodiment, temporary access to the key is provided to the data service front end, which obtains the encrypted data, decrypts the encrypted data, specific. It may be possible to use the decrypted data for a purpose (eg indexing) and then delete or otherwise lose access to the decrypted data. Such behavior may be governed by policies enforced by the data services front end and / or cryptographic services and may require permission from the user.

0054FIG. 13 illustrates an exemplary embodiment of process 1300, which can be used to obtain an encrypted data object and an encrypted key from a data service backend storage system or the like as described above. For example, process 1300 may be performed by the data service front-end system described above in relation to FIG. In one embodiment, process 1300 comprises receiving 1302 a GET request for an encrypted data object. Receiving a GET request can be performed in any suitable manner, such as by receiving the request via an API call to the data service front-end system. As a result of receiving the GET request, process 1300 may include submitting an authentication request 1304 and receiving an authentication response 1306. Submitting an authentication request 1304 and receiving an authentication response 1306 can be performed in any suitable manner as described above. The authentication response can be used to determine if the GET request is authentic 1308. If the GET request is determined to be unauthentic and 1308, process 1300 may include rejecting the GET request 1310. Rejecting a GET request 1310 can be performed in any suitable manner as described above. However, if the GET request is determined to be genuine in 1308, process 1300 can use the encrypted data object to decrypt the encrypted data object once it has been decrypted. Can include providing 1312. It should be noted that, as with all processes described herein, numerous modifications are considered to be within the scope of this disclosure. For example, process 1300 may be configured to respond to a GET request by providing an encrypted data object but not an encrypted key if the GET request is genuine. The requester, the user or system submitting the GET request, can otherwise obtain the encrypted key. For example, in some embodiments, the user is the user Under control, the encrypted key can be stored in its own data storage system. As another example, one storage service can store an encrypted data object, another service can store an encrypted key, and the user can store the encrypted data object and the encrypted key, respectively. Can be obtained from the service of. As another example, another service or third party can be used to store the encrypted key, allowing the user to obtain the encrypted key on request. In general, any method can be used in which an encrypted key can be provided.

0055As illustrated in FIG. 13, process 1300 may result in a data object and an entity provided with 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. Thus, FIG. 14 can be used to provide a decrypted key to an entity that requires such a decrypted key in order to use the decrypted key for decrypting an encrypted data object. , An exemplary embodiment of process 1400 is shown. Process 1400 can be performed by any suitable system, such as the cryptographic service front-end system described above in connection with FIG. In one embodiment, process 1400 comprises receiving 1402 decryption in order to decrypt the key using another key with the identified key ID. It should be noted that while process 1400 is described in relation to key decryption, process 1400 can generally be adapted for data decryption. The decryption request can be received 1402 in any suitable manner as described above (eg, via a well-configured API call). In addition, the decryption request can be received by any entity that is appropriate for the context in which process 1400 is running. For example, the decryption request may come from the user or another system such as the data service front end described above. The decryption request may also include the data to be decrypted (eg, the key) or a reference to it. The key ID can also be identified in any suitable fashion. For example, in some embodiments, the decryption request includes a key ID or a reference to the key ID, that is, information that can be used to determine the key ID. As mentioned above, the key ID can also be identified implicitly. For example, the key ID can be obtained through association with available data such as the ID of the requester who submitted the decryption request. For example, the key corresponding to the key ID can be the default key for the requester, or the entity for which the request was submitted.

0056In one embodiment, process 1400 comprises submitting an authentication request 1404 and receiving an authentication response 1406. Submitting an authentication request 1404 and receiving an authentication response 1406 can be performed in any suitable manner as described above. In addition, as mentioned above, the received authentication response can be used to determine if the GET request is authentic 1408. If the GET request is determined to be unauthentic and 1408 is determined, process 1400 may include rejecting the GET request 1410. Rejecting a GET request 1410 can be performed in any suitable manner, as described above. However, if the GET request is determined to be genuine 1408, process 1400 may include accessing policy information about the identified key ID and / or about the requester. The policy information can include one or more policies of the key ID and / or requester.

0057In one embodiment, the accessed policy information is used to determine whether any applicable policy allows decryption of a key with a particular key ID. If it is determined that the policy does not allow decryption of the key identified by the key ID 1414, process 1400 may include rejecting the GET request 1410 as described above. However, if the policy determines that it is possible to decrypt a key with a specified key ID 1414, process 1400 may include decrypting the key 1416 using the key identified by the key ID. When a key is decrypted using a key with a key ID, the decrypted key is then authorized by the requester (or in some embodiments, another) who submitted the decryption request, such as by transmission over a network. Can be provided to the destination) 1418.

0058As illustrated in the environment 1200 above, the user can obtain the encrypted data object and the key to decrypt the data object in various ways. FIG. 15 shows an exemplary embodiment of Process 1500 that can be used to obtain plaintext according to various embodiments. Process 1500 may be performed by any suitable system, such as by a system operated and / or hosted by the user, as described in connection with FIG. Other suitable systems include systems that operate on behalf of the user and do not necessarily follow the provided real-time user, but perhaps a pre-programmed process.

0059In one embodiment, process 1500 comprises receiving 1502 ciphertext from a data storage service. Requesting the ciphertext 1502 from the data storage service can be performed in any suitable manner as described above. For example, a system running process 1500 was described above using the well-configured API calls of environment 1200 illustrated above in connection with Figure 12 and / or in connection with Figure 13. Process 1300 may request ciphertext 1502.

0060Process 1500 may also include receiving ciphertext and encrypted keys. Receiving ciphertext and encrypted keys can be performed in any suitable manner. For example, the ciphertext and the encrypted key can be received in response to a ciphertext request from the data storage service. However, in general, the ciphertext and the encrypted key can be received 1504 in other suitable ways. For example, the request to receive the ciphertext from the data storage service can be an asynchronous request, and the ciphertext can be received 1504 according to another request submitted later. In addition, the ciphertext and the encrypted key can be provided in a single response, or can be obtained separately by different responses (which can be from the same or different systems), etc. As another example, a system running process 1500 may store the encrypted key locally or otherwise, and the encrypted key may be received from local memory.

0061In one embodiment, process 1500 comprises requesting decryption of an encrypted key using a key with a identified key ID. The key ID can be specified in any suitable format as described above. In addition, it should be noted that the system running process 1500 can identify the key ID in any suitable manner. For example, the encrypted key and / or the information provided therein may identify the key ID. As another example, a system running process 1500 may have local or remote access to information that allows it to determine the key ID. For example, a local or remote database may associate a data object identifier with the key identifier of the key used to encrypt the data object. In general, any form can be used that allows the system to identify the key ID. Further, in some embodiments, the key ID does not need to be specified, such as when the information provided to the cryptographic service is sufficient to determine the key ID. Request 1506 for decryption of the encrypted key is any suitable, such as in connection with the environment described above in connection with FIG. 12 and / or by performing process 1400 described above in connection with FIG. Can be carried out in style.

0062Process 1500, in one embodiment, comprises receiving 1508 the decrypted key. Receiving a decrypted key 1508 can be performed in any suitable manner. For example, a decrypted key can be received in response to a request to decrypt an encrypted key. As another example, a request to decrypt an encrypted key could be an asynchronous request, and another request may have been submitted to receive the decrypted key. In general, the decrypted key can be received in any suitable fashion. Moreover, as with all information flowing from one device to another, the passage of information can be performed using secure channels. For example, the decrypted key can be re-encrypted for decryption by the entity receiving the decrypted key. In general, any form of secure communication can be used to pass information from one entity to another.

0063When the decrypted key is received 1508, process 1500 may include using the decrypted key 1510 to decrypt the ciphertext 1510 and thus obtain the plaintext. It should be noted that, as with all processes described herein, modifications are considered to be within the scope of this disclosure. For example, process 1500 indicates that a ciphertext request and an encrypted key decryption request are being executed continuously. However, like many of the operations described herein in relation to the various processes, the operations need not be performed continuously in various embodiments. For example, if the system running process 1500 has access to the encrypted key before requesting the ciphertext, or can otherwise, the system may request the ciphertext and , In parallel or in a different order than illustrated, may require decryption of the encrypted key. Other modifications are also considered to be within the scope of this disclosure.

0064As mentioned above, the various embodiments of the present disclosure are intended to provide cryptographic services. Cryptographic services can be provided by cryptographic service systems such as those described above. Therefore, FIG. 16 shows exemplary examples of cryptographic service 1600 according to various embodiments. As illustrated and described above in FIG. 16, the cryptographic service 1600 is logically composed of a front-end system and a back-end system. Both front-end and back-end systems can be implemented by one or more computer systems configured to perform the operations described herein. For example, as illustrated in Figure 16, the cryptographic service 1600 front-end system implements a request API and a policy configuration API. In one embodiment, the request API is an API configured to require cryptographic and other operations to be performed by a cryptographic service. Therefore, a request can be made to the front-end system via the request API so that such a cryptographic operation is performed by the cryptographic service.

0065The request API may consist of the following high-level available request examples. Key creation (key ID) Encryption (key ID, data, [AAD]) Decryption (key ID, ciphertext, [AAD]) Shred (key ID) Key re-creation (ciphertext, old key ID, new key ID).

0066A key creation (key ID) request, in one embodiment, causes a cryptographic service to create a key identified by a key ID identified in the request. Upon receiving the request, the cryptographic service can generate a key and associate that key with the key ID. It should be understood that the one with the key ID can be a unique identifier, but not necessarily. For example, a key ID can identify a family of keys. For example, in some embodiments, key rotation is performed. Key rotation may include exchanging a key for another key to prevent the collection of decrypted data sufficient to allow practical cracking of the cipher used. When performed in the direction of an entity different from the cryptographic service, the use of a key creation (key ID) request may cause the cryptographic service to create a new key to exchange for the old key identified by the key ID. The old key can remain identified by the key ID, for example, it may only be used for decryption (of data already encrypted with the old key) and not for future encryption. is there. As another embodiment, in some embodiments, users of cryptographic services may provide their own key identifier, and two different customers may provide the same identifier. In such an example, the identifier cannot uniquely identify the key, or even the family of keys. Various methods can be put in place to deal with this. For example, other information associated with the user of the identity or cryptographic service can be used to identify the appropriate key or family of keys. In yet another embodiment, the cryptographic service may assign key IDs randomly, continuously, or using any other method.

0067It should be noted that if the key ID does not uniquely identify the key, various systems can be arranged to enable proper functioning. For example, in various embodiments, the family of keys identified by a key ID is finite. If a decryption operation using the key identified by the key ID is required, additional data (eg, the time stamp when the encryption was performed) may allow the determination of the appropriate key to use. In some embodiments, the ciphertext may include information indicating a key version. In some embodiments, all possible keys are used to provide different decryption of the data. Due to the finite number of keys, proper decryption can be selected from those provided. In some embodiments, key-based decryption detects that the ciphertext was not generated, at least in part, based on the key, such as by using authenticated encryption. Performed in a way that allows you to. Other modifications are also considered to be within the scope of this disclosure.

0068An encryption (key ID, data, [AAD]) request can be used to have a cryptographic service encrypt data identified using a key identified by a key ID. Additional authenticated data (AAD) can be used for a variety of purposes and is not necessarily encrypted, but for example, digital signatures, message authentication codes, or keyed hash values that are generally included with the AAD. Can be authenticated data by. In some embodiments, the ciphertext is generated containing at least a portion of the AAD. In some other embodiments, the AAD is provided separately during decoding. In some other embodiments, the AAD is generated at the decryption time, at least partially based on the request and other metadata so that the decryption succeeds only when the metadata passes. In some embodiments, the policy may constrain whether cryptographic operations can be performed for a particular AAD. The processing of cryptographic (key ID, data, [AAD]) requests is such that the AAD contains certain values and the AAD is authentic (eg, by programming a policy enforced by the logical and / or cryptographic service. It can require both (unmodified from the original transmission). Similarly, a decryption (key ID, ciphertext, [AAD]) request can be used to force a cryptographic service to decrypt a ciphertext identified using the key identified by the key ID. The AAD in the decryption (key ID, ciphertext, [AAD]) request can be used as described above. For example, the processing of decryption (key ID, ciphertext, [AAD]) is that AAD contains certain values and that AAD is authentic by enforcing policies enforced by logical and / or crypto services (AAD). It may require both (eg, not modified from the original transmission).

0069In one embodiment, a shred (key ID) can be used to cause a cryptographic service to electronically shred a key or a family of keys identified by a identified key ID. Electronic shredding can involve making the key no longer accessible. For example, the use of shredded (key ID) requests causes the cryptosystem to perform a secure erase operation on one or more hardware devices, on one or more keys identified by the identified key ID. I can order it. In general, a key (s) identified by a key ID is of any preference, such as by overwriting the data encoding the key with other data (eg, a series of 0s or 1s or a random string). Can be shredded electronically in any manner. When a key (s) is encrypted and stored under a key, the key used to encrypt the key can be electronically shredded and thus access to that key (s). Causes loss. In some embodiments, the shredded operation may cause a decryption operation that indicates that the shredded key ID will fail at some firm point in the future. Other modes can be used that securely and permanently destroy any possible access to the key (s).

0070In one embodiment, a rekey (ciphertext, old key ID, new key ID) request can be used by a cryptographic service to encrypt a ciphertext under a different key. When the cryptographic service receives a rekey (ciphertext, old key ID, new key ID) request, it uses the key identified by the old key ID to decrypt the identified ciphertext and then , The key identified by the new key ID can be used to encrypt the decrypted ciphertext. If the key identified by the new key ID does not yet exist, the cryptographic service will generate the key to use and generate the key, as mentioned above in the context of the create (key ID) request above. Can be associated with the identified new key ID. In some embodiments, the rekey operation may be operational to allow data to be transferred between isolated instances of cryptographic services. In some embodiments, the policy may allow the rekey operation to be performed on the ciphertext, but may not allow the same requester to decrypt the ciphertext directly. In some embodiments, the rekey rekey rekeys the ciphertext from the key identified by the first key ID in the first account to the key identified by the key ID in the second account. Can support creating.

0071Similarly, the front-end system may implement a policy configuration API, which, in one embodiment, requires the user to configure a policy for performing cryptographic actions and for other policy-related actions. Be able to submit. In various embodiments, the policy can be associated with a key, a group of keys, an account, a user, or other logical entity. Examples of policies that can be configured via the Policy Configuration API are provided below. In one embodiment, the cryptographic service policy configuration API contains the following requirements: Key setting policy (key ID, policy) Hold (key ID, public key) Restore (key ID, private key)

0072In one embodiment, a key configuration policy (key ID, policy) request can be used to cause a cryptographic service to store a policy regarding a key (or a family of keys) identified by a key ID. A policy can be information that determines whether a requested cryptographic action can be performed in a particular context. Policies are eXtensinble Access Control Markup Language (XACML), Enterprise Privacy Authorization Language (EPAL), Amazon Web Services Access Policy Language, Microsoft It can be coded within a declarative access control policy language, such as SecPol, or any suitable way to code one or more conditions that must also be met for the cryptographic operation performed. The policy is what action can be performed, when the action can be performed, which entity can make a permit request for the action to be performed, and which specific request is allowed. It can be defined whether information is required, etc. In addition, policies can be defined and / or implemented using access control lists, privileges associated with users, and / or behavioral bitmasks in addition to or in place of the examples given above. An example of the policy is shown below.

0073In some embodiments, the cryptographic service may support a hold operation, for example using a hold (key ID, public key) API call. The hold action allows the cryptographic service customer to deny the cryptographic service operator from using or accessing the key. This can be useful for customers who are concerned about other situations in which a secret legitimate order or cryptographic service operator may be forced to perform some action using the key. This can also be useful for customers who want to lock certain data and make it inaccessible online. In some embodiments, the provider holds the key unless the private key associated with the public key is provided using, for example, a restore (key ID, private key) API call that identifies the key ID and also includes the private key. The hold action is to receive the public key from the customer and to use the received public key to encrypt the key identified by the given key ID so that the key is not accessible. , And shredding the key identified by the key ID. In some other embodiments, the hold action is specified using another key managed by a cryptographic service, including but not limited to those created for the purpose of an immediate hold action. It may include encrypting the key associated with the key ID. The ciphertext generated by this operation can be provided to the customer and cannot be retained within the cryptographic service. The original key identified by the key ID can then be shredded. Cryptographic services may be able to act to receive the provided ciphertext and reimport the held key. In some embodiments, the ciphertext can be generated in a manner that can prevent the cryptographic service from returning the decrypted version to the customer.

0074As illustrated in FIG. 16, in some embodiments, the cryptographic service 1600 includes a back-end system that itself has various components. For example, the back-end system in this embodiment includes a request processing system, which can be a subsystem of cryptographic service 1600 configured to perform operations according to requests received through either the request API or the policy configuration API. .. For example, a request processing component may receive a request received via the request API, and the policy configuration API determines whether the request is authentic and thus feasible and makes the request. Can be accomplished. Performing a request involves, for example, performing and / or performing a cryptographic operation. The request processing unit may be configured to interact with an authentication interface that allows the request processing unit to determine if the request is authentic. The authentication interface can be configured to interact with an authentication system as described above. For example, when a request is received by a request processing unit, the request processing unit may utilize an authentication interface to provide an authentication certificate that, where applicable, can be used to perform cryptographic operations. Can interact with authentication services.

0075The back-end system of the cryptographic service 1600 includes a plurality of security modules (cryptographic modules) and policy enforcement modules in this exemplary embodiment. In various embodiments, the security module can be any suitable computer device configured to have the capabilities described herein, but one or more of the security modules are hardware security modules. Can be. Each security module in one embodiment stores a plurality of keys associated with a key ID. Each security module may be configured to securely store the key so that it is not accessible by other components of the cryptographic service 1600 and / or other components of the system. In one embodiment, some or all of the security modules comply with at least one security standard. For example, in some embodiments, the security module is federal information outlined in FIPS publications 140-1 and / or 140-2, such as one or more security levels outlined in FIPS publication 140-2. Each is proven to comply with the Federal Information Processing Standard (FIPS). In addition, in some embodiments, each security module is certified under the Cryptographic Module Verification Program (CMVP). A security module can be implemented as a hardware security module (HSM) or another security module with some or all of the capabilities of the HSM. In some embodiments, the proven module is used to bootstrap the operation. In some embodiments, the customer may configure some keys that are stored within a proven module and operate only thereby, and other keys that operate by software. In some embodiments, the implementation or costs associated with these various options may differ.

0076The security module may be configured to perform cryptographic operations according to the instructions provided by the request processing unit. For example, the request processing unit has instructions to the security module to decrypt the ciphertext and key ID using the key associated with that key ID and provide the plaintext in response. Can be provided to various security modules. In one embodiment, the cryptographic service 1600 back-end system securely stores multiple keys that form a key space. Each of the security modules can store all the keys in the key space, however, variants are considered to be within the scope of this disclosure. For example, each security module may store a subspace of a key space. Just as keys are stored in duplicate through the security module, the subspaces of the key space stored by the security module can be duplicated. In some embodiments, a particular key can only be stored within a particular geographic area. In some embodiments, a particular key may only be accessible to operations with a particular certification or clearance level. In some embodiments, a particular key may only be stored in and used only with a module operated by a particular third party under contract with a provider of data storage services. In some embodiments, constructive control of the security module is an additional entity, or additional jurisdiction that forces an action, for which a legitimate order attempts to force the use of a key other than permitted by the customer. May be required to include any of the above. In some embodiments, the customer may be offered an independent option for jurisdiction in which those ciphertexts are stored and their keys are stored. In some embodiments, the security module that stores the key may be configured to provide audit information to the key owner, and the security module will not be able to suppress the generation and provision of audit information by the customer. Can be configured as In some embodiments, the prober The security module should independently prove the signature generated by the customer so that Ida (eg, hosting the security module) cannot perform its actions under the key stored by the security module. Can be configured. In addition, some security models can store the entire key space, and some security modules can store subspaces of the key space. Other variations are also considered to be within the scope of this disclosure. In the example where different security modules store different subspaces of the key space, the request processing unit uses, for example, a relation table or other mechanism to determine which security module should be ordered to perform cryptographic operations according to various requests. Can be configured as

0077In one embodiment, the policy enforcement module is configured to obtain information from the request processing unit and, at least in part, determine whether a request received through the API can be executed based on that information. .. For example, if a request to perform a cryptographic operation is received through the request API, the request processing unit interacts with the policy enforcement module to apply any policy, etc. applicable to the key ID specified in the request. It may be possible to determine whether the request is permitted to be fulfilled according to possible policies and / or other policies such as those associated with the requester. If the policy enforcement module allows the request to be fulfilled, the request processing unit may instruct the appropriate security module to perform cryptographic operations as the request is fulfilled.

0078As with all drawings described herein, many modifications are considered to be within the scope of this disclosure. For example, Figure 16 shows a policy enforcement module that is separate from the security module. However, each security module may include a policy enforcement module in addition to, or instead of, a separately exemplified policy enforcement module. Therefore, each security module can be configured to implement the policy independently. Further, as another embodiment, each security module may include a policy enforcement module that implements a policy different from the policy enforced by a separate policy enforcement module. Many other variants are considered to be within the scope of this disclosure.

0079As mentioned above, various policies are configured by the user associated with the key ID so that the policy can be enforced if the request identifies the cryptographic action being performed in relation to the key corresponding to the key ID. obtain. FIG. 17 provides an exemplary example of Process 1700 for updating policies according to various embodiments. Process 1700 can be performed by any suitable system, such as a cryptographic service system, as described above in connection with FIG. In one embodiment, process 1300 comprises receiving 1302 a request to update the policy for the key ID. The request can be received 1302 in any suitable manner. For example, referring to FIG. 16 as an example, the request can be received through the policy configuration API of the cryptographic service 1600 front-end system described above. The request can be received in any suitable manner.

0080In one embodiment, process 1700 comprises submitting an authentication request 1704 and receiving an authentication response 1706. Submitting an authentication request 1704 and receiving an authentication response 1706 can be performed in any suitable manner as described above. In addition, as mentioned above, the received authentication response can be used to determine if the request to update the policy for the key ID is authentic or not 1708. If the received request to update the policy for the key ID is determined to be unauthentic 1708, the request can be rejected 1710. Rejecting a request 1710 can be performed in any suitable manner as described above. However, if the received request to update the policy for the key ID is determined to be genuine 1708, process 1700 may include accessing the policy information applicable to the requester 1712. The policy information can then be information to which any policy applicable to the requester can be enforced. For example, within an organization that utilizes cryptographic services performed by process 1700, only certain users of the organization may be allowed to update the policy on key identities. The policy information can indicate which user can force the cryptographic service to update the policy for the key ID and / or even whether the policy can be updated according to the existing policy. For example, in some embodiments, the cryptographic service may receive a request to implement the new policy. Cryptographic services may check whether any existing policy allows the new policy to be put in place. If the cryptographic service determines that the existing policy does not allow the new policy to be enforced, the request may be denied. In general, the policy information can be any information that can be used to implement the policy applicable to the requester.

0081As illustrated in Figure 17, process 1700 involves using the access policy information to determine whether the policy is capable of performing the requested update 1704. If the policy determines that it does not allow the requested update to be performed 1714, process 1700 may include rejecting the request 1710 as described above. However, if it is determined that the policy makes it possible to perform the requested update 1714, process 1700 may include updating the policy for the key ID 1716. Updating a policy about a key ID can include updating policy information according to or in connection with the key ID and storing the updated policy. The updated policy information may be stored, for example, by the cryptographic service policy enforcement module as described above in connection with FIG.

0082The policy can also be enforced by other components of the electronic environment operating in connection with cryptographic services. For example, referring to FIG. 2 above, the cryptographic service may provide the data service front end with an electronic display of the policy, as the data service front end does. Such may be useful in situations where the data service is better suited to implement the policy. For example, whether an action is enabled by a policy can be at least partially based on information accessible to the data service front end rather than the cryptographic service. As an example, a policy may rely on the data stored by the data service backend storage system for the customers associated with that policy.

0083As mentioned above, cryptographic services may include various systems that allow policy enforcement in accordance with policies regarding keys with key IDs. Therefore, FIG. 18 shows an exemplary embodiment of Process 1800 that can be used to implement the policy. Process 1800 can be performed by any suitable system, such as a cryptographic service system, as described above in connection with FIG. In one embodiment, process 1800 comprises receiving 1802 a request to perform one or more cryptographic operations using a key having a key ID. Figure 18 illustrates where process 1800 is running in connection with a request to perform one or more cryptographic operations, but process 1800 is not necessarily related to cryptography. It should be noted that it can be adapted for use with any requirement to perform the operation. An example of the operation is described above.

0084It can be determined in 1804 whether the received request is authentic. Determining whether a received request is authentic can be performed in any suitable manner as described above. For example, determining whether a request is authentic or not 1804 may include submitting an authentication request and receiving an authentication response, as described above. If the request is determined to be authentic 1804, process 1800 may include rejecting the request 1806. Rejecting the request 1806 can 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 key ID and / or policy information about the requester. Accessing policy information about key IDs and / or requests can be performed in any suitable manner. For example, accessing policy information about a key ID and / or requester can be performed by accessing storage policy information from one or more storage systems that store such policy information. Access policy information can be used to determine if a policy allows one or more actions to be performed.

0085Process 1800 may include rejecting the request 1806 if the policy determines that it does not allow it to perform one or more actions. However, if it is determined that the policy allows one or more operations to be performed, process 1800 may include performing 1812 one or more requested cryptographic operations. One or more results of performing one or more cryptographic actions may be provided 1814, eg, provided to the requester who submitted the incoming 1802 request to perform one or more cryptographic actions. In some embodiments, information derived at least in part from the enabled and / or denied requests may be provided through the audit subsystem.

0086As mentioned above, the embodiments of the present disclosure allow for flexible policy configuration and implementation. In some embodiments, the policy may state which service can perform which action in which context. For example, a key policy may allow a data storage service to cause a cryptographic service to perform a cryptographic action rather than a decryption action. The key policy may also include one or more conditions on the ciphertext and / or the decrypted plaintext. For example, the policy may require ciphertext and / or plaintext to generate a particular hash value (which can be a keyed hash value) before the result of the operation is provided in response to the request. The policy is at least partially based on the Internet Protocol (IP) from which the request is derived, the type of content to be encrypted / decrypted, AAD, and / or other information, and one or more restrictions and / or permissions. Can be identified.

0087Many variants are considered to be within the scope of this disclosure. For example, the various embodiments described above describe a dialogue with a separate authentication service. However, the components of the environment described above may have their own authorization components, and determining whether a request is authentic may or may not include communication with another entity. In addition, each of the above environments is exemplified in relation to the particular movements and capabilities enabled by the environment. The above techniques may be combined in relation to different environments, and in general, an environment in accordance with the present disclosure may allow flexible use of various techniques. As just one embodiment, cryptographic services can be used to encrypt both key and other content, such as non-key data objects, upon request. As another example, cryptographic services may be configured to receive and respond to requests from both users (eg, customers of computing resource providers) and other services (eg, data storage services). In some embodiments, cryptographic services and / or associated authentication services may be configured for use with mobile devices to perform encryption of stored data. In some embodiments, at least one unlock pin can be proven by cryptographic services. Still in other embodiments, the cryptographic service may receive the information generated by the hardware attestation as part of its operation. In some embodiments, the cryptographic service may be able to operate to provide a digital rights management service with respect to the content.

0088The embodiments of the present disclosure can be described with reference to the following appendices. 1. A computer implementation method for providing data storage services Under the control of a computing resource service provider, one or more computer systems consisting of executable instructions. Receiving a request from a customer of the computing resource service provider to use the data storage service of the computing resource service provider. As a result of receiving a request to use the data storage service, the cryptographic service of the computing resource service provider is provided with information encrypted by the cryptographic service using a key inaccessible to the data storage service. To provide, the information is the data object in unencrypted form and the key from multiple keys managed by the cryptographic service for multiple customers of the compute resource service provider. Can be used to obtain, provide and The computer implementation method comprising using the data storage service to store the encrypted information. 2. To provide the cryptographic service with proof information that allows the cryptographic service to provide the encrypted information so that the cryptographic service can verify the application for the received request. Including The computer implementation method according to Appendix 1, wherein the proof information is essential for the cryptographic service to provide the encrypted information. 3. The request for using the data storage service includes a request for storing data in encrypted form using the data storage service. The information contains a second key used to encrypt the data object. It is described in Appendix 1 or 2, that using the data storage service to store the encrypted information includes using the data storage service to store the data object in encrypted form. The computer mounting method. 4. Receiving a request to read the data object from the data storage service Obtaining the encrypted information from the data storage service To have the encryption service decrypt the encrypted information, The said in any one of Appendix 1-3, further comprising using the information to provide the data object in response to the received request to read the data object. Computer implementation method. 5. Using the information to provide the data object in response to the received request to read the data object, and using the key to decrypt the encrypted data object The computer mounting method according to Appendix 4, which comprises the above. 6. Providing the encrypted information to the encryption service for decryption, Have the cryptographic service check whether the policy for the key allows the key to be used to decrypt the encrypted information, and if so, the cryptography. The computer mounting method according to any one of Supplementary note 1 to 5, further comprising decoding the encrypted information. 7. Further including receiving information representing the policy regarding the key from the customer. A cryptographic service, the operating according to the policy represented, the computer implemented method according to any one of Appendices 1-6. 8. Receiving the key policy from the cryptographic service and Further including checking whether the received policy enables the fulfillment of the request. Having the cryptographic service provide the encrypted information depends on the policy that allows the fulfillment of the request. The computer implementation method according to Appendix 1, wherein the cryptographic service is operated according to the policy represented. The computer mounting method according to any one of Appendix 1 to 7, further comprising. 9. A computer implementation method for providing cryptographic services Under the control of one or more computer systems consisting of executable instructions As a result of the service receiving the first request to use the service, it receives a second request to perform one or more cryptographic operations necessary to fulfill the first request. To do and Performing one or more of the requested cryptographic actions and Providing the service with one or more results of performing the one or more requested cryptographic operations, the one or more results of the received request for using the service. The computer implementation method, including providing, which is necessary for at least one mode of performance. 10. The computer implementation method according to Appendix 9, wherein the one or more cryptographic operations include decryption of a key required to carry out the received request to use the data service. 11. Further including receiving information that verifies that the received request to use the data service is authentic. The said in Appendix 9 or 10, wherein performing the one or more cryptographic operations requires the receipt of the information that verifies that the received request to use the service is authentic. Computer implementation method. 12. The computer implementation method according to any one of Appendix 9 to 11, wherein the received request for using the service is a request for obtaining data stored by the service. 13. The computer implementation method according to any one of Appendix 9 to 12, wherein the received request for using the service is a request for storing data using the service. 14. Further comprising selecting at least one key to perform the one or more cryptographic operations from multiple keys, each containing at least two keys managed by the cryptographic service for different entities. The computer mounting method according to any one of Appendix 9 to 13. 15. The one or more cryptographic operations require the use of a key The method further comprises receiving a policy for the key for the key. The said in any one of Appendix 9-14, wherein performing the one or more cryptographic operations requires that the execution of the one or more cryptographic operations comply with the received policy. Computer implementation method. 16. Receiving a policy about the keys that can be used to perform the one or more cryptographic operations. Checking whether an existing policy allows implementation of that policy, The computer according to any one of Annex 9 to 15, further comprising denying the received policy as a result of the existing policy not allowing implementation of the policy. Implementation method. 17. It's a computer system With one or more processors Memory, at least in the computer system Cryptographic service, at least To store the multiple keys so that the multiple keys cannot access a service different from the cryptographic service. One or more keys required to select one key from the plurality of keys and use the selected key to carry out the pending request when the service detects a pending request. The computer system comprising a memory that stores instructions that can be executed by the one or more processors for implementing a cryptographic service that is configured to perform and perform cryptographic operations. 18. The computer system according to Appendix 17, wherein detecting the pending request in the service comprises receiving a notification and proof of the pending request in the service from the service. 19. The computer system is operated by a computing resource service provider The request is generated by one of the customers of the computing resource provider. The computer system according to Appendix 17 or 18, wherein each key of the plurality of keys has a corresponding customer of the computing resource provider. 20. The computer system according to any one of Appendix 17-19, wherein the cryptographic service is further configured to verify that the pending request is granted. 21. Any one of Appendix 17-20, further comprising a weighing service, configured to receive the output of the cryptographic service and generate account records based at least in part on the received output. The computer system according to. 22. The cryptographic service To store policy information that defines one or more policies for each of at least one subset of the keys. The computer system according to any one of Appendix 17-21, further configured to implement and to implement one or more of the defined policies. 23. The computer system is operated by a computing resource service provider Each key of the plurality of keys corresponds to the customer of the computing resource provider. The cryptographic service Receiving policy updates from customers of the computing resource provider The computer system according to Appendix 22, which is configured to update the stored policy information according to the received policy update. 24. A computer-readable storage medium that, when executed by one or more processors of a computer system, to the computer system, at least Receiving requests to use the service and As a result of receiving the request to use the service Based on the request, at least in part, the cryptographic service is provided with proof that the request has been received, thereby allowing the service to be used after one or more cryptographic operations have been performed. Having the key used to perform one or more cryptographic actions on the information that will be available to fulfill the request, The computer having instructions stored therein that perform and perform the request to use the service using the information in which the one or more cryptographic operations have been performed. Readable storage medium. 25. The computer-readable storage medium according to Appendix 24, which includes authentication information, which allows the proof to allow the cryptographic service to verify that the request for using the service is authentic. .. 26. The request to use the service includes a request to perform an operation related to the data object. The computer-readable storage medium according to Appendix 24 or 25, wherein the information is the key used to encrypt the data object. 27. When the instruction is executed by the one or more processors, the cryptographic service is forced to implement one or more policies regarding the key, and the one or more policies are the one or more cryptographic operations. The computer-readable storage medium according to any one of Appendix 24-26, which is a determinant of whether or not is executable using the key. 28. The computer-readable storage medium according to any one of Appendix 24 to 27, wherein the request for using the service is a request for performing a storage operation related to a data object. 29. Having the cryptographic service use the key to perform one or more cryptographic operations allows the cryptographic service to select the key from multiple keys stored by the cryptographic service. The computer-readable storage medium according to any one of Appendix 24-28, comprising providing an identifier for the key.

0089FIG. 19 illustrates aspects of an example of the environment 1900 for implementing embodiments that follow various embodiments. As can be understood, a web-based environment is used for explanatory purposes, but different environments may be used as appropriate to implement various embodiments. The environment includes an electronic client device 1902, which can operate to send and receive requests, messages, or information over the appropriate network 1904, and to carry and return information to users of the device. , Can include any suitable device. Examples of such client devices include personal computers, mobile phones, portable messaging devices, laptop computers, set-top boxes, personal digital assistants, electronic book readers and the like. The network may include any suitable network, including an intranet, the Internet, a cellular network, a local area network, or any other such network, or a combination thereof. The components used for such a system may depend, at least in part, on the type of network and / or environment selected. Protocols and components for communicating over such networks are known and are not described in detail herein. Communication over the network may be enabled by wired or wireless connections and combinations thereof. In this embodiment, the network includes the Internet because the environment includes a web server 1906 for receiving requests and providing content in response, but for other networks it may be apparent to those skilled in the art. Alternative devices that serve similar purposes may be used.

0090An exemplary environment includes at least one application server 1908 and datastore 1910. Other elements, processes, or components that can be configured with several application servers, layers, or chains or different, and can interact to perform tasks such as getting data from the appropriate data store. It should be understood that it is possible. As used herein, the term "data store" refers to any device or device combination that can store, access, and read data, which is any standard, distributed. , Or any number of data servers, databases, data storage devices, and data storage media in a cluster environment may be included in any combination. Since the application server is required to perform one or more application aspects for the client device, it handles most of the data access and business logic for the application to integrate with the data store. It may include any suitable hardware and software. The application server can work with the data store to provide access control services and generate content such as text, images, audio, and / or video that is transferred to the user, which is the embodiment. It may be provided to the user by a web server in the form of a hypertext markup language (HTML), an extended markup language (XML), or another suitable structured language. The processing of all requests and responses, as well as the delivery of content between the client device 1902 and the application server 1908, can be processed by the web server. No web and application server is required, as the structural code described herein can be executed on any suitable device or can host the machine as described elsewhere herein. And it should be understood that it is just an example of a component.

0091The data store 1910 may include several separate data tables, databases, or other data storage mechanisms, and media for storing data related to a particular embodiment. For example, the illustrated data store includes a mechanism for storing production data 1912 and user information 1916, which can be used to provide content to the producer. The data store has also been shown to include a mechanism for storing log data 1914, which may be used for reporting, analysis, or other such purposes. Stored in the datastore for page image information and to access the correct information, which may be stored in any of the above mechanisms as appropriate, or in an additional mechanism in the datastore 1910. It should be understood that there can be many other aspects that need to be done. Datastore 1910 can operate to receive instructions from application server 1908 and obtain, update, or otherwise process data in response through the logic associated with it. In one embodiment, the user may submit a search request for a particular type of item. In this case, the data store can access the user information to verify the user's identity and can access the catalog details to obtain information about that type of item. The information can then be returned to the user in the results described on the web page that the user can view through the browser of user device 1902. Information about a particular item of interest can be found on a dedicated page or window in your browser.

0092Each server can typically include an operating system that provides executable program instructions for general management and operation of the server, and typically when executed by the server's processor, the server intends to. It may include a computer-readable storage medium (eg, hard disk, random access memory, read-only memory, etc.) that stores instructions that allow it to perform the function to be performed. Suitable implementations of the server operating system and general functionality are known or commercially available and are readily implemented by those skilled in the art, especially in light of the disclosure herein. In some embodiments, the operating system may be configured or substantiated according to one or more proof systems, such as Level 4 of the Evaluation Guarantee Level (EAL).

0093The environment in one embodiment is a distributed computing environment that utilizes several computer systems and components that are interconnected via communication links using one or more computer networks or direct connections. However, it will be appreciated by those skilled in the art that such systems may work similarly well in systems with fewer or more components than those illustrated in FIG. Let's do it. Therefore, the description of System 1900 in FIG. 19 should be taken as exemplary in nature and not limiting the scope of this disclosure.

0094Various embodiments can also be implemented in a wide variety of operating environments, which in some cases can be used to operate any of a large number of applications, one or more. It may include a user computer, a computing device, or a processing device. The user or client device may be a desktop or laptop computer running a standard operating system, as well as cellular, wireless, and portable devices that can run mobile software and support a number of networking and messaging protocols. It may include any of a number of general purpose personal computers. Such a system may also include a variety of commercially available operating systems as well as several workstations running 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, game consoles, and other devices capable of communicating over the network.

0095Most embodiments include Transmission Control Protocol / Internet Protocol (TCP / IP), Open System-to-System Interconnection (OSI), File Transfer Protocol (FTP), Universal Plug and Play (UpnP). To support communications using any of a variety of commercially available models and protocols, such as Network File System (NFS), Common Internet File System (CIFS), and Apple Talk. Use at least one network that may be familiar to those in the industry. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public exchange telephone network, an infrared network, a wireless network, or any combination thereof.

0096In embodiments that utilize a web server, the web server includes a hypertext transfer protocol (HTTP), a server, an FTP server, a common gateway interface (GCI) server, a data server, a Java server, and a business application server. , Can run either various servers or intermediate tier applications. The server (s) can be written in any programming language such as Java®, C, C #, or C ++, or a scripting language such as Perl, Python, or TCL, and a combination thereof. It is also possible to run a program or script in response to a request from a user device by running one or more web applications that can be implemented as a script or program of. Servers (s) include, but are not limited to, database servers commercially available from Oracle (R), Microsoft (R), Sybase (R), and IBM (R). It can also be included.

0097The environment may include various data stores as well as other memory and storage media as described above. They reside in various locations, local to (and / or reside in) one or more of the computers, or remote from any or all of the computers across the network, such as on storage media. obtain. In a particular set of embodiments, the 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 appropriate. If the system includes computerized devices, each such device may include a hardware element that may be electrically connected via a bus, the element being, for example, at least one central processing unit (CPU). Includes at least one input device (eg, mouse, keyboard, controller, touch screen, or keypad), and at least one output device (eg, display device, printer, or speaker). Such systems include disk drives, optical storage devices, and solid storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc. One or more storage devices may also be included. 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.

0098Such devices may also include computer readable storage media readers, communication devices (eg, modems, network cards (wireless or wired), infrared communication devices, etc.) and working memory, as described above. A computer-readable storage medium reader is a remote, local, fixed, and / or removable storage device and storage medium for containing, storing, transmitting, and reading computer-readable information temporarily and / or more permanently. Can be configured to be connected to or receive a computer-readable storage medium that represents. The system and various devices typically reside in at least one working memory device, including an operating system and application programs such as client applications or web browsers, a number of software applications, modules, services, or other Can contain elements. It should be understood that alternative embodiments may have a number of variations from those described above. For example, custom hardware may also be used and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. In addition, connections to other computing devices, such as network input / output devices, may be used.

0099Storage media and computer-readable media for containing the code or parts of the code are RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read. Stores dedicated memory (CD-ROM), digital versatile disk (DVD), or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or desired information. For storing and / or transmitting information such as computer-readable instructions, data structures, program modules, or other data, including any other medium that can be used for and accessed by system devices. Any suitable medium known or used by those skilled in the art, including but not limited to storage media such as, but not limited to, volatile and non-volatile, removable and non-removable media, implemented in any method or technique. May include. Based on the disclosures and teachings provided herein, one of ordinary skill in the art will understand other methods and techniques for implementing various embodiments.

0100Therefore, specifications and drawings should be viewed in an exemplary sense rather than restrictive. However, it is clear that various modifications and modifications can be made to it without departing from the broader spirit and scope of the invention set forth in the claims.

0101Other variants are within the spirit of the present disclosure. Thus, the disclosed techniques may take various modifications and alternative structures, but their particular exemplary embodiments are shown in the drawings and described in detail above. However, there is no intent to limit the invention to any particular or disclosed form, but conversely, all intent is within the spirit and scope of the invention as defined in the appended claims. It should be understood that it covers modifications, alternative structures, and equivalents.

0102The terms "a," "an," and "the" in the context of describing the disclosed embodiments (particularly in the context of the claims below), as well as similar referents, are herein described. It should be construed as covering both the singular and the plural, unless otherwise indicated or clearly contradictory to the context. The terms "prepare," "have," "include," and "contain" are to be open terms (ie, meaning "include, but not limited to," unless otherwise stated). Should be interpreted. The term "connected" should be construed as being contained, attached, and joined together, partially or wholly, even if there is something intervening. .. The enumeration of the range of values herein is intended to serve solely as a shorthand method for individually pointing to each distinct value within the range, unless otherwise indicated herein. The separate values of are incorporated herein as if they were listed individually herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or where the context clearly does not conflict. The use of any and all examples, or representations of the examples (eg, "etc.") provided herein, is merely intended to better elucidate embodiments of the present invention. Unless otherwise asserted, the scope of the invention is not limited. No expression herein should be construed as indicating a non-claiming element as essential to the practice of the present invention.

0103Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventor to carry out the invention. Modifications of these preferred embodiments may be apparent to those skilled in the art when reading the above description. The inventor anticipates that those skilled in the art will use such modifications as appropriate, and the inventor intends that the invention be practiced differently than specifically described herein. Accordingly, the present invention includes, as permitted by applicable law, all modifications and equivalents of the subject matter listed in the claims attached herein. Moreover, any combination of the above elements in all of those possible variations is encompassed by the present invention unless otherwise indicated herein or otherwise clearly contradicted by context.

0104All references cited herein, including publications, patent applications, and patents, indicate that each reference is incorporated by reference, as if individually and specifically by reference. Incorporated here by reference to the extent that the book describes it in its entirety.