Federated key management

(Cross-reference to related applications) This application claims the priority of U.S. Patent Application No. 13 / 765,209 filed February 12, 2013, the contents of which are incorporated herein by reference in their entirety. Incorporated in. This application is, for all purposes, co-pending US Patent Application No. 13 / 764,944 with the title "AUTOMATIC KEY ROTATION" filed simultaneously with the present specification, and the title "DATA SECURITY SERVICE" with the present specification. US Pat. US Patent Application No. 13 / 764,995 with the title "POLICY ENFORCEMENT WITH ASSOCIATED DATA" pending, US Patent Application No. 13 / with the title "DELAYED DATA ACCESS" pending with the present specification. No. 765,239, the title of the application concurrently with this specification, "DATA SECURITY" U.S. Patent Application No. 13 / 765,265 co-pending "SERVICE" and U.S. Patent Application No. 13 / 765,283 co-pending title "SECURE MANAGEMENT OF INFORMATION USING A SECURITY MODULE" filed concurrently with this specification. All disclosures are incorporated by reference.

Various embodiments according to the present disclosure will 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">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented, and examples of the flow of information between various components of the environment according to at least one embodiment are shown.</figref><figref num="4">An example step of an exemplary process for storing a ciphertext according to at least one embodiment is shown.</figref><figref num="5">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented, and examples of the flow of information between various components of the environment according to at least one embodiment are shown.</figref><figref num="6">An example step of an exemplary process for responding to a request for retrieving data according to at least one embodiment is shown.</figref><figref num="7">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented, and examples of the flow of information between various components of the environment according to at least one embodiment are shown.</figref><figref num="8">An example step of an exemplary process for responding to a request to store data according to at least one embodiment is shown.</figref><figref num="9">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented, and examples of the flow of information between various components of the environment according to at least one embodiment are shown.</figref><figref num="10">An example step of an exemplary process for responding to a request for retrieving 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">Illustrative examples of environments in which the various aspects of the present disclosure can be implemented, and examples of the flow of information between various components of the environment according to at least one embodiment are shown.</figref><figref num="13">An example step of an exemplary process for responding to a request for retrieving data according to at least one embodiment is shown.</figref><figref num="14">An example step of an exemplary process for responding to a request to decrypt data according to at least one embodiment is shown.</figref><figref num="15">An example step of an exemplary process for obtaining decrypted data according to at least one embodiment is shown.</figref><figref num="16">A graphical representation of an example cryptographic service according to at least one embodiment is shown.</figref><figref num="17">An example step of an exemplary process for configuring a policy according to at least one embodiment is shown.</figref><figref num="18">An example step of an exemplary process for performing cryptographic operations while enforcing a policy, according to at least one embodiment, is shown.</figref><figref num="19">An exemplary example of the process for encrypting data according to at least one embodiment is shown.</figref><figref num="20">An exemplary example is provided for encrypting data using a security module according to at least one embodiment.</figref><figref num="21">An exemplary example is provided for encrypting a key used to encrypt data using a security module, according to at least one embodiment.</figref><figref num="22">An exemplary example of the process for enforcing a policy using relevant data, according to at least one embodiment, is shown.</figref><figref num="23">An exemplary example of the process for enforcing a policy using relevant data and security modules according to at least one embodiment is shown.</figref><figref num="24">An exemplary example of a policy phase diagram according to at least one embodiment is shown.</figref><figref num="25">An exemplary example of another phase diagram of a policy that follows at least one embodiment is shown.</figref><figref num="26">An exemplary example of the automatic rotate key process according to at least one embodiment is shown.</figref><figref num="27">An exemplary example of the automatic rotate key process according to at least one embodiment is shown.</figref><figref num="28">An exemplary example of displaying a database that can be used to track key usage, according to at least one embodiment, is shown.</figref><figref num="29">Illustrative examples of environments in which various embodiments can be implemented are shown.</figref><figref num="30">A graphical representation of information that may be associated with a key is shown according to at least one embodiment.</figref><figref num="31">A graphical representation of key access annotations that may be included in association with a request is shown according to at least one embodiment.</figref><figref num="32">An exemplary example of the process for processing a request according to at least one embodiment is shown.</figref><figref num="33">An exemplary example of the process for processing a request according to at least one embodiment is shown.</figref><figref num="34">Illustrate an environment in which various embodiments can be implemented.</figref>

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

The techniques described and proposed herein enable enhanced data security in environments with distributed computing resources. In one example, a distributed computing environment includes one or more data services that can be implemented by appropriate computing resources. The data service may allow various operations to be performed in connection with the data. As an example, a distributed computing environment includes one or more data storage services. The electronic request may be sent to a data storage service to perform a data storage operation. An operation example is an operation for storing data using a data storage service and for acquiring data stored by a data storage service using a data storage service. Data services, such as data storage services, can also perform operations that handle data. For example, in some embodiments, the data storage service can encrypt the data.

Various embodiments of the present disclosure include a distributed computing environment that includes cryptographic services implemented using appropriate computing resources. Cryptographic services can be implemented by a distributed system that receives and responds to electronic requests and performs cryptographic operations such as plaintext encryption and ciphertext decryption. In some embodiments, the cryptographic service manages the key. Upon request to perform a cryptographic operation, the cryptographic service may perform a cryptographic operation using a managed key. For example, a cryptographic service can select the appropriate key to perform a cryptographic operation, perform the cryptographic operation, and provide one or more results of the cryptographic operation in response to a request received. In an alternative configuration, a cryptographic service may generate an envelope key (eg, a session key used to encrypt a particular data item) and return the envelope key to the system that invokes the cryptographic operation of the service. it can. The system can then use its envelope key to perform cryptographic operations.

In some embodiments, the cryptographic service manages the keys of 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 operates as a customer of a computing resource provider. Customers may configure and manipulate resources physically hosted by computing resource providers, both remotely and programmatically. 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. And can perform cryptographic operations. Keys managed by cryptographic services can be securely managed so that other users and / or data services do not have access to their keys. Lack of access to another entity's key by an entity (eg, user, customer, service) means that the entity has no authorized way to obtain the key of another entity, and / or the entity is the key of another entity. It can mean that the system that manages the entity does not have an approved way to use the key at the direction of the entity. For example, a cryptographic service allows another customer to have access to the customer's key (s) for the customer, and the cryptographic service uses the customer's key (s) to perform cryptographic operations. Keys can be managed so that they cannot both be executed. As another example, a cryptographic service may manage keys so that other services, such as data storage services, cannot force cryptographic services to perform cryptographic operations using some or all of the keys. Unauthorized access to the key can be prevented by appropriate security measures, for example, making unauthorized access difficult or impossible. Difficulty is due to inability to perform calculations to gain access and / or fraudulent (eg, infringement of permit certificates, illegal, illegal, and / or otherwise prohibited. Could be due to the need to occur. Systems that follow various embodiments can be configured to ensure an objective measure of non-computational performance for gaining access to keys. Such a measure is, for example, an average for a computer with a given unit of computing power (eg, a specific operation per unit time) to decrypt the encrypted information required for authorized access to the key. Can be measured in terms of the amount of time that will be required.

As mentioned, cryptographic services can 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 send a request to a cryptographic service in order to force the cryptographic service to perform a cryptographic operation. As an example, a customer may send a request to a data storage service to store a data object. The request may indicate that the data object should be encrypted when it is stored. The data storage service communicates the request with the cryptographic service in order to perform the cryptographic operation. The cryptographic operation can be, for example, encryption of 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. Cryptographic operations can be the generation of envelope keys that data storage services can use to encrypt data objects.

Systems that follow various embodiments implement various security measures to provide enhanced data security. For example, in various embodiments, there is a limit to how cryptographic services can use the keys they manage. For example, in some embodiments, the cryptographic service is configured to use only the key corresponding to the customer at the time of proper approval. If a request to use a customer's key is said to arise from the customer (ie, from a computing device operating on behalf of the customer), the cryptographic service will provide the appropriate certificate that the request is owned by the customer. Can be configured to require being electronically (digitally) signed using. If a request to use a customer's key comes from another data service, the cryptographic service must provide proof that the data service has made a signed request to the data service by the customer. It is configured to be. In some embodiments, for example, a data service is configured to acquire and provide a token that acts as a proof of an authenticated customer request. Other security measures can also be incorporated into the configuration of electronic environments, including cryptographic services. For example, in some embodiments, cryptographic services are configured to limit key usage according to context. As an example, a cryptographic service may be configured to use a key for encryption in response to a request from a customer or a data service acting on behalf of the customer. However, cryptographic services can be configured to use only the key for decryption in response to requests from customers (but not from other data services). In this manner, if the data service is compromised, the data service will not allow the cryptographic service to decrypt the data.

Various security measures can be incorporated into cryptographic services and / or their electronic environment. Some security measures may be managed according to configurable policies in some embodiments. As an example, cryptographic services may utilize application programming interfaces (APIs) that allow users to configure policies on keys. The policy on the key can be decisive information about whether the key can be used in a particular situation when processed by a cryptographic service. Policies can, for example, limit the identities of users and / or systems that can direct the use of keys, limit the amount of time that keys can be used, and data on which keys are used to perform cryptographic operations. Can be restricted and other restrictions can be provided. The policy may provide explicit restrictions (eg, who cannot use the key) and / or explicit authorization (eg, who can use the key). In addition, policies can be complexly configured to generally provide conditions when keys are available and when they are not. 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 performed in accordance with the policy.

In various embodiments of the present disclosure, the key may be managed by a cryptographic service with respect to the enforcement of the policy associated with the key. A user of a cryptographic service, such as a customer of a computing resource provider that hosts the cryptographic service, may specify a key policy enforced by the cryptographic service. The policy is who can direct the cryptographic service to use the key, what operations can be performed with the key, under what circumstances the key can be used, and / or Constraints and / or privileges associated with other key usage can be encoded.

In certain embodiments, the data associated with the ciphertext is used to enforce the policy. The data associated with the ciphertext can be data obtained through the use of cryptography, such as Advanced Encryption Standard (AES) mode. For example, the input to a cryptographic algorithm may include plaintext and related data to be encrypted. Cryptographic algorithms can use keys to encrypt plaintext and can provide authentication output, such as a message authentication code (MAC) that allows the determination of whether relevant data has changed. Authentication output can be determined, at least in part, based on relevant data and plaintext.

Policy enforcement may be at least partially based on relevant data. For example, some policies may require the relevant data to have a certain value before the decrypted ciphertext (ie, plaintext) is provided. Authentication output (eg, MAC) can be used to ensure that relevant data has not changed and therefore policy enforcement is performed correctly. The relevant data can be any suitable data, which itself can be explicitly or implicitly specified by the policy. For example, the policy is a decrypted cipher only if the request to decrypt the ciphertext is submitted by a user who has a user identifier encoded in the relevant data used to encrypt the ciphertext. It can be specified that a sentence (plaintext) can be provided. In this mode, if another user requests the decryption of the ciphertext (without impersonating the user with the user identifier), the request will not be fulfilled because it conflicts with the policy. As another example, a policy may state that a decrypted ciphertext can only be provided if the ciphertext is tagged with the specified information. As yet another example, a policy can only provide a decrypted ciphertext if it is tagged with a plaintext hash, a ciphertext hash, or other relevant data equal to a specified value. I can say it clearly. In general, embodiments of the present disclosure allow a wealth of policy enforcement centered on the input or output of a cryptographic algorithm before the output of the cryptographic algorithm is revealed. In some embodiments, the relevant data can itself represent a policy.

The various embodiments of the present disclosure also enable policies centered on key use. For example, in some embodiments, the key is auto-rotated to prevent the key from being used for a sufficient amount of time to allow a successful cryptographic attack that can reveal the key. To prevent the key from being used for a sufficient amount of time to result in a possible security breach, cryptographic services or other systems that utilize the key may track the operations performed with the key. When the key identified by the key identifier (KeyID) is used in the threshold number of operations, the key is retired (eg, unavailable for future cryptographic operations, but available for future decryption operations). ), Can be exchanged for a new key identified by the KeyID. In this mode, new keys are generated in a timely manner. Moreover, various embodiments of the present disclosure perform such key rotation in a transparent manner with respect to a particular entity. As an example, a customer or other entity of a computing resource provider may submit a request to a cryptographic service to perform an operation using the key identified by the KeyID. Cryptographic services can perform key rotation independently of any request from an entity to perform key rotation. From the customer's or other entity's point of view, the request may still be served using the KeyID without any reprogramming or other reconfiguration required due to the key being retired and replaced with a new key.

In some embodiments, a plurality of systems supporting cryptography or other services are used at the same time to have access to a key and perform a request to perform a cryptographic operation. For example, cryptographic services may utilize clusters of security modules, some of which redundantly store one or more keys. The service may assign operations to security modules and maintain its own counters. When a security module uses that assignment (for example, using a key to perform an assigned number of operations), the service checks if the key is still available or if the key should be retired. Can be done. Note that a security module (or other computer system) can be configured to perform multiple types of key-based operations such as encryption, decryption, and digital signature generation. In some embodiments, not all types of operations force the security module to use some of the operation assignments. For example, a decryption operation may not result in the assigned operation being used, while an encryption operation may result in the assigned operation being used. In general, in various embodiments, cryptographic operations that result in the generation of new information (eg, ciphertext and / or digital signatures) can result in the assigned operations being used, while the new information Cryptographic operations that do not result in generation may not result in the assigned operations being used. Moreover, different types of operations can result in different numbers of cryptographic operations being performed. As an example, plaintext encryption can vary in the amount of cryptographic operations required, at least in part, based on the size of the plaintext. For example, by using a block cipher, the assigned cryptographic operations can be used for each block of generated ciphertext.

If the total number of operations available for one key is still available, the service may assign additional operations to the security module. If the key should be retired (for example, because the counter indicates so), the service causes a security module that redundantly stores the key to retire the key and replace it with a new key. Here the new key can be generated or acquired in another way by one security module and safely passed to the rest of the security modules. In some embodiments, other security modules instead run out of their assigned operations under the old key. If the security module does not work properly, becomes inoperable, is intentionally taken offline (for example, for maintenance), and / or the operation it performed using one or more keys. If the service does not provide information about the number and the performance of the cryptographic operation becomes unavailable in another way, the service may treat its non-usefulness as a use of its allocation. For example, if a security module is assigned 1 million operations for each key in a set of keys and the security module becomes inoperable, the service will provide 100 for each key in the set of keys. It can behave as if it had performed a million operations. For example, if the service can assign additional operations to a security module or another security module and adjust the counters accordingly, and / or the corresponding counters indicate that they need to be replaced. One or more may be retired and exchanged.

The embodiments of the present disclosure also enable enhanced data security with annotation and / or federated key management techniques. In some embodiments, the request submitted to a service (such as a cryptographic service or other data service) may include annotations (also referred to as key access annotations) that contain information that allows policy enforcement. Or it may be associated with it separately. In certain embodiments, the key access annotation must meet one or more conditions before the corresponding request can be fulfilled. In some embodiments, one or more conditions are that the annotation is digitally signed using the key associated with the KeyID, which KeyID identifies a different key that can be used to fulfill the request. Including. The presence of a valid digital signature can indicate that the information in the annotation has not been altered, and can also prove possession of the key used to generate the digital signature.

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

The embodiments of the present disclosure also enable enhanced data security by forced delay before certain types of requirements are fulfilled. For example, in some embodiments, decoding certain data requires a delay before the plaintext is provided in response to the corresponding request. During the delay, various actions may be taken to notify stakeholders of the pending request to decrypt the information. In this context, interested parties (eg, the person responsible for compliance with the organization, or anyone else who has the authority to allow the plaintext to be provided) are given the opportunity to cancel the request before the plaintext is provided. Be done. In various embodiments, the request is easily canceled. For example, the requirement to cancel a request may be less stringent than the requirement to fulfill the request. In this context, unauthorized data breaches can be easily detected and / or prevented.

FIG. 1 is an exemplary Figure 100 illustrating various embodiments of the present disclosure. In certain embodiments, a cryptographic service performs a cryptographic operation that may include one or more computational applications that follow one or more cryptographic algorithms. As illustrated in Figure 1, a cryptographic service allows a user or service to generate plaintext from a ciphertext. In one configuration example, cryptographic services can be used to encrypt / decrypt keys, and these keys can be used to encrypt / decrypt data, such as data stored within a data storage service. can do. For example, a cryptographic service may receive 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, returns the decrypted key to the service, and uses the decrypted key to ciphertext. Plaintext can be generated from. 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 example, the ciphertext is one of the electronic requests to the cryptographic service from an authorized entity that can be a customer of the compute resource provider operating the cryptographic service and / or another service of the compute resource provider. Can be provided to cryptographic services as a department. The cryptographic service illustrated in Figure 1 may utilize one or more cryptographically powerful algorithms to encrypt data. Such cryptographically powerful algorithms include, for example, Advanced Encryption Standard (AES), Blowfish, and Data Encryption Standard. It can be either Standard) (DES), Triple DES, Serpent, or Twofish, and can be either asymmetrical or symmetric, depending on the particular implementation chosen. In general, cryptographic services may utilize any encryption and / or decryption algorithm (encryption), or a combination of algorithms that utilize the data managed by the cryptographic service.

Cryptographic services can be implemented in a variety of ways, as described in more detail below. In certain embodiments, 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, a cryptographic service 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, a computer system can be a distributed system. In certain embodiments, the ciphertext is information encrypted using a cryptographic algorithm. In the example of FIG. 1, the ciphertext is plaintext in an encrypted form. Plaintext can be arbitrary information and its name does not include textual text, while plaintext and ciphertext can be information encoded in any suitable form, not necessarily textual information, but textual information. May include. For example, as illustrated in FIG. 1, plaintext and ciphertext include a sequence of bits. Plaintext and ciphertext can also be represented in other ways, and in general in any manner in which encryption and decryption can be performed by a computer system.

FIG. 2 shows an exemplary example of an environment 200 in which a cryptographic service as illustrated in FIG. 1 can be implemented. In 200 environments, various components work together to provide secure data-related services. In this particular example, the environment 200 includes a cryptographic service, an authentication service, a data service front end, and a data service back end storage system. In certain embodiments, the cryptographic service receives plaintext from the data service front end and provides the ciphertext in its place, or allows the service to perform cryptographic operations using an envelope key. Configured within Environment 200 to perform cryptographic operations, such as by providing an envelope key to a service. Cryptographic services perform additional functions, such as converting plaintext to ciphertext and securely storing keys for performing cryptographic operations such as decrypting ciphertext into plaintext, as described below. obtain. Cryptographic services also perform operations associated with policy enforcement, such as by enforcing policies associated with the keys 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 sent over a network from various users. The request can be a request to perform an operation in connection with 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.

An 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 instead receive information indicating whether the user request is authentic. The determination of whether a user request is authentic can be performed in any preferred manner, and the mode in which authentication is performed can vary between various embodiments. For example, in some embodiments, the user digitally signs a message sent to the data service front end. The digital signature can be generated using confidential information available to both the authentication entity (eg, the user) and the authentication service (eg, the private key of the key pair associated with the user). The request and the signature for the request may be provided to an authentication service that can use the confidential information to calculate the reference signature for comparison with the received signature to determine if the request is authentic. If the request is authentic, the authentication service may provide other services, such as cryptographic services, with information that the data service front end can use to prove that the request is authentic. Allows 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 are valid for a particular amount of time. In one example, the digital signature and / or token is generated at least partially based on a function (eg, hash-based message authentication code) that considers the input as a time stamp, which is included with the digital signature and / or token for verification. To. The entity verifying the submitted digital signature and / or token checks that the time stamp received is sufficiently up-to-date (eg, within the specified amount of time from the current time) and receives it. Can generate a reference signature / token to use for the time stamp. Authentication can fail if the timestamp used to generate the submitted digital signature / token is not sufficiently up-to-date and / or if the submitted signature / token does not match the reference signature / token. .. In this manner, when the electronic signature is infringed, the electronic signature is valid only for a short period of time, thus limiting the potential damage caused by the infringement. Note that other methods of verifying authenticity are also considered to be within the scope of this disclosure.

A data service backend storage system in one embodiment is a computer system that stores data according to a request received via the data service front end. As discussed in more detail below, data service backend storage systems 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 stored in the data service back end storage system should be encrypted. 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 accessible to some or all systems in Environment 200. The data can be encoded by a cryptographic service for storage within the data service back-end storage system, and / or, in some embodiments, the data is separate, such as a user system or a data service front-end system. The system can be encrypted using a key decrypted by a cryptographic service. Examples of various methods that Environment 200 can operate to encrypt data are provided below.

Numerous 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, one data storage service may provide active access to the data, the data storage service performing the data storage service in a synchronous manner (eg, a request to retrieve the data is synchronized with the retrieved data). You can receive a response). Another data storage service may provide an archive data storage service. Such archive data storage services may utilize asynchronous request processing. For example, a request to retrieve data may not receive a synchronization response containing the retrieved data. Rather, the archived data storage service may require a second request to be submitted to acquire the acquired data when it is ready to provide the acquired data. As another example, the environment 200 may include a weighing service that receives information from a cryptographic service (and / or other service) and uses that information to create a billing record. Billing records may be used to charge customers for the use of cryptographic services (and / or other services). In addition, information from cryptographic services can provide guidance on how much to charge. For example, in some examples, a customer may be offered an invoice for the use of cryptographic services. In another example, the fee for using the cryptographic service may be matched to the fee for using other services, such as a data service that uses the cryptographic service as part of its operation. Use can be weighed and billed in a variety of ways, including per-operation, per-period, and / or other methods. Other data services may also be included in Environment 200 (or any other environment described herein).

In 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 via a user device (eg, a computer) not illustrated in the figure. In addition, the user depicted in Figure 2 (and other parts of the figure) may also represent non-human entities. For example, automated processing performed on a computer system may interact with a data service front end as described herein. As an example, the entity represented by the user in Figure 2 uses the data service front end to store data in the data service back end storage system as part of its operation, and / Or it can be a server that gets from a data service backend storage system. As yet another example, the entity represented by the user in FIG. 2 can be an entity provided as a service of a computing resource provider that operates 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 variants, including other environmental variants described below, are also considered to be within the scope of this disclosure.

For example, FIG. 3 shows an exemplary example of an environment 300 in which various embodiments of the present disclosure can 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, but such a network is not illustrated in the figure. In the example environment 300 illustrated in FIG. 3, arrows representing the flow of information are provided. In this example, the user sends a PUT request to the data service front end. A PUT request can be a request to store the specified data in a data service backend storage system. In response to a PUT request, the data service front end submits the request in such a way that the PUT request is authentic, that is, the user can perform the requested operation in accordance with the authentication policy implemented by the system. , Can be determined.

FIG. 3 illustrates an exemplary example of how such an authentication decision can be made. In this particular example, 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 the authentication certificate to the data service front end. The certificate of authentication can be an electronic token, or other information that can be used independently by another service, such as a cryptographic service, to determine that a genuine request has been received. In one exemplary example, the PUT request is sent with a signature for the PUT request. The PUT request and its signature are provided via an authentication service that 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 provide authentication proof accordingly. Determining whether a PUT request is authentic also includes one or more operations related to policy enforcement. For example, if the signature is valid but the policy separately indicates that the PUT request should not be completed (for example, the request was submitted during a time prohibited by the policy), the authentication service means that the request is not authentic. Can provide information indicating. (However, it should be noted that such policy enforcement may be performed by other components of the environment 300.) The authentication service signs, such as by using the authentication service and a key shared by the user. Can be generated. The certificate of authentication can be, as mentioned, information that another service, such as a cryptographic service, can independently verify that the request is authentic. For example, using the example of a cryptographic service illustrated in Figure 3, the authentication certificate is at least partially based on a key shared by both the cryptographic service and the cryptographic service, such as a key that is inaccessible to other services. Can be generated.

As illustrated in Figure 3, when the data service front end receives the certificate from the authentication service, it provides plaintext and the certificate to the crypto service. Plaintext and credentials are provided to cryptographic services according to API calls or other electronic requests (eg, Encrypt API calls). Cryptographic services can analyze the credentials to decide whether to encrypt the plaintext.

Note that additional information may be provided to the cryptographic service. For example, the identifier of the key used to encrypt the plaintext can be provided as an input parameter to the API call from the data service front end (instead, it may have received the identifier from the user). However, keep in mind that the identifier may not be sent to the cryptographic service. For example, in various embodiments, it may be possible to separately determine which key to use to encrypt the plaintext. For example, the information sent from the data service front end to the cryptographic service may be information associated with the user, such as the identifier of the customer who submitted the PUT request on behalf of the user, and / or the identifier of the organization associated with the user. Can include. Such information can be used by cryptographic services to determine the default key used. In other words, the key can be implicitly specified by the information available to determine 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 and may provide an identifier for the generated or selected key that will be used later. Another example of an API parameter could be an identifier for the master key for the customer account on which the encryption operation is performed.

As illustrated in Figure 3, a cryptographic service can perform one or more cryptographic operations if the credentials are sufficient for the cryptographic service to encrypt the plaintext. In certain embodiments, one or more cryptographic operations can include an operation for generating an envelope key used to encrypt plaintext. The envelope key can be a randomly generated symmetric key, or a private key in a key pair. After the envelope key is generated, the cryptographic service can encrypt the envelope key with the master key specified in the API call and permanently remember the encrypted envelope key (eg,). (By storing the encrypted key in a storage service or some other persistent storage), or can be destroyed. In addition, the cryptographic service can send a plaintext version of the envelope key as well as an encrypted envelope key to the data service front end. 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), and the envelope key is the master used to encrypt the envelope key. It can be stored in persistent storage in association with the identifier for the key. In addition, the data service can discard the plaintext version of the envelope key. Thus, in certain embodiments, the data service can no longer decrypt the ciphertext after destroying the plaintext version of the envelope key.

In alternative embodiments, cryptographic operations can be involved in 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 according to its operation. Other information may also be sent from the data service front end to the data service back end storage system. For example, the identifier of the key used to encrypt the plaintext and generate the ciphertext may be provided by the data service backend storage system along with the ciphertext for storage. Other information may also be provided, such as metadata that identifies the user and / or the user's organization.

As with all environments described herein, many variations are considered to be within the scope of this disclosure. For example, the flow of information between the various components of Environment 300 may differ from what is shown. For example, the flow of information 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). Can be provided directly to its destination and / or via other intermediate components of the environment 300 (not necessarily included in the figure). As another example, a PUT request (and GET request) is provided for exemplary purposes. However, any suitable requirement for performing the described operations may be used.

FIG. 4 shows an exemplary example of a process 400 that can be used to store data within a data storage service according to an embodiment. Process 400 can be performed, 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) is the control of one or more computer systems consisting of executable instructions. Code that can be executed under and that is executed together on one or more processors, either by hardware or by a combination (eg, executable instructions, one or more computer programs, or one or more applications). ) Can be implemented. 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. Computer-readable storage media can be non-temporary.

As 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. Upon receiving the PUT request, process 400 may include submitting an authentication request 404. For example, a system running within process 400 submits an authentication request (eg, via a well-configured API call) to a separate authentication service as described above in connection with Figure 3. obtain. Similarly, a data service front end that performs its own authentication may submit an authentication request to the authentication module implemented by the data service front end. In general, the certification request can be submitted in any suitable manner according to various embodiments.

When an authentication request is submitted, an authentication response is received by the entity to which the authentication request was submitted 406. For example, referring to FIG. 3, an authentication service may provide a response to a data service front end that includes proof of authentication for use by another service. Other information may also be sent, such as an indication of successful authentication. A decision can be made as to whether the request is authentic 408. The authenticity of a request can depend on one or more factors that are checked, such as by an entity such as an authentication service, or a combination of entities that perform such checks together. Authenticity means, for example, providing a valid certificate that requires a request (eg, a digital signature generated by a private key shared by the entity being checked), and / or that the policy fulfills the request. May need to be allowed. From the point of view of the system that submits the authentication request and receives the authentication response, the authenticity can depend on the received authentication response. Thus, in certain embodiments, the determination 408 of whether a request is authentic can be performed, at least in part, on the received authentication response. For example, if the authentication was not authentic, the authentication response would indicate so and a decision 408 could be made accordingly. Similarly, the response can implicitly indicate that the authentication request is authentic, such as by not including the information that would be included if the request was not authentic. If the PUT request is determined to be non-authentic 408, the PUT request can be rejected 410. Rejection of a PUT request can be performed in any preferred manner and can depend on various embodiments in which process 400 is running. For example, rejecting a PUT request 410 may include sending a message to the user who submitted the PUT request. The message may indicate that the request has been rejected. Rejecting a request can also be used to determine a solution to any problem that results in an incorrect digital signature or an incorrect or unapproved PUT request, etc.

If the PUT request is determined to be genuine and approved 408, in one embodiment process 400 comprises performing one or more cryptographic operations that result in plaintext encryption 412. For example, a request (eg, a well-configured API call) is submitted to a cryptographic service and provided with a key used to perform one or more cryptographic operations. A cryptographic service can perform cryptographic operations (eg, encrypt plaintext to provide ciphertext, or encrypt plaintext, because the request provided to the cryptographic service can be provided with proof that the PUT request is authentic. You can independently decide whether to perform (to generate an envelope key that can be used for). 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 a cryptographic service receives a request from a data service front end, the cryptographic service can 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 using cryptographic services to provide an additional layer of security. Cryptographic services generate a key or acquire it in another way, encrypt the acquired key, or acquire a separately encrypted key (eg, from memory), and upon request, the acquired key and It may provide an encrypted acquired key. The acquired key can be encrypted using the key identified in the request to the cryptographic service. The plaintext can be encrypted using the acquired key, and after encrypting the plaintext, the acquired key can be destroyed (eg, irrevocably deleted from memory). In an alternative embodiment, a system performing process 400 may generate or otherwise acquire a key used to perform one or more cryptographic operations and encrypt the acquired key for encryption. Can be provided to the service

In some embodiments, performing one or more cryptographic operations can result in the generation of ciphertext. Ciphertext generated as a result of one or more cryptographic operations can be stored for subsequent retrieval 414. As mentioned above, the ciphertext memory may include a memory of additional information that allows subsequent decryption of the ciphertext. For example, the ciphertext can be stored with the identifier of the key used to encrypt the plaintext into the ciphertext, so the key with the identifier can be used later to decrypt the ciphertext and obtain the plaintext. .. Ciphertext storage can also be performed in any preferred manner. For example, ciphertext storage can be performed by a data service backend storage system, as described above.

FIG. 5 therefore shows an exemplary example of the environment 500 and a flow of information exemplifying how plaintext can be obtained. Environment 500 in this example includes an authentication service, a cryptographic service, a data service front end, and a data service back end storage system. The authentication service, cryptographic service, data service front end, and data service back end storage system can be such a system. As illustrated in Figure 5, the data service front end is configured to receive a GET request from the user and provide plaintext instead. To do this, the data service front end can also be configured to submit an authentication request to the authentication service so that the authentication service itself provides the authentication certificate to the data service front end, if appropriate. Can be configured. The data service front end can also be configured to send a request to a cryptographic service, causing the cryptographic service to perform one or more cryptographic operations related to decrypting the data. In embodiments where an envelope key is used, the data service issues a request (eg, an API call) to an encrypted envelope key (or identifier for an encrypted envelope key) certificate, and an envelope for the cryptographic service. It can be submitted to a cryptographic service that contains or specifies the identifier of the master key used to encrypt the key. The cryptographic service can determine if the certificate is sufficient to allow the operation, and if the certificate is sufficient, decrypt the envelope key. The decrypted envelope key can be sent back to the data service, which can use the key to decrypt the encrypted plaintext. The data service can then discard the decrypted plaintext key.

In 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. The cryptographic service accordingly determines whether the credential is sufficient to allow the decryption of the ciphertext, and if the credential is sufficient, the appropriate key (to the cryptographic service by the data service front end). Can be configured to decrypt the ciphertext 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).

FIG. 6 shows an exemplary example of process 600 that can be used to obtain plaintext according to various embodiments. Process 600 can be performed, for example, by the data service front-end system (data service front-end) illustrated above in connection with FIG. 5, while process 600 and its variants can be performed by any suitable system. .. In certain embodiments, process 600 comprises receiving a GET request (or other suitable request) from the user 602. 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 manner as described above 604. The authentication response can be received accordingly. A decision as to whether a GET request is authentic can be made, at least in part, based on the authentication response received 608. If it is determined that the GET request is not authentic 608, process 600 may include 610 rejecting a request that may be executed in different ways according to different embodiments, as described above.

If the GET request is determined to be authentic 608, process 600 may include retrieving the ciphertext from memory. Obtaining the ciphertext from memory 612 can be performed in any suitable manner. For example, referring to Environment 500 described above in connection with Figure 5, the data service front end may submit a request for the ciphertext to the data service backend storage system and receive the ciphertext accordingly. Can be done. In general, the ciphertext can be obtained from memory in any suitable manner. Upon receiving the ciphertext, process 600 may include performing one or more operations related to decrypting the ciphertext 614. For example, in certain embodiments, the data storage service may send a request to the cryptographic service to perform one or more cryptographic operations associated with decrypting the ciphertext. In one configuration example, the data service is used by the cryptographic service to encrypt the encrypted envelope key (or encrypted envelope key identifier) authentication and the envelope key to the cryptographic service. You can send API calls that include the master key identifier. The cryptographic service can determine if the certificate is sufficient to allow the operation, and if the certificate is sufficient, decrypt the envelope key. The decrypted envelope key can be sent back to the data service, which can use the key to decrypt the encrypted plaintext.

In another configuration, the ciphertext may be provided to a cryptographic service, such as the cryptographic service described above in connection with FIG. Other information, such as proof of authentication that the cryptographic service can use to determine whether to decrypt the ciphertext, may also be provided to the cryptographic service. In addition, 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 may be implicitly shown to the cryptographic service. For example, the cryptographic service may use the default key associated with the customer indicated for the cryptographic service. In general, any mode can be used that allows the cryptographic service to determine which key to use to decrypt the ciphertext.

As illustrated in FIG. 6, after the ciphertext has been decrypted, process 600 may include 616 providing a response to the GET request. 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, plaintext can be the key used to decrypt other encrypted information that is later provided in response to a 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.

As mentioned, various embodiments of the present disclosure allow data to be stored by a data storage service in various ways. FIG. 7 shows an exemplary example of the environment 700 with arrows showing the flow of information according to such an embodiment. As illustrated in FIG. 7, the environment 700 includes an authentication service, a cryptographic service, a data service front end, and a data service back end storage system, as described above. In this particular example, the data service front end is a computer system configured to receive PUT requests from various users. The PUT request may include or specify a data object stored by the data service backend storage system. The PUT request can also specify a key identifier for the key used to encrypt the data object. The data service front end also provides a certificate of authentication to an operable cryptographic service to receive the key and key identifier, as described above, with the key encrypted by the key identified by the key identifier accordingly. It can also be configured to interact with an authentication service to provide. The data service front end can then result in storage within the data service back end storage system. The data that can be stored can include data objects that are encrypted by the key. The data that can be stored can also include a key that is encrypted by the key identified by the key identifier. As discussed elsewhere in this specification, encrypted data objects and encrypted keys can be stored within different services.

As 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 example, the data service front end is configured to provide a data object that is encrypted under a key, and a key that is encrypted under another key that has a KeyID. Note that curly braces are used to represent encryption for illustrative purposes. Specifically, the information in curly braces is the information that is encrypted under the key specified by the subscript. For example, {Data Object}_KeyIndicates that the data "Data Object" is encrypted under the key "Key". Key identifiers can also appear in subscripts using this curly braces notation. When a key identifier appears in subscript, the information in curly braces is encrypted under the key identified by that key identifier. For example, {Data Object}_KeyIDIndicates that the data object "Data Object" is encrypted under the key identified by the key identifier "KeyID". Similarly, {Key}_KeyIDIndicates that the key "Key" is encrypted under the key identified by the identifier "KeyID". In other words, the present disclosure uses both keys and key identifiers in subscripts, and the meaning of the subscripts should be clear from the context. The ciphertext may contain additional metadata that can be used to determine the identity of the associated decryption key.

FIG. 8 shows an exemplary example of a 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 may be performed by any suitable system, such as by the data services front-end system described above in connection with FIG. In certain embodiments, process 800 comprises receiving a PUT request for a data object 802. Receiving a PUT request for a data object can be performed in any preferred manner, as described above. Note that the data object can be received in connection with the request or can be received from another service. For example, the request may include an identifier for a data object that 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 806 received can be used to determine if the PUT request is a genuine request 808. If the PUT request is determined to be non-authentic 808, process 800 may include 810 to reject the request as described above. If the PUT request is determined to be authentic 808, process 800 may include acquiring a key identifier (KeyID) such as a keyID for the master key used to encrypt the envelope key 812. Acquiring the KeyID 812 can be performed in any preferred manner, and the mode in which the KeyID is acquired can vary according to various embodiments. For example, as illustrated in Figure 7, the PUT request can specify a KeyID. As another example, a user's identity, or an identity that is otherwise associated with the user, can be used to obtain an identifier or default key. As another example, the ciphertext may provide an indication of the associated key ID. Yet another example is one or more

In certain embodiments, process 800 also includes generating a key, such as an envelope key 814. Key generation can be performed in any preferred manner, for example, by a cryptographic service or a service that requests a cryptographic operation from a cryptographic service (eg, a data storage service). For example, a key can be generated using a key derivation function with the appropriate input to the key derivation function. Examples of key derivation functions are KDF1 defined in IEEE Std 1363 2000, key derivation function defined in ANSI X9.42, and HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) specified in RFC 5869. Includes HMAC-based key derivation functions such as. As another example, the key can be a random or pseudo-random number generator, a hardware entropy source, or the National Institute of Standards and Technology Special Publication (NIST). Can be generated by a deterministic random bit generator as specified by SP) 800-90A. Note that while Figure 8 shows process 800 involving generating a key 814, the key can be obtained in other ways, such as by retrieving from memory. In other words, the key may be pre-generated.

Continuing with the process 800 illustrated in FIG. 8, in one embodiment the process 800 includes 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 can provide the data service with a key, a KeyID, and an encrypted copy of the key. For example, referring to Figure 7, the data service front end has a KeyID for the envelope key, and the master key used to encrypt the envelope key from the cryptographic service, any other association such as authentication. Can be received with information. 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 destroyed, 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 send 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 can provide a key and a Key ID to a cryptographic service. For example, the data service front end may send the envelope key and the KeyID for the master key used to encrypt the envelope key to the cryptographic service along with any relevant information such as credentials. A plaintext copy of the encryption key can then be used to encrypt the data object. The service can destroy the plaintext copy of the encryption key, and the encrypted data object as well as the encrypted key can then be stored. For example, referring to FIG. 7, the data service front end may send an encrypted data object and an encrypted key to the data service back end storage system for storage.

Encrypted data objects and encrypted envelope keys can be stored without a plaintext version of the key, i.e. plaintext keys have no access to the data service backend storage system and one or more other systems. It may be possible. 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 accessible only to cryptographic services. In some other embodiments, this can be achieved by storing the master key within the hardware or other security module, or in another manner under the protection of the hardware or other security module. it can. In some embodiments, the memory location that stores the plaintext envelope key (eg, the memory of the data service) may be allowed to be overwritten, or the memory location that stores the key is the key to the data service front end. Can be intentionally overwritten to make access to. As another example, the plaintext envelope key can be kept in volatile memory, which eventually ceases to store the key. In this aspect, the envelope key is computationally infeasible, such as when it is decrypted using the key identified by the KeyID, or otherwise, by decrypting the key without the key identified by the KeyID. It is accessible only if it is acquired in a fraudulent manner, which may be possible. In other words, the key identified by the KeyID is required for authorized access to the key on which the data object is encrypted. Thus, decrypting a data object requires access to a key, which can only be obtained by decryption using the key identified by the KeyID, or by any other method that is not computationally feasible. So if the data service backend storage system in Figure 7 is compromised, such

As mentioned, various embodiments of the present disclosure allow the user to both store data objects and obtain them in a secure manner. FIG. 9 therefore illustrates an exemplary example of an environment 900 that can be used to acquire data objects from memory. 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 accordingly. To provide data objects in response, the data storage front-end system in this embodiment is configured to interact with authentication services, cryptographic services, and data service back-end storage systems, as illustrated in FIG. Will be done. 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 example, the data service front end is configured to provide the cryptographic service with a key and credential that is encrypted by the key identified by the KeyID, and the cryptographic service is at least partially based on the credential. It is operable to decide whether to provide the key, and when it is decided to provide the key, it provides the key to the data service front end. The data service front end can also be configured to provide other information, such as a Key ID, to a cryptographic service. However, in some embodiments, the KeyID may be implicitly shown to the cryptographic service, such as by association with other information provided to the cryptographic service. In some embodiments, the user is a data service user. Also note that the Key ID is provided to the data service front end in connection with submitting the request to the loan end. Also, as illustrated in FIG. 9, the data service front end in certain embodiments requests a data object from the data service back end storage system, and a key-encrypted data object and a KeyID accordingly. It is configured to receive a key that is encrypted by the key identified by. In some embodiments, the cryptographic service may be manipulated to refuse to perform decryption of ungenerated ciphertext using the key associated with the specified KeyID.

In certain embodiments, the data service front end is configured to decrypt a data object using a key received from a cryptographic service and provide the decrypted data object to the user. FIG. 10 therefore illustrates an exemplary example of Process 1000 that can be used to provide objects decrypted according to various embodiments. Process 1000 can be performed by any suitable system, such as a data service front-end system as described in connection with FIG. In certain embodiments, process 1000 comprises receiving a GET request for a data object 1002. Receiving a GET request for a data object can be performed in any preferred manner as described above in connection with 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. Process 1000 therefore, in certain embodiments, includes submitting an authentication request to the authentication system 1004 and receiving an authentication response 1006, similar to the other processes described herein. 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 in 1008 to determine if a GET request is authentic. If the GET request is determined to be non-authentic 1008, process 1000 in certain embodiments comprises rejecting the request 1010. However, if the GET request is determined to be authentic 1008, the process 1000 in one embodiment comprises retrieving the encrypted data object and the encrypted key from memory 1012. For example, a data service front-end system may obtain an encrypted data object and an encrypted key from the data service back-end storage system illustrated above in connection with FIG.

In certain embodiments, process 1000 comprises providing an encrypted envelope key to a cryptographic service 1014. Providing an encrypted envelope key to a cryptographic service 1014 is a certificate of authentication that can be performed in any preferred manner and allows the cryptographic service to determine whether to decrypt the encrypted key. Etc., can be provided with other information. 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. It may include providing the key identifier required for the approved decryption of the encrypted envelope key. As mentioned above, however, the key can be implicitly identified. The cryptographic service can therefore decrypt the encrypted key by choosing the appropriate key. Thus, in certain embodiments, process 1000 comprises receiving the decrypted envelope key from a cryptographic service 1016. For example, if the cryptographic service determines that the certificate is valid and / or the decryption of the encryption is acceptable according to any applicable policy, the cryptographic service will give the decrypted key to the data object. It can be provided to the system to be decrypted. The data object can then be decrypted using the decrypted envelope key 1018. The decrypted data object can then be provided to the requester, such as the user or other system that submitted the GET request 1020.

In many cases, it is desirable for the user (ie, the device that typically utilizes the cryptographic service) to interact directly with the cryptographic service. FIG. 11 therefore illustrates 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. Authentication services, data service frontends, and data service backend storage systems can be as described above. For example, a data service front end may be configured to receive and respond to requests from users, as illustrated in FIG. 11, over a suitable network. As part of responding to a request from a user over the network, the data service front end also determines if the user request is authentic and / or to enforce the policy for that request. , Can also be configured to interact with the authentication service. The data service front end can 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 retrieve the data from the data service backend storage system. As mentioned above, other requests such as a request to delete the data stored in the data service backend storage system, a request to update the data stored in the data service backend storage system, etc. , Can be used according to various embodiments.

In the particular example of FIG. 11, in environment 1100, the cryptographic service includes a cryptographic service front end and a data service back end. Like the data service front end, the 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 a convenient manner as described above. Note that the cryptographic service frontend and the data service frontend can interact with the same authentication service, while 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.

The cryptographic service frontend may, in certain embodiments, be 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 can be used by a user to encrypt plaintext 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 examples are also provided below.

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

In addition, as with all environments exemplified herein, additional front-end systems allow users and data service front-ends and cryptographic service front-ends and possibly other fronts to coordinate actions between systems. It can be logically placed between it and the end system. 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 request that a data object be encrypted and stored, and the front-end system responds to that request through appropriate interaction with the cryptographic service front-end and the data service front-end. However, from the user's point of view, such things can be done with a single request. Other variants are also within the scope of this disclosure.

FIG. 12 shows an exemplary example of an environment 1200 that can be used to implement the various embodiments of the present disclosure. In FIG. 12, the environment 1200 is configured to allow the user to store the ciphertext in the 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 systems as described above 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 enforce policies on user requests. The data service front end may be configured to submit an authentication request to the authentication service and receive an authentication certificate accordingly as part of the response to the request. Upon successful authentication, the data service front end retrieves encrypted and possibly unencrypted data objects from the data service back-end storage system that may later be provided to the user. It may be further configured to interact with the end storage system.

As illustrated in FIG. 12, the cryptographic service front end is also configured to provide an authentication request to the authentication service and receive the authentication certificate accordingly. Credentials can be used to obtain services from cryptographic service backends. For example, a cryptographic service frontend may be configured to provide a ciphertext along 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 its place. obtain. As illustrated in Figure 12, the ciphertext can be an encrypted key, and the cryptographic service backend decrypts the encrypted key and uses the decrypted key, which is the plaintext key, as the plaintext key. Can be provided to a cryptographic service front end that is further configured to provide to the user. The user can then use that key to decrypt the encrypted data object received from the data service front end, or within the user's domain (eg, in a data center or computer system operated or controlled by the user). ) Can decrypt the encrypted data object. In this example, 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. Although illustrated as a single request in Figure 11, separate requests may be made for both the data object and the key. As illustrated in FIG. 11, the data service front end acquires an encrypted data object and an encrypted key from the data service back end storage system, and the encrypted data object and the encrypted data are encrypted. The key may be provided to the user.

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 that is encrypted under a key and a key that is encrypted by another key identified by a key identifier provided to the user. Further levels of encryption can also be used. For example, a data object can be encrypted under a key that is only accessible to the user (and / or inaccessible by other components of the environment 1200). The key used to encrypt a data object can also be encrypted under a key that is only accessible to the user. In this example, unauthorized access to the components of environment 1200 (user absent) still requires decryption to allow access to the user's key, thus providing access to the unencrypted content of the data object. Still not offered.

As another example, in the environment 1200 illustrated in FIG. 12, the data service front-end and data service back-end storage systems do not have access to the keys required to decrypt the encrypted data. Has no access to plaintext data stored by the data service backend storage system. However, in some embodiments, access may be granted to the data service front end and / or data service back end storage system. For example, in certain embodiments, a data service front end acquires encrypted data, decrypts the encrypted data, and uses the decrypted data for a particular purpose (eg, indexing). Temporary access to the key may then be provided to the data service front end to allow access to the decrypted data to be deleted or otherwise lost. Such actions may be controlled by the policies enforced by the data services front end and / or cryptographic services and may require user approval.

FIG. 13 illustrates an exemplary example of process 1300 that can be used to obtain encrypted data objects and encrypted keys from a data service backend storage system or the like as described above. Process 1300 may be performed, for example, by the data service front-end system described above in connection with FIG. In certain embodiments, process 1300 comprises receiving a GET request for an encrypted data object 1302. Receiving a GET request can be performed in any preferred 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 a certification request 1304 and receiving a certification response 1306 can be performed in any suitable manner as described above. The authentication response can be used for 1308 to determine if the GET request is authentic. If it is determined that the GET request is not authentic 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 authentic 1308, process 1300 is an encrypted data object that can be used to decrypt the encrypted data object when it is decrypted. May include 1312 to be provided with the key. It should be noted that, as with all processes described herein, many modifications are considered to be within the scope of this disclosure. For example, process 1300 may be configured to respond to a GET request when it is authentic by providing an encrypted data object without providing an encrypted key. The user who submitted the GET request or the requester, who is the system, may obtain the key encrypted in other ways. For example In some embodiments, the user may store the encrypted key itself in a data storage system under the control of the user. As another example, one storage service can store encrypted data objects, another service can store encrypted keys, and users can store encrypted data objects and encrypted data objects. You can get the key from each service. As another example, another service or a third party for the user may be used to store the encrypted key and the user may obtain the encrypted key on request. In general, any method can be used in which an encrypted key can be provided.

As 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. FIG. 14 is therefore used to provide a decrypted key to an entity that needs such a decrypted key to decrypt an encrypted data object using the decrypted key. An exemplary example of the obtaining process 1400 is shown. Process 1400 can be performed by any suitable system, such as by the cryptographic services front-end system described above in connection with FIG. In certain embodiments, process 1400 comprises receiving a decryption to decrypt a key using another key with a specified KeyID 1402. Note that process 1400 is described in connection with key decryption, but process 1400 may generally be suitable for data decryption. The decryption request can be received in any suitable manner as described above 1402 (eg, via a well-configured API call). In addition, the decryption request can be received by any entity appropriate for the context in which process 1400 is running. For example, the decryption request can come from the user or from another system, such as the data service front end discussed above. The decryption request can also include the data to be decrypted (eg, the key) or a reference to it. The KeyID can be specified in any suitable manner. For example, in some embodiments, the decryption request includes a KeyID, or a reference to a KeyID, that is, information that can be used to determine the KeyID. As mentioned above, the KeyID can also be specified implicitly. For example, the KeyID can be obtained in relation to available data, such as the identity of the requester who submitted the decryption request. For example, KeyI

Process 1400 includes, in certain embodiments, 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 described above, the received authentication response can be used for 1408 to determine if the GET request is authentic. If it is determined that the GET request is not authentic 1408, 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 the specified KeyID and / or requester's policy information. Policy information may include information containing one or more policies regarding the KeyID and / or requester.

In certain embodiments, the accessed policy information is used to determine whether any applicable policy allows decryption of a key with a specified KeyID 1414. If the policy is determined not to allow decryption of the key specified by the KeyID 1414, process 1400 may include rejecting a GET request as described above 1410. However, if the policy is determined to allow decryption of the key with the specified KeyID, process 1400 may include decrypting the key using the key identified by the KeyID. When a key is decrypted using a key with a KeyID, then the decrypted key is the requester who submitted the decryption request (or, in some embodiments, another), such as by transmission over a network. Can be provided to (approved destinations) 1418.

As illustrated in Environment 1200 discussed above, a user may obtain an encrypted data object and a key for decrypting the data object in various ways. FIG. 15 shows an exemplary example 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 user-operated and / or hosted system as described in connection with FIG. Other suitable systems include systems operating on behalf of the user that do not necessarily follow the real-time user input provided, but perhaps follow a pre-programmed process.

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

Process 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 may be received in response to a ciphertext request from the data storage service. However, in general, ciphertext and encrypted keys can be received in other suitable ways 1504. For example, a request to receive a ciphertext from a data storage service can be an asynchronous request, and the ciphertext can be received according to another request subsequently submitted 1504. In addition, the ciphertext and encrypted key can be provided in a single response or can be obtained separately, such as by different responses (which can be from the same or different systems). As another example, a system running process 1500 may store the encrypted key locally or in another format, and the encrypted key may be retrieved from local memory.

In certain embodiments, process 1500 comprises requesting decryption of an encrypted key using a key with a specified KeyID. The KeyID can be specified in any suitable manner as described above. In addition, it should be noted that the system running process 1500 can specify the KeyID in any preferred manner. For example, the encrypted key and / or the information provided with it may specify the KeyID. As another example, the system running process 1500 may have local or remote access to information that allows the determination of the KeyID. The local or remote database may, for example, associate the data object identifier with the key identifier of the key used to encrypt the data object. In general, any mode in which the system may be able to specify the KeyID can be used. Moreover, in some embodiments, the KeyID need not be specified, such as when the information provided to the cryptographic service is sufficient to determine the KeyID. Request 1506 for decryption of the encrypted key is made in connection with the environment described above in connection with FIG. 12 and / or by the execution of process 1400 described above in connection with FIG. It can be performed in any suitable manner.

Process 1500 includes, in certain embodiments, receiving a decrypted key 1508. Receiving a decrypted key 1508 can be performed in any suitable manner. For example, the decrypted key can be received in response to a request to decrypt the encrypted key. As another example, a request to decrypt an encrypted key can be an asynchronous request, and another request has been submitted to receive the decrypted key. In general, the decrypted key can be received in any suitable manner. Moreover, as with all information flow from one device to another, information transfer 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 mode of secure communication can be used to pass information from one entity to another.

A 1508 in which the decrypted key is received, and process 1500 include 1510 in which the decrypted key is used to decrypt the 1510 ciphertext, whereby the plaintext can be acquired. 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 presents a request for ciphertext and a request for a composite of encrypted keys that is executed sequentially. However, like many of the operations described herein in connection with the various processes, the operations need not be performed sequentially in the various embodiments. For example, if the system running process 1500 has access to the encrypted key before requesting the ciphertext, or can do so in another way, the system may request the ciphertext. , And decryption of the encrypted key may be requested in parallel or in a different order than illustrated. Other variants are also within the scope of this disclosure.

As described above, 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 an exemplary example of cryptographic service 1600 according to various embodiments. As illustrated in Figure 16, and as described above, the cryptographic service 1600 logically front end sheet made from the stem and the 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. A request API is, in certain embodiments, an API configured for a cryptographic request and other operations performed by a cryptographic service. As such, a request can be made to the front-end system via the request API so that such cryptographic operations are performed by the cryptographic service.

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

A CreateKey (KeyID) request, in certain embodiments, causes a cryptographic service to create a key identified by a KeyID identified within the request. Upon receiving the request, the cryptographic service can generate a key and associate that key with the KeyID. It should be noted that the KeyID identifier can be a unique identifier, but not always. For example, the KeyID can identify a family of keys. For example, in some embodiments, key rotation is performed. Key rotation can involve exchanging a key for another key to prevent the collection of sufficient decrypted data to allow substantial cracking of the cipher used. When executed at the direction of an entity different from the cryptographic service, the use of the CreateKey (KeyID) request may force the cryptographic service to create a new key in exchange for the old key identified by the KeyID. The old key can be identified by the KeyID as is, but can only be used, for example, for decryption (of data already encrypted using the old key) and not for future encryption. As another example, in some embodiments, the user of the cryptographic service provides its own key identifier, but it is possible that two different customers may provide the same identifier. In such cases, the identifier cannot uniquely identify the key, or even the family of keys. Various measures can be provided to deal with this. For example, identity or other information associated with a user of cryptographic services can be used to identify the appropriate key or key family. Still in other embodiments, the cryptographic service may assign KeyIDs randomly, sequentially, or using any other method.

Note that various systems can be provided to allow proper functionality when the KeyID does not uniquely identify the key. For example, in various embodiments, the family of keys identified by the KeyID is finite. If a decryption operation using the key identified by the KeyID is required, additional data (eg, the time stamp when the encryption was performed) may allow it to determine the appropriate key for use. In some embodiments, the ciphertext may include information indicating a key version. In some embodiments, any possible key is used to provide different decoding of the data. Due to the finite number of keys, the appropriate decryption can be selected from those provided. In some embodiments, key-based decryption detects that a cryptographic service has at least partially not generated a ciphertext based on the key, such as by using authenticated encryption. It is executed in a way that enables. Other variants are also within the scope of this disclosure.

Encrypt (KeyID, Data, [AAD]) requests can be used to have a cryptographic service encrypt certain data using the key identified by the KeyID. Additional Authenticated Data (AAD) can be used for a variety of purposes and is not necessarily encrypted, but is data that is authenticated, for example, by a digital signature, message authentication code, or, in general, a keyed hash value that is included with the AAD. Can be. In some embodiments, the ciphertext is generated containing at least a portion of the AAD. In some embodiments, the AAD is provided separately during decoding. In some other embodiments, the AAD is generated at the time of decoding, at least in part based on the request and / or other metadata so that the decoding is successful only when the metadata is passed. In some embodiments, the policy may constrain whether a cryptographic operation can be performed on a particular AAD. The processing of Encrypt (KeyID, Data, [AAD]) requests by policies enforced by programming logic and / or cryptographic services is that the AAD contains certain values and that the AAD is authentic (eg, the first transmission). (Unmodified from) may be required. Similarly, a Decrypt (KeyID, Ciphertext, [AAD]) request can be used to force a cryptographic service to decrypt a specified ciphertext using the key identified by the KeyID. The AAD in the Decrypt (KeyID, Ciphertext, [AAD]) request can be used as described above. For example, the processing of Decrypt (KeyID, Ciphertext, [AAD]) by policies enforced by programming logic and / or cryptographic services is that the AAD contains certain values and that the AAD is authentic (eg, the first). It may require both (unmodified from transmission).

Shred (KeyID) can, in certain embodiments, be used by a cryptographic service to electronically shatter a key or a family of keys identified by a designated KeyID. Electronic crushing can involve making the key no longer accessible. For example, the use of Shred (KeyID) requests can force a cryptosystem to perform a Secure Erase operation on one or more keys identified by one or more hardware devices by the specified KeyID. In general, the key (s) identified by the KeyID is, for example, by overwriting other data (eg, a series of zeros or ones, or a random string) on the data encoding the key. It can be electronically crushed in any suitable manner. If the key (s) are encrypted and stored under the key, the key used to encrypt the key can be electronically shattered, thereby accessing the key (s). Causes loss. In some embodiments, the crushing operation may cause the decryption operation, which indicates the KeyID to be crushed, to fail at some point in the future. Other modes of destroying any possible access to the key (s) safely and permanently can be used.

The ReKey (Ciphertext, OldKeyID, NewKeyID) request can be used in certain embodiments to cause a cryptographic service to encrypt a ciphertext under a different key. Upon receiving a ReKey (Ciphertext, OldKeyID, NewKeyID) request, the cryptographic service can decrypt the specified ciphertext using the key identified by the OldKeyID and then decrypt it using the key identified by the NewKeyID. Ciphertext can be encrypted. If the key identified by NewKeyID does not yet exist, the cryptographic service will generate a key to use and specify the generated key as described in connection with the Create (KeyID) request mentioned above. Can be associated with the New Key ID. In some embodiments, the ReKey operation may be manipulated to allow data to be transmitted 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, ReKey assists in rekeying the ciphertext from the key identified by the first KeyID in the first account to the key identified by the KeyID in the second account. May be done.

Similarly, front-end systems, in certain embodiments, allow users to submit policies for performing cryptographic operations, as well as requests for configuring other policy-related operations. Can be implemented. Policies can be associated with keys, groups of keys, accounts, users, and other logical entities in various embodiments. Examples of policies that can be configured via the Policy Configuration API are provided below. In certain embodiments, the cryptographic service policy configuration API includes the following requirements:

SetKeyPolicy (KeyID, Policy) Suspend (KeyID, Public Key) Reinstate (KeyID, Private Key)

In certain embodiments, a SetKeyPolicy (KeyID, Policy) request can be used by a cryptographic service to store a policy on a key (or family of keys) identified by a KeyID. A policy can be decisive information about whether a requested cryptographic operation can be performed within 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 encoded in a declarative access control policy language, such as SecPol, or any preferred method of encoding one or more conditions that must be met for the cryptographic operation performed. A policy is a specific request, such as what operation can be performed, when the operation can be performed, which entity can make an approved request for the operation to be performed, and so on. It can define what information is needed to be approved, etc. In addition, policies can be defined and / or enforced using access control lists, privileges associated with users, and / or operational bitmasks in addition to or instead of the examples given above. An example policy is shown below.

In some embodiments, the cryptographic service may assist the suspend operation using, for example, a Suspend (KeyID, Public Key) API call. The pause operation allows the cryptographic service customer to deny the use or access to the key by the cryptographic service operator. This can be useful for customers who are concerned about hidden legitimate orders, or other situations in which a cryptographic service operator may be forced to perform some operations using a key. It is also useful for customers who want to lock certain data and make it inaccessible online. In some embodiments, the pause operation is associated with receiving a public key from a customer and encrypting the key specified by a given KeyID with the received public key. The private key is, for example, Reinstate (KeyID, Private) that specifies the KeyID and contains the private key. It may include using the Key) API call to break the key specified by the KeyID to prevent the provider from accessing the suspended key unless provided. In some embodiments, the pause operation includes the key associated with the specified KeyID, another key managed by the cryptographic service, including one created for the purpose of an immediate pause operation. May be accompanied by encryption using (but not limited to). The ciphertext produced by this operation can be provided to the customer and is not stored within the cryptographic service. The original key identified by the KeyID can then be shattered. The cryptographic service may be able to receive the ciphertext provided and operate to re-import the pause key. In some embodiments, the ciphertext may be generated in such a way as to prevent the cryptographic service from returning the decrypted version to the customer.

As illustrated in FIG. 16, the cryptographic service 1600 includes a back-end system that itself has various components in some embodiments. For example, the back-end system in this example includes a request processing system that can be a subsystem of cryptographic service 1600 configured to perform operations that follow requests received via 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 such request is genuine and therefore capable of being fulfilled. , Can fulfill that request. Fulfilling a request can include, for example, performing a cryptographic operation and / or performing it. The request processing unit may be configured to interact with an authentication interface that allows the request processing unit to determine whether 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 utilizes an authentication interface to interact with an authentication service that provides authentication that can be used to bring about performing cryptographic operations when appropriate. obtain.

The cryptographic service 1600 back-end system also includes multiple security modules (cryptographic modules) and policy enforcement modules in this exemplary example. One or more of the security modules can be hardware security modules, but in various embodiments, the security module is any suitable computer device configured to have the functionality described herein. Can be. Each security module in one embodiment stores a plurality of keys associated with a KeyID. Each security module may be configured to securely store the key so that other components of the cryptographic service 1600 and / or other components of the system are inaccessible. In certain embodiments, some or all of the security modules comply with at least one security standard. For example, in some embodiments, each security module has one or more security levels outlined in FIPS Publication 140-2. Validated according to the Federal Information Processing Standard (FIPS) outlined in 140-1 and / or 140-2. In addition, in some embodiments, each security module is certified under the Cryptographic Module Validation Program (CMVP). A security module can be implemented as a hardware security module (HSM), or another security module that has some or all of the functionality of the HSM. In some embodiments, validated modules are used to bootstrap operations. In some embodiments, the customer can configure some keys stored within the verified module and operated only by the verified module, and other keys operated by the software. In some embodiments, the performance or cost associated with these various options may vary.

The 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 provides the ciphertext and KeyID to the appropriate security module, along with instructions to the security module to decrypt the ciphertext using the key associated with the KeyID and provide plaintext accordingly. obtain. In one embodiment, the cryptographic service 1600 back-end system stores a plurality of keys that form a key space. Each of the security modules may store all the keys in the keyspace, but variants are considered to be within the scope of this disclosure. For example, each of the security modules may store a subspace of the key space. The subspaces of the keyspace stored by the security module can overlap because the keys are redundantly stored throughout the security module. In some embodiments, a particular key may only be stored within a designated geographic area. In some embodiments, a particular key may only be accessible to an operator with a particular certificate or clearance level. In some embodiments, a particular key may be stored within a module operated by a particular third party provider under a contract with a provider of data storage services, and may be used only with that module. In some embodiments, the constitutive control of the security module uses keys other than being authorized by the customer to be involved in either an additional entity that is enforced or an additional jurisdiction that enforces an action. It may require a legitimate order to enforce it. In some embodiments, the customer may be offered an independent option for jurisdiction in which their ciphertext is stored and their key is stored. In some embodiments, a security module that stores a key may be configured to provide audit information to the owner of the key, which security module may generate and provide audit information. It can be configured so that the customer cannot control the service. In some embodiments, the security module is a signature generated by the customer so that the provider (eg, hosting the security module) cannot perform operations under the keys stored by the security module. Can be configured to verify independently. In addition, some security models can memorize all of the keyspace, and some security modules can memorize subspaces of the keyspace. Other variants are also within the scope of this disclosure. When different security modules store different subspaces of the keyspace, the request processing unit is a relational table or other machine for deciding which security module commands to perform cryptographic operations according to different requests. It can be constructed using an introduction or the like.

In certain embodiments, the policy enforcement module is configured to obtain information from a request processing unit and, at least in part, based on that information to determine whether a request received from the API can be executed. For example, when a request to perform a cryptographic operation is received via the request API, the request processing unit interacts with the policy enforcement module to perform any appropriate policy, eg, within the request. It may determine whether it is approved by a policy applicable to the specified KeyID and / or other policies such as the policy 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.

As with all figures described herein, many modifications are considered to be within the scope of this disclosure. For example, Figure 16 shows a policy enforcement module 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 independently to enforce the policy. In addition, as another example, each security module may include a policy enforcement module that enforces a policy that is different from the policy enforced by a separate policy enforcement module. Many other variants are considered to be within the scope of this disclosure.

As described above, various policies are in or associated with the KeyID so that when a request specifies a cryptographic operation to be performed in association with the key corresponding to the KeyID, the policy can be enforced. It can be configured by the user. Figure 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 by a cryptographic service system as described above in connection with FIG. In one embodiment, process 1300 includes receiving a request to update the KeyID policy 1302. The request can be received in any suitable manner 1302. For example, referring to FIG. 16 as an example, the request may be received via the policy configuration API of the cryptographic service 1600 front-end system described above. The request can be received in any suitable manner.

Process 1700, in certain embodiments, comprises submitting an authentication request 1704 and receiving an authentication response 1706. Submitting a certification request 1704 and receiving a certification response 1706 can be performed in any suitable manner as described above. Further described above, the received authentication response can be used to determine if the request to update the KeyID policy is genuine or not in 1708. If the received request to update the KeyID policy is determined to be non-genuine 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 KeyID policy is determined to be genuine 1708, process 1700 may include accessing the policy information applicable to the requester 1712. The policy information can be information to which any policy applicable to the requester can be enforced. For example, within an organization that uses cryptographic services performed by process 1700, only certain users in that organization may be allowed to update the policy for KeyID. The policy information may even indicate which user can force the cryptographic service to update the KeyID policy and / or whether the policy can be updated according to an existing policy. For example, a cryptographic service may receive a request to enforce a new policy in some embodiments. Cryptographic services can check whether any existing policy allows new policies to be introduced. If the cryptographic service decides that the existing policy does not allow the enforcement of the new policy, the request may be denied. In general, the policy information can be any information that can be used to enforce the policy applicable to the requester.

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

The policy can also be enforced by other components of the electronic environment that operate in connection with cryptographic services. For example, referring to Figure 2 discussed above, a cryptographic service may provide an electronic display of policies to the data service front end for the data service front end to enforce. Such may be useful in situations where the data service is better suited to enforce the policy. For example, whether an action is allowed by a policy can be based, at least in part, on information that is accessible to the data service front end but not accessible to cryptographic services. As an example, a policy may be based on data stored by a data service backend storage system on behalf of the customer associated with the policy.

As described above, cryptographic services may include various systems that allow policy enforcement in accordance with policies on keys that have a KeyID. Therefore, FIG. 18 shows an illustrated example of process 1800 that can be used to enforce the policy. Process 1800 can be performed by any suitable system, such as by a cryptographic service system as described above in connection with FIG. In certain embodiments, process 1800 includes 1802 receiving a request to perform one or more cryptographic operations using a key with a KeyID. FIG. 18 illustrates process 1800 as being performed in connection with a request to perform one or more cryptographic operations, because process 1800 performs operations that are not necessarily cryptographic. Note that it may be suitable for use in any requirement of. An example of operation is described above.

A determination can be made as to whether the received request is authentic 1804. 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 may include submitting an authentication request and receiving an authentication response, as described above. If the request is determined to be non-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 to access the KeyID and / or the requester's policy information. Accessing the KeyID and / or request policy information can be performed in any preferred manner. For example, accessing the KeyID and / or requester's policy information can be performed by accessing the storage policy information from one or more storage systems that store such policy information. Access policy information can be used to determine whether a policy allows one or more operations to be performed in 1810.

If the policy is determined not to allow one or more operations to be performed 1810, process 1800 may include denying the request 1806. However, if the policy is determined to allow one or more operations to be performed, process 1800 may include 1812 performing one or more requested cryptographic operations. One or more results of performing one or more cryptographic operations may be provided, for example, to the requester who submitted the received request 1802 to perform one or more cryptographic operations 1814. In some embodiments, information derived at least in part from the permitted and / or denied requests may be provided via the audit subsystem.

As discussed, the embodiments of the present disclosure allow flexible policy composition and enforcement. In some embodiments, the policy may state which service can perform which operation in which context. For example, a policy on the key may allow a data storage service to allow a cryptographic service to perform a cryptographic operation rather than a decryption operation. The policy on the key may also include one or more conditions for ciphertext and / or decrypted plaintext. For example, a policy may require ciphertext and / or plaintext to produce a particular hash value (which can be a keyed hash value) before the result of the operation is provided on demand. The policy is one or more constraints and / or permissions that are based at least in part on time, the type of Internet Protocol (IP) encrypted / decrypted content, AAD, and / or other information from which the request originates. Can be specified.

Many variants are considered to be within the scope of this disclosure. For example, the various embodiments discussed above discuss dialogue with separate authentication services. However, the environmental components discussed above may have their own approval components, and the determination of whether a request is authentic may or may not involve communication with another entity. .. In addition, each of the environments discussed above is exemplified in connection with the specific operations and functions enabled by the environment. The techniques discussed above in the context of different environments can be combined, and in general, the environment according to this disclosure may allow flexible use of various techniques. As merely an example, cryptographic services can be used to encrypt both keys and other content such as unkeyed data objects at the time of 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 on mobile devices to perform encryption of stored data. In some embodiments, at least one unlock pin can be verified by a cryptographic service. Still in other embodiments, the cryptographic service may receive the information generated by the hardware configuration certificate as part of the operation. In some embodiments, the cryptographic service may be operable to provide a digital rights management service for the content.

As mentioned above, the various embodiments of the present disclosure allow for a wealth of policy enforcement and configurability. Many cryptosystems provide a certified cryptographic mode of operation in which cryptographic operations can be performed simultaneously to provide confidentiality, integrity, and authenticity assurance for the data. Confidentiality can be provided by encryption of plaintext data. Authenticity can be provided for both plaintext and related data that can remain unencrypted. In such systems, changes to either the ciphertext or related data can cause ciphertext decryption failures.

In certain embodiments, the data associated with the plaintext is used in policy enforcement. Therefore, FIG. 19 shows an exemplary example of process 1900 for encrypting data in a manner that allows policy enforcement with relevant data according to various embodiments. Process 1900 can be performed by any suitable system, such as cryptographic services and / or security modules. As illustrated, process 1900 involves acquiring plaintext 1902. Plaintext can be acquired in any suitable manner. For example, in a service provider environment as described above, a user (eg, a customer) may provide encrypted data. As another example, acquisition 1902 may include generating a key (encrypted) and / or acquiring an encrypted key. The key can be used as described above.

As shown, process 1900 involves acquiring relevant data. The relevant data can be any data associated with or will be associated with the plaintext. The relevant data can be any data on which one or more policies are at least partially based. An example is shown below. In addition, related data includes eXtensible Markup Language (XML), JavaScript Object Notation (JSON), Abstract Syntax Notation One (ASN1), YAML Ain't Markup Language (Yet Another Markup). It can be encoded in any suitable manner, such as (also referred to as Language) (YAML), or another structured extensible data format. In certain embodiments, process 1900 comprises generating message authentication code (MAC) and ciphertext, at least in part, based on plaintext and related data. A combination of MAC and ciphertext, such as the output of an AES-GCM cipher, can be referred to as an authenticated ciphertext. Generating the MAC and ciphertext can be performed in any preferred manner, and generating the MAC and ciphertext can depend on which cryptosystem (s) are used. For example, in one embodiment, Advanced Encryption Standard (AES) assists associated authenticated data (AAD) when operated in either CCM mode or GCM mode, where CCM is Counter with CBC-. MAC stands for MAC, GCM stands for Galois / Counter Mode, and CBC stands for cipher block. Chaining). When using AES in either CCM or GCM mode, plaintext and related data may be provided as input to obtain the output of a concatenated pair of ciphertext and MAC for both plaintext and related data. Although AES-CCM and AES-GCM are provided for purposes of illustration, other certified cryptosystems may also be used and the techniques expressly described herein are adapted accordingly. Note that it can be modified. For example, the techniques of the present disclosure are generally applicable to symmetric block ciphers that support authenticated encryption modes. In addition, other cryptosystems can be combined with MAC functions according to various embodiments of the present disclosure. Suitable combinations of encryption methods and MAC functions include, but are not limited to, those in which the encryption method is confidential under a chosen-plaintext attack and the MAC function cannot be forged under a chosen-plaintext attack. Further, various embodiments of the present disclosure utilize a cipher that results in a single output that encodes both the ciphertext and the MAC, but the MAC and the ciphertext can be generated using different ciphertexts. In addition, the MAC is used as an example, but other values that are not commonly referred to as the MAC, such as common hashes, checksums, signatures, and / or other values that can be used in place of the MAC. Values can also be used. Thus, ciphers with automated cryptographic modes that support relevant data include ciphers that use other cryptographic primitives in addition to or as an alternative to the MAC.

Moreover, generating the MAC and ciphertext can be performed in different ways according to different embodiments. For example, in certain embodiments, plaintext is provided to the security module as described above. The security module can be configured to generate a MAC. In other embodiments, components of the electronic environment other than the security module generate a MAC and a ciphertext. In such an embodiment, the security module can be used to decrypt the MAC and the key used to generate the ciphertext when in plaintext form. Once generated, the MAC and ciphertext (ie, the authenticated ciphertext) are provided 1908. Relevant data are also provided in some embodiments. MACs and ciphertexts can be provided in different ways in different implementations utilizing Process 1900 and its variants. For example, in some embodiments, the MAC and ciphertext are provided to the user as described above, or to the data service as described above for processing by the data service. Will be done. Further, as stated, relevant data may be provided, but in various embodiments, relevant data is not provided and / or is generally retained in clear text form. As an example, relevant data may not be provided if it is available independently. As an exemplary example, if the relevant data is a device's persistent identifier (eg, a storage device's identifier), the relevant data will be acquired later when it is needed for policy enforcement and / or other purposes. Can be done.

As mentioned above, various embodiments of the present disclosure utilize security modules to provide enhanced data security. FIG. 20 illustrates an exemplary example of Process 2000 that can be used to encrypt data in a manner that allows new and rich policy enforcement according to various embodiments. Process 2000 is performed by any suitable system, such as cryptographic services and / or security modules. As illustrated in Figure 20, Process 2000 involves acquiring plaintext and relevant data. As mentioned above, plaintext and related data may be received in a single communication, in a separate communication, and / or from a separate entity. Once acquired, plaintext, relevant data, and KeyID will be provided to the Security Module 2004. The security module can be as described above. In addition, the security module may be selected from a plurality of security modules involved in an electronic environment, such as an environment that supports cryptographic services, as described above. The KeyID can be as described above and can be specified in the request for encrypting the plaintext submitted to the cryptographic service, or in another form. Further, in an alternative embodiment of Process 2000, the KeyID may not be specified. For example, in some embodiments, the security module may select a KeyID and / or generate a key to which it can be assigned a KeyID later. In such an embodiment, process 2000 can be modified to provide a KeyID from the security module.

Returning to the illustrated embodiment, process 2000 may include receiving ciphertext and MAC from the security module 2006. The ciphertext can be encrypted under the key identified by the KeyID. Since the MAC can be a MAC for both plaintext and related data combinations, changes to ciphertext or related data will result in a MAC check failure. Note that, as mentioned above, the variants include those in which the MAC is at least partially based on relevant data but generated independently of the plaintext. Further, as mentioned above, the ciphertext and MAC can be provided together (such as from the output of the use of AES-CCM or AES-GCM ciphers) or separately. When received from the security module, the MAC and ciphertext are provided to the appropriate entity, such as the user of the cryptographic service, or the data service that operates in association with the cryptographic service, as described above.

As mentioned above, security modules can be used in various ways to enhance the protection of data. As mentioned above, in some embodiments, the security module is used to encrypt the key used to encrypt other data (in plaintext form). Therefore, FIG. 21 shows an exemplary example of Process 2100 that can be used in such situations. Process 2100 is performed by any suitable system, such as cryptographic services and / or security modules. Process 2100, in certain embodiments, comprises acquiring plaintext and relevant data 2102, as described above. As illustrated, process 2100 provides the security module with an encrypted key, associated data, and a KeyID that identifies the key that can be used by the security module to decrypt the encrypted key 2104. including. Therefore, process 2100 involves obtaining the decrypted key from a security module that uses the key identified by the KeyID to decrypt the encrypted key. The acquired key can be used to encrypt the plaintext and thereby calculate the ciphertext and MAC for 2108. The ciphertext can be plaintext encryption, and the MAC can be related data, or both related data and plaintext (ie, at least partially based), as described above. Once encrypted, process 2100 may include 2110 to provide the MAC and ciphertext, as described above. In addition, the process also performs a Secure Erase operation, overwrites the memory that stores the decrypted key, removes power from the volatile memory that stores the key, and / or the system performs process 2100 (eg, some cryptosystems). It can also include 2112 losing access to the decrypted key, which can be performed in any preferred manner, such as by any other method (lacking a security module). In parallel

FIG. 22 shows exemplary examples of process 2200 that can be used to enforce policies using relevant data according to various embodiments. Process 2200 is performed by any suitable system, such as cryptographic services and / or security modules. In certain embodiments, process 2200 comprises receiving a request to perform an operation 2202. The request can be any request submitted to the service that processes the request. In certain embodiments, the request is a request to perform a cryptographic operation submitted to a cryptographic service. Depending on the receipt of the request 2202, the process 2200 may include 2204 to acquire the ciphertext, MAC, and expected relevant data. Acquiring ciphertext, MAC, and expected relevant data 2204 can be performed in any suitable manner. For example, in some embodiments, one or more of the ciphertext, MAC, and expected relevant data is received within the request. Two or more of the ciphertext, MAC, and expected associated data may be received in separate requests or other communications, and / or may be accessed from a data store, such as a local data store. For example, in certain embodiments, the ciphertext and MAC are received as part of a request as a concatenated pair (perhaps generated from the output of an AES-GCM or AES-CCM cipher). Predicted relevant data can also be part of the request or be identified in other ways. For example, the requester's identity can be used directly or indirect to determine relevant data. As a specific example, if the request is to perform an operation related to the data stored in the storage device, then acquiring the relevant data 2204 may include acquiring the identifier of the data storage device. The identifier can be used explicitly (eg, as part of a request) or implicitly (eg, because other information can be used to determine that the data is stored within the data storage device). Can be identified To. The relevant data can be an identifier for the data storage device, or at least in part based on it. As mentioned above, the relevant data can vary widely between different embodiments.

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

Then, whether the policy allows the requested operation to be performed (for example, whether the policy allows the request to be fulfilled), at least in part, based on the policy information accessed. A decision can be made 2212. Determining whether a policy allows the requested operation to be performed may include determining whether the ciphertext is tagged with the relevant data specified by the accessed policy information. In addition, policy information that is not exemplified, but is at least partially unbased on relevant data (eg, policies based on information other than relevant data) also determines whether the policy allows the operation to be performed. Can be used to If the policy is determined to allow the operation 2212, process 2200 may include performing the operation 2214. However, if the policy is determined not to allow the operation 2212, and / or if the reference MAC is determined to be inconsistent with the acquired MAC 2208, process 2200 requests as described above. May include refusal 2216.

Various policies can be enforced using the techniques described above. For example, as stated, a policy can be associated with a key to determine what can and / or cannot be done with the key when it is enforced. As an example, the policy states that the data service can only use the key for certain types of operations specified by the policy (or that certain operations are prohibited for the data service). obtain. The policy can also specify conditions such as usage, usage time, IP address, what can be encrypted, what can be decrypted, and so on. As an example, one policy may specify that providing a decrypted result is only allowed if the hash of the decryption matches the specified value. Therefore, the cryptographic service or other service that enforces the policy does not provide the plaintext if the plaintext hash does not match the policy. As another example, one policy may specify that decryption of a ciphertext is only allowed if the ciphertext is tagged with relevant data that is equal to or begins with the specified value. As yet another example, one policy may specify that decryption of the ciphertext is only allowed if the ciphertext is tagged with the identifier of the storage device that is encoded in the relevant data.

In general, a policy may specify constraints and / privileges that are at least partially based on the value of the data associated with the ciphertext (ie, the authenticated associated data). Some additional policies are for decryption to tag the ciphertext tagged with the identifier of the computer requesting decryption, the identifier of the storage volume attached (operably connected) to the computer requesting decryption. Includes policies that specify that only ciphertexts that are used and / or ciphertexts that are tagged with identifiers of other computing resources are allowed. A computing resource can also be a computing resource hosted by a computing resource provider that enforces the policy. Other policies reveal the output of the cryptographic algorithm to entities other than the entity that executes the cryptographic algorithm (eg, to users and / or other data services other than the cryptographic service that enforces the policy). Previously, it is considered to be within the scope of this disclosure, such as policies that are at least partially based on the input and / or output of cryptographic algorithms. As mentioned above, the policy can also specify the conditions under which the policy can be modified, which may be at least partially based on relevant data.

FIG. 23 shows an exemplary example of process 2300, which is a variant of process 2200 described above in relation to FIG. 22, where the variant follows various embodiments of a security module in policy enforcement. Illustrate use. In certain embodiments, process 2300 includes receiving a request to decrypt a ciphertext, which may be an encrypted key or other encrypted data 2302. Process 2300 also includes acquiring ciphertext, MAC, and expected relevant data, as described in connection with FIG. 22. As illustrated in FIG. 23, in certain embodiments, process 2300 includes using a security module 2306 to decrypt the ciphertext. Using Security Modules 2306 may also include selecting a security module from multiple operational security modules to decrypt the ciphertext, thereby producing plaintext. Security modules can also be used to generate reference MACs based at least in part on plaintext and expected relevant data 2308. Although shown as two separate steps in Figure 23, using the security module to decrypt the ciphertext and generate the reference MAC is performed in a single operation (eg, a single request to the security module). Note that you get. Once acquired from the security module, process 2300 includes determining whether the reference MAC and the acquired MAC match, as described above in relation to Figure 22. However, it should be noted that in some embodiments, process 2300 may be modified so that the security module is provided with a reference MAC and determines whether the reference MAC and the acquired MAC match. In this variant, the security module may provide a response indicating whether there is a match.

Returning to the embodiment illustrated in FIG. 23, if it is determined that the reference MAC and the acquired MAC match 2310, process 2300 is at least partially as described above in relation to FIG. Includes access to policy information based on relevant data in 2312. Also, as mentioned above, additional policy information about policies that are not exemplified as such, but are at least partially not based on relevant data, may also be accessible. A decision can be made as to whether the policy allows the operation 2314. If the policy is determined to allow the operation 2314, plaintext may be provided 2316. As above in connection with Figure 22, if the policy is determined not to allow the operation 2314, and / or if the reference MAC is determined not to match the acquired MAC, the process is described above. As such, denying the request may include 2318.

Although various embodiments of the present disclosure are illustrated using relevant data of cryptographic authentication modes, other embodiments are also considered to be within the scope of the present disclosure. For example, embodiments of the present disclosure generally apply to the use of ciphertext-verifiable data to enforce policies. As an exemplary example, the policy display can be combined with the first plaintext to generate a new plaintext (eg, the plaintext and the new plaintext that includes the policy). The new plaintext can be encrypted using a suitable cipher such as AES to produce the ciphertext. When a request to decrypt the ciphertext is received, the system receiving the request decrypts the ciphertext, extracts the policy from the new plaintext, and whether the policy allows the first plaintext to be provided. Can be checked. If the policy does not allow the first plaintext to be provided, the request may be denied. Such embodiments may be used in lieu of or in addition to the embodiments described above in connection with the relevant data of cryptographic authentication modes.

Various embodiments of the disclosure also allow the policy on the key to specify the conditions under which the audit is performed. For example, a policy on a key can specify the audit level of the key, where the audit level is a parameter of the crypto service that is decisive about how the crypto service audits the use of the key. The audit can be performed by any suitable system. For example, referring to FIG. 16, the request processing unit may communicate with an audit system (not shown) that may be part of or separate from the cryptographic service. When an event occurs in connection with the execution of a cryptographic operation, the relevant information may be provided to a monitoring system that records the information. The event can be a request to perform a cryptographic operation and / or information indicating whether the requested operation has been performed. For example, if a user succeeds in making a request to a cryptographic service to perform a decryption operation, the cryptographic service provides the audit system with information to enable the request and information that the operation has been performed. Can be done. Management access events and, in general, any interaction or operation of cryptographic services are recorded along with relevant information that may identify the entity involved in the event, information that describes the event, time stamps of the event, and / or other information. Can be done.

In certain embodiments, audit levels include high durability levels and low durability levels. At low durability levels, key auditing operations can be performed best effort by cryptographic services. In a low durability level audit, all operations are audited during normal operation, but some audit data can be lost in the event of cryptographic service component failure. Auditing according to a high durability level provides a guarantee that the audit record that the operation occurred is durablely passed to memory before revealing the result of the cryptographic operation. Operations in high-durability audit mode are slower than operations in low-durability audit mode because confirmation is required. Guarantees that audit records are durablely passed to memory can include confirmations from one or more other systems used to store audit records. Therefore, referring to the previous paragraph, the cryptographic service may delay the provision of plaintext to the user until the audit system confirms that the record of the decryption that results in the plaintext is durablely passed to memory. Durable delivery to memory can mean that the data is stored according to one or more conditions for durability. For example, data is stored redundantly between multiple data storage devices when the data is written to non-volatile memory and / or data is stored redundantly (eg, erasure coding or other redundancy). When (using the encoding method), it can be delivered to memory in a durable manner.

In certain embodiments, cryptographic services use sublevels of low durability and high durability audit levels. For example, in certain embodiments, each level corresponds to two separate states, an invariant state and a variable state. Whether a state is immutable or immutable can determine how and whether transitions between states occur. For example, using an example of audit durability, the policy on the key is between low durability variable and high durability variable, from low durability variable to low durability invariant, and high durability variable. Can be changed from to high durability invariant. However, cryptographic services can be configured to prohibit transitions once the key policy is placed in either low-durability invariance or high-durability invariance. Therefore, once the key policy is placed in an immutable state, the policy cannot be changed.

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

FIG. 25 shows a generalized phase diagram showing how the system can allow transitions between the various policies applicable to the key. In this example, three policies, Policy A, Policy B, and Policy C, are shown. Each of these policies has variable and immutable states, indicating acceptable transitions between states and policies. For example, transitions from the immutable state are not allowed. However, a policy in a variable state can be changed to another policy in a variable state. For example, the policy on the key can be changed from policy A (variable) to policy B (variable). As illustrated in Policy B, there can be transitions available for multiple policies. For example, from policy B, the policy can be changed to either policy C or policy A. Similar to FIG. 24, other transitions and policies may be included and not all policies may have all states. Moreover, while various examples show policies with immutable and variable states, policies can have more than one state, where each state is a set of actions that can or cannot be performed. Corresponds to. For example, a semi-variable state may allow some, but not all, of the transitions available under a variable state.

As stated, policies can be used for various operations in addition to auditing. For example, the above constraints in policy transitions can be applied to key crumbleability. For example, one policy may indicate whether a key can be shattered (lost in an irrevocable manner). The policy can have four states: crushable-variable, crushable-immutable, non-crushable-variable, non-crushable-immutable. As mentioned above, the policy cannot be changed when in the immutable state. As another example, a policy on whether a key can be exported from a security module can also have such a four-state policy.

Policies can also be associated with keys to prevent key use that makes them vulnerable to security attacks. For example, in one embodiment, one or more keys are associated with an automatic rotation policy that retires the key after a certain number of uses (eg, is marked as no longer available for encryption). Such a policy can be a user-configurable (eg, customer-configurable) policy in which the user (eg, the customer) activates and / or provides the parameter. The policy can also be a global policy applicable to a larger set of keys, such as a set containing at least all keys managed by a cryptographic service on behalf of a customer. In this manner, the key may be retired before sufficient plaintext and corresponding ciphertext knowledge has been used for sufficient time to enable a cryptographic attack that provides the ability to determine the key.

FIG. 26 shows an exemplary example of process 2600 used to rotate keys at appropriate intervals according to various embodiments. Process 2600 can be performed by any suitable device, such as the security modules described above. In certain embodiments, process 2600 includes 2602 receiving a request to perform a cryptographic operation using the key identified by the KeyID. The request can be a request received from a cryptographic service request processor, as described above. The request uses a key to encrypt or decrypt data, such as a digital signature, another key, or the generation of other information that is at least partially based on the key, or, in general, a key identified by a KeyID. It can be a request to perform any cryptographic operation. Upon receiving the request 2602, process 2600 includes performing the requested operation 2604. Performing the requested operation may include additional operations, such as selecting the appropriate version of the key to perform the operation. For example, if the operation is encryption, the key marked as active may be used for encryption. If the operation is decryption, performing the operation may include selecting and decrypting the appropriate version of the key identified by the KeyID, and in various embodiments, the key encrypts the data. This is the first key used for. The key can be selected in various ways. For example, in some embodiments, the ciphertext may include metadata that identifies a version, serial number, date, or other information that allows selection of a key. In some embodiments, each of the possible keys can be tried until the data is correctly decrypted, which is determined by the hash of the plaintext output associated with the ciphertext or by the legitimacy of the associated data. obtain.

Once the cryptographic operation is performed 2604, process 2600 includes updating the key usage counter for the active key identified by the KeyID 2606. For example, if a cryptographic operation results in a single key use, the counter can be incremented by one. Similarly, if the cryptographic operation results in N (N is a positive integer) key usage, the counter can be incremented by N. A decision is made as to whether the counter exceeds the threshold 2608. The threshold can be the number of uses assigned to the version of the key identified by the KeyID. Thresholds may be provided by a component of a cryptographic service that manages the assignment of key operations. The threshold can also be the default number of operations. If the counter is determined to exceed a threshold 2608, in one embodiment process 2600 includes acquiring a new key 2610. Acquiring a new key can be performed in any suitable manner. For example, if process 2600 is executed by a security module, acquiring a new key means generating a new key or acquiring a new key from another security module that can be organized by a cryptographic service operator. Can include. Passing a key from one security module to another can be performed by encrypting the key with a key that the provider and receiver security modules have access to. A security module running process 2600 can obtain and decrypt the encrypted key. Public key key exchange techniques can also be used.

When a new key is acquired, in one embodiment, process 2600 may include marking the current active key as retirement 2612. Marking the current active key as a retirement can be done in any suitable way, such as by changing the appropriate value in the database maintained by the security module. In addition, process 2600 involves associating the new key with the KeyID 2614, and marking the new key as active, such as by updating the database maintained by the security module. Although not illustrated, Process 2600 may also include providing a new key for use by another security module. At some point after the new key is ready for use by the security module (or other system) running process 2600, as indicated by the dashed line, the process will perform another cryptographic operation. 2602 may be included and process 2600 may process as described above. Further, if the counter is determined not to exceed the threshold 2608, process 2600 may terminate and / or repeat with 2602 when another request is received.

FIG. 27 illustrates an exemplary example of Process 2700 that can be used to perform automatic key rotation in cryptographic services or other environments according to various embodiments. Process 2700 can be performed by any suitable system, such as a cryptographic service component that tracks key usage and organizes key rotations according to various embodiments. As illustrated in Figure 27, process 2700 involves assigning many key operations for a key (eg, many operations for each of multiple keys) to one or more security modules 2702. As a concrete example, in an environment where 5 security modules are used to redundantly store / use a set of keys, each security module is assigned 1 million operations to each key it manages. obtain. The security module (or other computer system) to which the operation is assigned can be hosted in the same data center in multiple data centers. For example, in some embodiments, a computing resource provider leverages security modules within multiple data centers in multiple geographic areas to implement geographically distributed cryptography or other services.

However, keep in mind that the assignments can be made for some keys rather than all keys, and that the assignments for each key may not be equal. Assigning a key operation may include providing each security module with an assignment notification of which key operation was assigned. The notification may specify the number assigned to each key, or in some embodiments, the notification to the security module reinitializes the security module with a pre-programmed counter within the security module. Or can indicate that a pre-programmed number is added to the counter. The 2702 that assigns key operations to the security module and the key usage counters for each key to which the operation is assigned can be updated. Continuing with the specific example above, if each of the five security modules is assigned 1 million operations to a key identified by a particular KeyID, the counter for the KeyID can be incremented by 5 million (counting). Up or down, depending on whether it runs up or down).

When a key operation is assigned, the security module may perform cryptographic operations as described above. Security modules may maintain their own counters that are at least partially based on the allocations made. In the above example, if the security module is assigned 1 million operations to a key identified by a particular KeyID, the security module can set the counter to 1 million (or the existing counter is the remaining operation). If you have more than 1 million). When performing key-based cryptographic operations, the security module may increase its own counters accordingly.

At some point, allocation exhaustion events for one or more KeyIDs can be detected 2706. A depletion event can be any event in which one or more security modules lose or deplete its allocation. As an example, a security module can use its assignment of operations on a key identified by a particular KeyID, and depletion event detection is from the security module by the security module performing the corresponding number of operations. In another way, it is predicted that the assignment to the KeyID is depleted (or is within some prescribed threshold indicating that the assignment is depleted, or that the assignment is depleted soon). ) May be included in receiving the notification. As another example, in some embodiments, the security module is at a particular event, such as detection of a failure, intrusion, or other tampering, or when the operator requires access to the security module for maintenance. , It is configured to lose access to the keys stored there (and the data associated with the keys such as counters). Therefore, depletion events include security module loss (possibly temporary) due to failure or tampering / intrusion detection, and internal actions (such as temporarily disabling the security module for maintenance). obtain. In this example, the security module can be treated as if it used that assignment, even though it did not necessarily perform the assigned number of operations. However, all such events may not include depletion events in certain embodiments, such as when the counter is permanently stored and therefore recoverable even in the event of loss of access to the corresponding key. Please note that there is. Also note that depletion events can affect more than one security module. For example, affecting multiple security modules in a data center

Upon detection of a depletion event, a decision may be made whether the counter exceeds any of the thresholds associated with the depletion event 2710. The threshold can be a defined number of operations that are at least partially based on the mathematical properties of the cryptography used to perform the cryptographic operations. For example, in ciphertext using CBC mode, the number of operations is (1) the size of the keyspace divided by the product of the square of the length of the ciphertext represented in the block and (2) the number of ciphertexts. Or, at least in part, based on it. In ciphertext using CTR mode (such as AES-GCM), the number of operations is the keyspace divided by (1) the square of the ciphertext length in the block and (2) the number of ciphertexts. It can be of size, or at least partly based on it. If the counter is determined to exceed the threshold of any of the keys affected by the depletion event 2710, process 2700 has one or more security modules (ie, one or more security associated with the depletion event). Module) may include 2712 to acquire one or more new keys whose operation assignments are exhausted and to replace the affected key (s) with the new key (s). .. For example, if the security module goes offline temporarily (which causes a depletion event), and as a result the counters for KeyIDs (but not all KeyIDs) exceed the threshold, the security module will Acquire a new key as described above (for example, by creating a new key, accessing a pre-generated key from data storage, or acquiring a new key from another security module). Can be ordered. However, a security module that is different from the security module affected by the depletion event can be instructed to acquire a new key, such as when one security module is taken offline and a new security module is brought online. Please note that. Replacing the affected key (identified by the KeyID) with a new key means marking the affected key as a retirement, associating the new key with the KeyID (eg in the database), and the new key. May include marking as active. Replacing the affected key with a new key can also involve initializing the counter for the new key, which is maintained by the security module that replaces the affected key with the new key. It can be a pre-programmed value or a value obtained from the system running process 2700. Process 2700 may also include marking 2714 with the affected key (s) as retirement, the new key (s) as active, and updating the database accordingly. The system running process 2700 may not have access to the affected key and / or the new key (s), resulting in the affected key (s) being retired and new. Note that marking a key (s) as active can involve associating a key identifier with a value that indicates either retirement or new. It can also include 2714, which is marked (several) by activating it and updating the database accordingly. The system running process 2700 may not have access to the affected key and / or the new key (s), resulting in the affected key (s) being retired and new. Note that marking a key (s) as active can involve associating a key identifier with a value that indicates either retirement or new. It can also include 2714, which is marked (several) by activating it and updating the database accordingly. The system running process 2700 may not have access to the affected key and / or the new key (s), resulting in the affected key (s) being retired and new. Note that marking a key (s) as active can involve associating a key identifier with a value that indicates either retirement or new.

In one embodiment, at 2714 when marking 2710, if none of the affected keys is determined to have a counter above the threshold, process 2700 is still the active affected key (s). , And / or assigning additional key operations to any new key (s) obtained as a result of performing an operation in process 2700 may include 2716. Appropriate key usage counters (s) may be updated when assigning additional key operations, as described above.

As with all processes described herein, modifications are considered to be within the scope of this disclosure. For example, in some embodiments, the security module does not track their use of keys, but another component of cryptography or other services uses the keys to perform one or more operations. Update the counter for the key for each request submitted to any security module. In such an embodiment, for each key of a plurality of keys, a component of the security module tracks a request to perform an operation using the key (or, for example, successfully fulfills the request). The operations performed can be tracked by confirmation or other indicators) and the counters for the keys can be updated accordingly. When the counter reaches the threshold, the system that maintains the counter forces all appropriate security modules to retire the key and replace it with a new key (or has the security module with the key retire the key, 1). It can cause one or more other security modules to perform some other operation that causes key retirement), such as initiating the use of a new key. As another example of a variant that is within the scope of the present disclosure, in some embodiments, the security module is described above when the security module uses its assignment of keystrokes to cause the counter to exceed a threshold. So you can be ordered to get a new key. Other security modules may continue to use the key until they use their assignment. When a security module uses that assignment, it can acquire a new key that has been exchanged for a key in the security module that caused the counter to exceed the threshold. In other words, the security module may be allowed to exhaust those assignments of key operations before new keys need to be acquired.

FIG. 28 shows an exemplary representative of a database used to keep track of key usage. The database can be maintained by a suitable system, such as the system running process 2700. In the illustrated database, columns correspond to KeyIDs, key versions, usability, and counters. The KeyID and key version can be as described above. The value in the usability column is whether the key is retired or active (or whether the key has another state (if such other states are supported by the various embodiments of the present disclosure)). Can be shown. As illustrated in FIG. 28, the database has a column for each version of the key identified by the KeyID, including all retired and active versions. However, keep in mind that the database can lack all versions of the key. For example, a key can be permanently deleted from memory for a variety of security reasons. Deletion may be subject to, for example, customer request or policy enforcement.

As illustrated in FIG. 28, the illustrated database also includes a counter for each active key. Also, in this particular example, the database includes a counter for inactive keys (eg, showing the value of each key above a threshold, which results in a new key being acquired). However, the inactive key counter value may not be retained in some embodiments. Counters can be updated by the system that maintains the database when keystrokes are assigned to the security module. If the value of the counter column exceeds the threshold value, a new column may be added to the database to accommodate the new key for the counter to replace the over-threshold key.

Security modules may maintain similar databases for their own purposes. For example, when a security module can track its own use of a key, and the use of the key by the security module runs out of the number assigned to the security module, the security module, for example, performs additional operations on the security module. A process like process 2700 described above for either reassigning or forcing the security module to acquire a new key if a large number of key operations for which the key is available have been exhausted. Can notify the key rotation management component of a cryptographic service (or another service that uses a security module) that can perform.

The database used to track key usage can differ from that illustrated in Figure 28 and those described above. Additional information in the database, such as metadata associated with the key, such as time of generation, time of retirement, information about the user using the key, and / or other information that may be useful in various embodiments. Can be included. In addition, although relational tables are provided for exemplary purposes, other methods of storing data in support of various embodiments may be used.

The information used to enforce the policy can be obtained in various ways by cryptographic services. FIG. 29 shows an exemplary example of an environment 2900 in which the various embodiments of the present disclosure can be practiced. The components of Environment 2900 may include components such as those described above. For example, as illustrated, Environment 2900 includes a user interacting with a data service front end system (data service front end) through a user device, but interacts with the data service front end on behalf of the user. It may be any computer system configured in. Further, as illustrated, the environment includes a data service backend storage system and an authentication service, which may be as described above. In addition, the environment includes a cryptographic service called an internal cryptographic service in FIG. 29 to distinguish it from another cryptographic service referred to in the figure as an external cryptographic service. Either or both of the internal and external cryptographic services operate as cryptographic services, as described above. As with all environments described herein, modifications are considered within the scope of this disclosure. For example, FIG. 29 shows a user communicating with a data service front end, which can communicate with a cryptographic service without a data service front end, as described above.

Further included in Environment 2900 is, in certain embodiments, a computer system (eg, a computer or computer) that is configured to issue a message to one or more subscribers in response to a request from an internal cryptographic service. It is a message service that is a network). As discussed in more detail below, some requests can trigger components within Environment 2900 to act to use the message service to send messages about the request. For example, some data may be encrypted and stored under a key that has an associated policy that the response to a decryption request must be delayed by a specified amount of time. When a request to decrypt data is submitted, policy enforcement can result in delayed response and notifications sent by the messaging service. In this manner, the computer system that monitors the user or message may have the opportunity to submit a request to cancel the decryption request or have the decryption request canceled in another way during the delay. Message services include any suitable technology that can be used to send a message by email, short message service (SMS), telephone, pager, facsimile, and / or sending information from the message service to another entity. It may be sent to one or more subscribers using one or more technologies, not limited to these.

As illustrated in Figure 29, the request submitted to the data service front end may include key access annotations. For example, as shown, the GET request submitted by the user contains a key access annotation. Key access annotations may contain the information needed to enforce a policy by one or more components of Environment 2900. The key access annotation may include a digital signature generated using the key, or it may be provided separately. The key used to generate the signature can be a key shared between the user and the components of the environment 2900 that enforces the policy, or in some embodiments utilizing a public key digital signature scheme. , The key can be the user's private key, thereby making the signature verifiable using the corresponding public key. The components of the environment 2900 that enforces the policy can use digital signatures to verify the authenticity of the information in the key access annotations, and the information in the key access annotations can be used by the policy to fulfill the request. You can decide whether to allow it.

As illustrated in Figure 29, any of several components of Environment 2900 may receive key access annotations and use those key access annotations for enforcement in the policy. For example, the data service front end may pass the key access annotation to the internal cryptographic service along with the ciphertext and authorization certificate that can be used as described above. The internal cryptographic service can use key access annotations to validate policies on keys managed by the internal cryptographic service. In some embodiments, the key access annotation contains information that identifies another service, such as an external cryptographic service. The internal cryptographic service may provide a key access annotation to an external cryptographic service that may be one of multiple cryptographic services or another service that uses the key access cryptographic service when discovering information that identifies the external cryptographic service. However, such other services are not illustrated in Figure 29.

As mentioned above, keys managed according to various embodiments can be associated with policies that encode key usage restrictions and / or privileges. Other information related to policy enforcement can also be associated with such keys according to various embodiments. FIG. 30 shows an exemplary example of a key 3000 (such as a key managed by a cryptographic service, as described above) and an example of information that can be maintained in association with the key 3000 (eg, by a cryptographic service). .. As illustrated, policy information that encodes one or more policies for key 3000 is maintained in association with key 3000, as described above. In certain embodiments, the set of keys is also maintained associated with the key 3000 (eg, associated with the key 3000 by a database or other data storage system). The association can be maintained in any suitable manner. For example, a relation table or other mechanism may associate key 3000 directly with a key in a set of keys. As another example, a relational table or other mechanism may associate key 3000 with an identifier of a key in the set associated with key 3000 and / or a reference to a key in the set associated with key 3000. ..

For example, in some embodiments, one or more keys from the used key set and one or more keys from the management key set are maintained associated with key 3000. In certain embodiments, cryptographic services are configured such that the keys in the key set used are required in some embodiments to fulfill at least some requests. Specifically, in some embodiments, in a request to perform an operation using a key identified by a KeyID, the fulfillment of the request is probably used by the key access annotation, along with others. Electronic (ie, digital) by the key corresponding to the key in the key set (for example, any key in the used key set, or a key in the used key set specified or separately associated with it by the key access annotation). Requires to be signed. In the absence of such a signature, the request may be denied. The key corresponding to the key in the used key set can be a key in the used set or a reference to it, or a private key corresponding to the public key in the used key set (here, the public key and Private key is used in public key digital signature scheme).

In certain embodiments, the keys in the management key set are used for the purpose of modifying the set of keys associated with the key 3000. For example, in some embodiments, the keys corresponding to the keys in the management keyset were used in order to fulfill the request to modify either the usage keyset or the management keyset (or both). An electronic signature may be required. Modifications include adding keys to a keyset, removing keys from a keyset, exchanging keys in a keyset for another key, reassociating a key in a keyset with another entity, and / Or may include other modifications. In other words, in order to modify the used key set and / or the management key set, proof of access to the management key is required. The management key may also be used in a similar manner for other purposes, such as for policy modifications and / or other management actions applicable to key 3000. As illustrated in FIG. 30, the key 3000 can also be associated with an operation bitmask. The information bitmask can be information that encodes a set of operations in which the key 3000 can be used, such information can be encoded by a policy.

The use of various key sets associated with keys managed by security modules offers many technical benefits. For example, referring to Figure 30, if a key in the keyset associated with key 3000 is compromised, the keyset can be modified to prevent data hazards without the need to change key 3000. it can. As another example, a third party key can be used so that a single entity does not have both the ciphertext and the key needed to decrypt the ciphertext, so to access the plaintext. Requires collusion between entities.

FIG. 31 shows an exemplary representative of 3100 key access annotations according to an embodiment. In FIG. 30, key access annotation 3100 contains information related to policy enforcement related to the request containing the key access annotation. In this example, the key access annotations include a TimeStamp and an Operation Descriptor, a KeyHolderID, a KeyID, and a key identifier from the used or administrative keyset. It may contain less or more information.

In certain embodiments, the information in the key access annotation 3100 is used to determine if the request can be fulfilled. Specifically, in some embodiments, the information in the key access annotation 3100 meets one or more conditions (in addition to the presence of a digital signature) for the request to be fulfilled. There must be. For example, in some embodiments, the time stamp must indicate the time within some threshold amount of time when the request is received. As another example, the key access annotation must be in the operation count window, must approve a specific operation associated with specific data, or be enforced by the entity that received the key access annotation 1 One or more conditions must be met separately.

The KeyHolderID enables federated key management according to various embodiments of the present disclosure. With reference to FIG. 29, for example, the KeyHolderID can be information that identifies the key identified by the KeyID, or otherwise allows it to be identified. KeyHolderID can be used, for example, to provide key access annotations (eg, by forwarding a request containing annotations) to a uniform resource locator (URL), Internet Protocol (IP) address, or corresponding entity. Can be other information. In some embodiments, the KeyHolderID is encoded within the KeyID so that the recipient of the request can extract the KeyHolderID and, where appropriate, forward the request to the appropriate third party. Environment 2900's internal cryptographic service detects, for example, whether the KeyHolderID of a request specifies a different entity, and when it discovers a KeyHolderID that specifies a different entity, the request (or at least some other information based on the request). ) Can be configured to be forwarded to different entities, which may be external cryptographic services such as those described above (eg, cryptographic services of different computing resource providers). Different entities may utilize various embodiments of the present disclosure to determine whether to respond to a request and, where appropriate, provide a response to the request, which may be provided via cryptographic services. If the key access annotation lacks a KeyHolderID (or the KeyHolderID specifies an internal cryptographic service), the internal cryptographic service may fulfill the request itself, assuming compliance with policies and other requirements for fulfilling the request. ..

Figure 32 illustrates an exemplary process 3200 that can be used to enforce a policy in connection with a request submitted in connection with a key access annotation as described above. Process 3200 can be performed by any suitable device, such as a cryptographic service device involved in request processing (eg, a device that implements a front-end API for cryptographic services). The cryptographic service can be an internal or external cryptographic service as described above.

In certain embodiments, process 3200 comprises receiving a key access annotation 3202 in connection with the request. The key access annotation can be the annotation included with the request or can be received in some other way. For example, a request with a key access annotation can be processed, and as part of the processing, the key access annotation can be provided to a device running process 3200 (or a variant thereof). Upon receipt of the key access annotation, in certain embodiments, process 3200 comprises using the annotation to generate a reference signature, as described above. A decision can be made as to whether the reference signature matches the signature of the annotation 3206. In an alternative embodiment, process 3200, along with information that allows the security module to generate a reference signature and check whether the reference signature matches the signature of the key access annotation. Includes providing to the security module. In other words, determining whether the key access annotation signature is valid can be performed by obtaining such a decision from the security module.

If the reference signature is determined to match the signature of the annotation 3206, process 3200 may include accessing any policy associated with the KeyID specified in the request 3208. Assuming the policy exists for the KeyID, process 3200 involves determining whether the accessed policy allows the request to be fulfilled 3210. If the policy is determined to allow the request to be fulfilled 3210, process 3200 may include 3212 determining whether the KeyHolderID (as described above) identifies an external entity. Determining whether a KeyHolderID identifies an external entity 3212 can be performed in different ways according to different embodiments. For example, the absence of a KeyHolderID in a key access annotation can indicate a negative decision, while the presence of a KeyHolderID in a key access annotation can indicate a positive decision. As another example, the KeyHolderID may require a value that indicates either an internal entity (eg, an internal cryptographic service) or an external entity (eg, an external cryptographic service).

If it is determined that the KeyHolderID does not identify an external entity 3212, process 3200 may include performing the request 3214 as described above. However, if the KeyHolderID is determined to identify an external entity 3212, process 3200 includes forwarding the request to the identified external entity 3216, and receiving information that allows the request to be fulfilled accordingly. obtain. The information can be, for example, plaintext obtained by decrypting the ciphertext by an external entity and / or information that is at least partially based on the cryptographic operations performed by the external entity. Although not illustrated, other information may also be received in addition or as an alternative. For example, if an external entity independently decides not to allow the request to be fulfilled (for example, because the policy enforced by the external entity does not allow the request to be fulfilled), information indicating the refusal is provided. obtain. Assuming that the information that enables the request fulfillment is received 3216, the process may include fulfilling the request 3214, as described above. For example, the received information that enables the request to be fulfilled may be provided to the requester.

In addition to those expressly described above, modifications are also considered to be within the scope of this disclosure. For example, FIG. 32 illustrates verifying a digital signature and policy for a request, and then transferring the request (or at least partially based information) to an external entity. As with all processes exemplified herein, the order of operations may vary. For example, process 3200 may be modified so that the request is forwarded before any signature and / or policy validation is done. External entities may perform signature and / or policy validation in addition to or instead of the system running process 3200. For example, in some embodiments, the system performing the operations of Process 3200 does not perform signature and / or policy validation and delegates such validation to an external entity. In other embodiments, the system performing the operations of Process 3200 performs signature and / or policy validation, and the external entity performs additional signature and / or policy validation. External entities may have different keys and / or different policies, for example, where the request is checked before it is fulfilled.

The embodiments of the present disclosure also make use of techniques that provide enhanced data security. For example, despite best efforts, security breaches often occur in connection with various systems. To mitigate the effects of such violations, various embodiments of the present disclosure allow request processing in a manner that provides time to detect the violation and respond accordingly. For example, in some embodiments, decryption of encrypted data and / or access to the decrypted data requires a delay. Delays can be required, for example, by the configuration of the system or by the policies enforced by the system, where the policies are configured according to various embodiments described herein). Such delays to encrypted data, for example, regulation or other requirements require archiving of specific data, but not necessarily immediate availability of the data. It can be useful in situations where quick access is not required.

FIG. 33 shows an exemplary example of Process 3300 for providing such a delay according to various embodiments. Process 3300 may be performed by cryptographic services such as internal or external cryptographic services as described above. In one embodiment, process 3300 includes receiving a request to decrypt the ciphertext using the key identified by the KeyID 3302. The request can be received in any suitable manner. For example, the request may be received from a user or from a data service, as described above. In certain embodiments, the policy associated with the KeyID is accessed 3304. However, it should be noted that the policy may be enforced automatically in some embodiments, and as a result, the policy may not be accessed in some implementations. For the embodiment illustrated in FIG. 33, process 3300 includes determining whether the policy allows the fulfillment of the request 3306. Determining whether the policy allows request fulfillment 3306 can be performed in any suitable manner, as described above.

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

Upon initialization of the timer, process 3300 may include performing a check to see if the timer has expired until 3312, when it is determined that the timer has actually expired. In some embodiments, the request can be canceled prior to its fulfillment. Canceling a request may require less stringent requirements than the request to decrypt the information. For example, in some embodiments, the request may be self-evidently canceled by anyone with access to the system. As another example, the alarm action, when selected, comprises sending a message containing a hyperlink that, in some embodiments, causes the request to be canceled without authenticating the recipient of the message. obtain. Other methods that allow the request to be canceled may also be used. Thus, in one embodiment, once the timer expires (or at other times, such as before the timer expires), a determination can be made as to whether the request has been cancelled. If it is determined that the request has been canceled 3314, process 3300, for example, decrypts the ciphertext using the key identified by the KeyID and provides the resulting plaintext, or sends the ciphertext to the security module. It may include performing the request by having it decrypted and providing the corresponding plaintext and then forwarding the plaintext to the requester or providing access to the plaintext in another form. However, if it is determined that the request has not been canceled 3314, and / or if the policy is determined not to allow the request to be fulfilled 3306, process 3300 rejects the request, as described above. May include.

Many other variants are within the scope of this disclosure. For example, in some embodiments, the key is associated with a policy that specifies a valid date, or another policy that indicates some determined validity period that is not indefinite. For example, in some embodiments, the key may be associated with a policy that specifies that the key should be destroyed after a period of time, on a particular day, or when one or more conditions are met. As an example, organizational and / or governmental rules, laws, policies, or regulations may specify that data should be retained for a period of time. A policy on the key used to encrypt such data (for example, encrypt the key used within the cipher for encrypting the data, or another key under which the data is encrypted. The key used in the ciphertext to make it is that the key should be destroyed (ie, irrevocably inaccessible to anyone) when the required time is exceeded. Can be specified. Cryptographic services or other systems can detect the time required and destroy the key accordingly. Cryptographic services can detect overtime required in many ways. For example, in some embodiments, the cryptographic service maintains a database in which information indicating the time for key destruction is stored. Periodic processes performed by cryptographic services can destroy keys that appear to be destructible in the database.

The policy effective date can also be used in other ways. For example, the time delay enforced for decrypting data can change over time. For example, as the data encrypted under the key becomes obsolete, the time delay enforced to decrypt the data can be reduced. As another example, a principal may have the privilege of performing cryptographic operations using a key only for a specified period of time that may be updatable via the cryptographic service API. In this context, the ability of an individual to perform cryptographic operations in association with a key can automatically expire.

In some embodiments, the request may be made for another purpose in addition to or as an alternative to the request for decrypting the ciphertext. For example, the various techniques described above may be suitable for different types of policy enforcement. For example, the policies used in connection with the various embodiments of the present disclosure may utilize the effective time of the policy. Policy updates can have a valid time that indicates a future time in which the policy update will take effect in the system that enforces the policy. Existing policies may require that some or all policy changes be tolerable under certain conditions, one of which is the time the policy update is specified (eg, for example). , 48 hours). The request may be made to change the policy to allow the data to be retrieved, which may be involved in the decryption of the data. The requirement can be, for example, a requirement to weaken the conditions that need to be met before the data can be retrieved. The request can specify the effective time of the policy change. A system that enforces a policy in relation to the principal to which the policy applies may approve or deny the request, at least in part, based on whether the validity time complies with the existing policy. If the system approves the policy change, the system may start a timer (which may be at least partially based on time-to-live) and run an alarm process as described above. In addition, policy changes can be canceled until the request is fulfilled, as described above. In this manner, stakeholders may be provided with opportunities to prevent unauthorized access to notifications and data.

Other variants are also considered to be within the scope of this disclosure. For example, in some embodiments, the data storage system is unique for request processing, sufficient to cancel the request and / or provide time to otherwise prevent a potential security breach. It can have the latency of. For example, an archive data storage system may utilize asynchronous request processing, where the data responding to the request may be available hours after the request is submitted. In addition, the data that responds to the request may be available after different amounts of time, which may depend on factors such as the system. In such systems, timers can be unnecessary due to the inherent latency. The embodiments of the present disclosure can be described with reference to the following appendices. 1. A computer implementation method under the control of one or more computer systems consisting of executable instructions. Receiving a request from a requester to perform a cryptographic operation, the request containing information and, at least in part, an electronic signature generated based on the information, the electronic signature being the second key. Receiving, which can be verified with the first key of one or more corresponding sets of keys, and detecting whether the request specifies a key owner among multiple key owners. As a result of the request detecting a specific key owner among a plurality of key owners, the digital signature is valid for the specific key owner, at least in part, based on the information and the first key. And, at least in part, based on the information, to determine if the information meets one or more conditions for fulfilling the request, and by a particular key owner, the electronic. The signature is valid, and as a result of determining that the information satisfies one or more conditions, the response information is to obtain the response information necessary for fulfilling the request from a specific key owner. Obtaining and being generated, at least partially based on one or more cryptographic operations performed using the second key, A computer implementation method that includes providing a response to a request to a requester using the obtained response information. 2. The computer implementation method described in Appendix 1, where a particular key owner is a computer system hosted by a third party. 3. The set of one or more keys corresponding to the second key contains a plurality of keys, and each key of the plurality of keys verifies that the conditions required for fulfilling the request are satisfied. The computer implementation method described in Appendix 1 or 2, which can be used in. 4. Receiving a second request to perform a cryptographic operation, the second request containing a second piece of information and, at least in part, a second digital signature based on the second piece of information. electronic signature one or more corresponding to the fourth key can be verified by a third key in the second set of keys on a receiving, at least partially the second information and the third Determining whether a second digital signature is valid based on the key of, and at least partly based on the second information, one or more for the information to fulfill the second request. Determining if the second condition is met and One for fulfilling the second request using the fourth key as a result of determining that the second digital signature is valid and the second information meets one or more second conditions. The computer implementation method according to any one of Appendix 1 to 3, further comprising performing the above cryptographic operation. 5. The computer implementation method described in any one of Appendix 1-4, wherein one or more conditions for fulfilling the request are defined by one or more policies corresponding to the second key. 6. The computer implementation method according to any one of Appendix 1 to 5, wherein the second key is inaccessible to one or more computer systems in clear text form. 7. Computer implementation, under the control of one or more computer systems consisting of executable instructions, information and electronic signatures in connection with a request, at least in part, at least part of that information. As a result of receiving, detecting the owner of the second key specified in the information from multiple key owners, and detecting the owner of the second key based on To the owner of the key of 2 As a result of having the digital signature determine whether it is valid and the signature valid, at least in part, based on a portion of the information and the first key associated with the second key. Performing a request using the second key to perform one or more cryptographic operations and using one or more results of one or more ciphers obtained from the owner of the second key. That and, including, methods. 8. The first key is an element of one or more key sets that correspond to the second key, and each key in one or more key sets is valid for the corresponding request to be fulfilled. The computer implementation method described in Appendix 7, which can be used to verify electronic signatures that are required to be. 9. The computer implementation method described in Appendix 7 or 8 where the owner of the second key is a third party. 10.1 The computer implementation method described in any one of Appendix 7-9, wherein one or more computer systems lack access to the second key in clear text. 11. The information further comprises one or more values, and the method further comprises determining whether one or more values satisfy one or more conditions. The computer implementation method according to any one of Appendix 7 to 10, wherein fulfilling the request depends on determining that one or more values satisfy one or more conditions. 12. The computer implementation method described in any one of Appendix 7-11, wherein the owner of the second key is one or more computer systems. 13. When a system is executed by one or more processors and a memory is executed by one or more processors, the computer system stores one or more sets of keys associated with the first key. Let me As a result of having a request that requires the use of the first key to be performed and the first key being held by a third party, the third party is forced to use a second set of one or more keys. Use the key to determine if the request should be fulfilled, and as a result of deciding that the request should be fulfilled, use the first key to perform one or more cryptographic operations. A system with memory, including instructions. 14. The system described in Appendix 13 where the owner of the first key is a third party system. 15. The system described in Appendix 13 or 14, wherein one or more sets of keys contain a subset of management keys, each of which can be used for digital signature verification required to modify one or more sets of keys. 16. The system described in any one of Appendix 13-15, wherein the system is hosted by an entity and the entity lacks access to the first key in clear text. 17. The system described in any one of Appendix 13-16, where the request specifies the first key. 18. Using a second key from one or more sets of keys to determine if a request should be fulfilled is a digital signature submitted in connection with the request using the second key. The system according to any one of Appendix 13 to 17, wherein the system comprises detecting. 19.1 One or more computer-readable storage media, when executed by one or more processors in a computer system, causes the computer system to associate one or more sets of keys with the first key and one or more. The second key from said set of keys is used to allow the fulfillment of the request by at least having the owner of the first key use the first key in one or more cryptographic operations. A computer-readable storage medium that stores instructions there, letting you decide whether or not. 20. One or more computer-readable storage media described in Appendix 19, in which the owner of the first key is a third party. twenty one. The request is submitted in connection with the request information, and the instruction further causes the computer system to verify that one or more conditions for the request information are met, and the fulfillment of one or more conditions enables the request to be fulfilled. One or more computer-readable storage media, as described in Appendix 19 or 20, required to do so. 22. One or more sets of keys contain a subset of management keys, and each management key in the subset of management keys can be used to determine whether to fulfill a request to change one or more sets of keys. One or more computer-readable storage media according to any one of Appendix 19-21. 23. One or more computer-readable storage media described in Appendix 22, where changing one or more sets of keys involves adding or removing keys from one or more sets of keys. 24. One or more computer-readable storage media described in any one of Appendix 19-23, wherein the request is submitted in connection with the information that identifies the owner of the first key. 25. One or more computer-readable storage media described in any one of Appendix 19-24, in which the owner of the first key is the computer system.

FIG. 34 illustrates aspects of 3400 environmental examples for implementing embodiments that follow various embodiments. As will be appreciated, a web-based environment is used for explanatory purposes, but different environments can also be used to implement various embodiments as needed. The environment can include any suitable device that can be manipulated to send and receive requests, messages, or information over the appropriate network 3404 and return the information to the user of the device, electronic client device 3402. Including. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, set-top boxes, personal digital assistants, electronic book readers and the like. The network can 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 in such a system may at least partially depend on the type of network and / or environment selected. Protocols and components for communication over such networks are well known and are not discussed in detail herein. Communication over the network may be enabled by wired or wireless connections, and combinations thereof. In this example, the network includes the Internet because the environment includes a web server 3406 for receiving requests and delivering content accordingly, but other networks provide alternative devices that serve similar purposes. It will be apparent to those skilled in the art that it can be used.

An exemplary environment includes at least one application server 3408 and data store 3410. Some application servers, layers, or other elements that can be concatenated or configured in different ways and can interact to perform tasks such as getting data from the appropriate data store. It should be understood that a process, or component, can exist. As used herein, the term "data store" refers to any device or combination of devices capable of storing, accessing, and retrieving data, in any standard, distributed, or clustered environment. It may include any combination and number of data servers, databases, data storage devices, and data storage media. The application server can include any suitable hardware and software to integrate with the data store as needed to perform one or more application aspects for the client device, and the application data access. And handle most of the business logic. The application server can work with the data store to provide access control services and generate content such as text, graphics, audio, and / or video that is sent to the user, which are hypertext markup. It may be supplied to the user by a web server in the form of a language ("HTML"), an extended markup language ("XML"), or another suitable structured language in this example. The processing of all requests and responses, as well as the delivery of content between the client device 3402 and the application server 3408, can be processed by the web server. The structured codes discussed herein can be run on any suitable device or host machine as discussed elsewhere in the specification, so no web and application server is required, just an example. Please understand that it is a component of.

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

Each server typically includes an operating system that provides executable program instructions for general management and operation of the server, typically when executed by the server's processor, the server intends to do so. Includes 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 being performed. Suitable implementations of the general functionality of operating systems and servers 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 according to or under one or more verification regimes, such as Evaluation Guarantee Level (EAL) Level 4.

The environment in one embodiment is a distributed computing environment that utilizes components interconnected via several computer systems and communication links using one or more computer networks or direct connections. However, one of ordinary skill in the art will appreciate that such a system can operate equally well in a system with fewer or more components than illustrated in FIG. As such, the description of System 3400 in FIG. 34 should be considered exemplary in nature and is not limited to the scope of this disclosure.

Various embodiments can also be implemented in a wide variety of operating environments and, in some cases, used to operate one or more user computers, computing devices, or a large number of applications. It may include processing devices that can. The user or client device is a desktop or laptop computer running a standard operating system, as well as a number of general purpose personal computers such as mobile, wireless, and handheld devices that can run mobile software and support a number of networking and messaging protocols. It can include any of the computers. Such a system can also include a number of workstations running any of a number of off-the-shelf operating systems and other known applications for purposes such as development and database management. These devices can also include other electronic devices such as dummy terminals, thin clients, gaming systems, and other devices that can communicate over the network.

Most embodiments include Transmission Control Protocol / Internet Protocol ("TCP / IP"), Open System Interconnection ("OSI"), and File Transfer Protocol ("OSI"). Transfer Protocol ("FTP"), Universal Plug and Play ("UpnP"), Network File System ("NFS"), Common Internet File At least one network well known to those skilled in the art to assist using any of a variety of commercially available models and protocols, such as System) ("CIFS"), and AppleTalk. Use. 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.

In an embodiment using a web server, the web server is a Hypertext Transfer Protocol ("HTTP") server, an FTP server, a common gateway interface (Common Gateway). It can operate any of a variety of servers or middle-tier applications, including Interface) ("CGI") servers, data servers, Java servers, and business application servers. The server (s) are also written in any programming language such as Java®, C, C #, or C ++, or any scripting language such as Perl, Python, or TCL, and combinations thereof. It may also be possible to run a program or script in response to a request from a user device, such as by running one or more web applications that may be implemented as one or more scripts or programs. Servers (s) may also include database servers, including but not limited to those commercially available from Oracle®, Microsoft®, Sybase®, and IBM®. ..

The environment can include various data stores and other memory storage media, as described above. These are in a variety of locations, such as on a storage medium that is local to (and / or resides in) one or more of the computers, or remote from any or all of the computers throughout the network. Can exist in. In a particular set of embodiments, the information may reside within a storage area network ("SAN") well known to those of skill in the art. Similarly, any required file for executing a function belonging to a computer, server, or other network device may be stored locally and / or remotely, as needed. If the system includes computerized devices, each such device can include a hardware element that can be electronically connected via a bus, which element is, for example, at least one central processing unit ("CPU"). "), 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 also include solid-state storage devices such as disk drives, optical storage devices, random access memory ("RAM") or read-only memory ("ROM"), as well as replaceable media devices, memory cards, flash cards, etc. Can also include one or more storage devices. 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.

Such devices can 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 contains, stores, transmits, computer-readable storage media, which means remote, local, fixed, and / or interchangeable storage devices, as well as temporarily and / or more permanently computer-readable information. And can be connected to or configured to receive storage media for acquisition. The system and various devices are also typically located within a number of software applications, modules, services, or at least one working memory device, including operating systems and application programs such as client applications or web browsers. Also includes elements. It should be understood that alternative embodiments may have numerous variations from those described above. For example, customized hardware may 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.

The storage medium and computer-readable medium for containing the code or a portion of the code may be RAM, ROM, electronically erasable programmable read-only memory ("EEPROM"), flash memory, or the like. Memory technology, compact disc read-only memory (Compact Disc Read-Only) Used to store Memory) ("CD-ROM"), digital versatile disks (DVDs), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, or other magnetic storage devices, or desired information. Storage and / of information such as, but not limited to, computer-readable instructions, data structures, program modules, or other data, including, but not limited to, any other medium that can be and can be accessed by the system device. Also known or used in the art, including storage and communication media such as volatile and non-volatile, convertible and non-commutable media implemented by any method and technique for transmission. Any suitable medium can be included. Based on the disclosures and teachings provided herein, one of ordinary skill in the art will understand other means and / or methods for implementing various embodiments.

The present specification and drawings are therefore considered to be exemplary rather than restrictive. However, it will be clear that various modifications and modifications can be made without departing from the broader intent and scope of the invention described in the claims.

Other modifications are within the spirit of this disclosure. As such, the disclosed techniques are susceptible to various modifications and alternative configurations, but specific exemplary embodiments are shown in the drawings and described in detail above. However, there is no intention to limit the present invention to the specific form (s) disclosed, and conversely, all purposes and scope of the present invention as defined in the appended claims. It should be understood to cover modifications, alternative configurations, and equivalents.

The use of the terms "a", "an", and "the" and similar directives in the context of describing the disclosed embodiments (particularly in the context of the claims below) is otherwise provided herein. Unless instructed to do so, or as clearly contradictory to the context, it is construed to cover both singular and plural. The terms "comprising," "having," "including," and "containing" are unrestricted terms (ie, "including," unless otherwise stated. , Not limited to that). The term "connected" is to be construed as being contained, attached to, or joined together, in part or in whole, even if there is an intervening object. The enumeration of a range of values herein is intended to serve simply as a simplified way of referencing each distinct value within that range individually, unless otherwise indicated herein. Each distinct value is incorporated herein as if it were listed individually herein. All methods described herein may be performed in any suitable order unless otherwise indicated herein or which is clearly inconsistent with the context. The use of any and all examples, or exemplary languages (eg, "etc.") provided herein is intended merely to better clarify embodiments of the invention and is otherwise claimed. Does not impose any restrictions on the scope of the invention unless. No wording herein should be construed as indicating that any unclaimed element is essential to the practice of the present invention.

Preferred embodiments of the present disclosure are described including the best embodiments known to the inventors to practice the invention. Modifications of those preferred embodiments may be apparent to those skilled in the art by reading the above description. The inventors anticipate that those skilled in the art will use such modifications as needed, and the inventors in a manner different from that specifically described herein. Intended to be implemented. Accordingly, the present invention includes all modifications and equivalents of the subject matter listed in the claims attached herein, as permitted by applicable law. Furthermore, any combination of the above elements, in all possible variations thereof, is included by the present invention unless otherwise indicated herein or otherwise clearly inconsistent with the context. To.

All references, including publications, patent applications, and patents cited herein, are individually and specifically indicated so that each reference is incorporated by reference, and the entire reference is described herein. To the extent that it is incorporated herein by reference.