Key derivation method and system and non-transitory computer-readable storage medium

Abstract

A computer system performs cryptographic operations as a service. The computer system is configured to allow users of the service to maintain control of their respective cryptographic material. The computer system uses the inaccessible cryptographic material to encrypt the user's cryptographic material in a token that is subsequently provided to the user. The user cannot access a plaintext copy of the cryptographic material in the token, but can provide the token back to the service to cause the service to decrypt and use the cryptographic material.

Description

[0001] Description of the case

[0002] This application is a divisional application of the invention patent application with application date of March 25, 2016, application number 201680023756.5, and invention name “Key derivation method and system and non-temporary computer-readable storage medium”.

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application incorporates by reference the entire disclosure of U.S. Patent Application No. 14 / 675,614, filed on March 31, 2015, and entitled “Key Derivation Technology,” for all purposes. Background Art

[0005] For many data users, the security of data is very important in many cases. Many technologies such as encryption have been well developed to ensure the security of data, such as by preventing unauthorized entities from obtaining data in plain text. At the same time, computer systems have become more and more complex as the needs of organizational development. For example, organizations often use networks of computing devices to provide a set of powerful services to their users. Networks often span multiple geographical boundaries and are often connected to other networks. For example, an organization may use an internal network of computing resources and computing resources managed by others to support its operations. For example, an organization's computers can communicate with computers of other organizations to access and / or provide data when using the services of another organization. In many cases, organizations use hardware managed by other organizations to configure and operate remote networks, thereby reducing infrastructure costs and achieving other advantages. It can be challenging to use such a configuration of computing resources to ensure that access to resources and the data they hold is secure, especially as the scale and complexity of such a configuration grows.

[0006] To assist organizations in developing complex computer systems to support their operations, many organizations have begun hosting computing resources as a service. For example, computing resource services may be hosted to perform various operations on behalf of customers, such as computation, data storage, advanced data storage (e.g., using databases), network services (e.g., hosting computer networks), etc. While such services offer many advantages to customers of the service provider (e.g., the ability to build computing resources without a large capital investment), customers often worry that the data may be accessed by other entities, regardless of the substantial efforts made by the service provider to protect its customers' data. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0008] Figure 1Figures illustrating various aspects of the present disclosure are shown;

[0009] Figure 2 Illustrative examples of environments in which various embodiments may be practiced are shown;

[0010] Figure 3 shows illustrative examples of data structures according to embodiments;

[0011] Figure 4 shows an illustrative example of an exported key token according to an embodiment;

[0012] Figure 5 shows an illustrative example of a process for fulfilling a request for a derived key token according to an embodiment;

[0013] Figure 6 An illustrative example of a process for fulfilling a request to perform one or more cryptographic operations using a derived key token is shown according to an embodiment;

[0014] Figure 7 shows an illustrative example of a process for rotating derived domain keys according to an embodiment;

[0015] Figure 8 An illustrative example of a process for fulfilling a request to perform one or more cryptographic operations according to an embodiment is shown;

[0016] Fig. 9 shows an illustrative example of a process for fulfilling a request to extend the life of a derived client key, according to an embodiment;

[0017] Fig.10 shows an illustrative example of a process for fulfilling a request to convert an exported customer key to an escrow customer key, according to an embodiment;

[0018] Fig.11 showing an illustrative example of a process for fulfilling a request to convert an escrow customer key to a derived customer key, according to an embodiment; and

[0019] Fig.12 An environment is shown in which various embodiments may be implemented. DETAILED DESCRIPTION

[0020] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details will be set forth in order to provide a thorough understanding of each embodiment. However, it will also be apparent to those skilled in the art that each embodiment may be practiced without the specific details. In addition, in order not to obscure the described embodiments, well-known features may be omitted or simplified.

[0021] The technology described and suggested herein includes operating a distributed computer system using an application programming interface (API) that allows a service provider's customers to utilize cryptographic services while limiting the service provider's access to cryptographic keys provided to customers. In an embodiment, the service provider operates a cryptographic service that performs cryptographic operations (e.g., encryption, decryption, and digital signature generation and verification) on behalf of the customer. The cryptographic service can utilize dedicated hardware such as a hardware security module to ensure the security of the data performing the cryptographic operations and the cryptographic keys used to perform the cryptographic operations. In some examples, the API of the service provider's cryptographic service is configured to enable submission of requests involving cryptographic keys to which the service provider has limited access.

[0022] For example, in an embodiment, the API is configured such that a request (e.g., a web service request) can specify a cryptographic key to be utilized in a variety of ways in performing a cryptographic operation. In one example, a request to perform a cryptographic operation includes an identifier of a cryptographic key managed by a cryptographic service (an escrow customer key is also referred to as a managed customer key). In another example, a request to perform a cryptographic operation includes a token (referred to as an export key token) that includes an encrypted copy of the cryptographic key used to perform the cryptographic operation, wherein the copy of the cryptographic key can be decrypted using another cryptographic key (referred to as a wrapping key or export domain key) that is maintained as a secret within one or more devices (e.g., a hardware security module or other device that provides hardware-based protection of cryptographic material) at a service provider.

[0023] In order to process a request to perform one or more cryptographic operations, the service provider may obtain a cryptographic key specified in the request. In the example of a request that specifies an escrow customer key, the service provider may obtain an encrypted copy of the specified escrow customer key from a data storage device and provide the encrypted copy of the specified escrow customer key to the hardware security module for decryption and execution of the requested cryptographic operation. In the example of a request that includes or otherwise specifies an export key token, the export key token may be provided to the hardware security module for decryption of the export key token to obtain the customer key and to execute the requested cryptographic operation. At least in the example where the request specifies an export key token, once use of the customer key has been completed (e.g., as a result of providing a response to the request), the service provider may be unable to access the customer key obtained from the export key token, thereby preventing the service provider from accessing the customer key unless provided in another communication (e.g., a request) that includes the export key token or another export key token that includes the customer key. Note that the inability to access the customer key may include the inability to access any information from which the customer key can be determined, such as the export key token.

[0024] In various embodiments, the cryptographic service uses at least two classes of domain keys, one for escrow customer keys and the other for exporting customer keys. In this way, different classes of domain keys can be rotated according to different rotation schedules (e.g., replaced to avoid cryptographic key exhaustion). For example, because the service provider has access to the escrow customer keys (each key can be stored encrypted under the current domain key), the service provider can rotate the domain keys more frequently than the export domain keys without causing the loss of customer data. Specifically, the service provider can access the encrypted customer keys, decrypt the customer keys using the expired domain keys, encrypt the customer keys using the new domain keys, and store the encrypted customer keys. However, for exporting customer keys, if the customer does not provide an export key token for re-encrypting the new export domain key, the rotation of the export domain keys may cause the loss of customer data.

[0025] In various embodiments, different rotation arrangements for different classes of domain keys enable flexible operation of cryptographic key usage periods. In some implementations, the API of the cryptographic service allows customers to specify a usage period for exporting customer keys. In addition, the service provider can maintain a set of export domain keys, each with a different expiration. The service provider can use an export domain key from a set of export domain keys maintained that matches the usage period specified by the customer to encrypt the customer key to be provided to the customer in the export key token. Once the export domain key expires and is no longer accessible to the service provider, the export key token is no longer available to the service provider to decrypt the export key token, and therefore the export key token can no longer be used to obtain the customer key. In this way, customers can ensure that data is only accessible for a limited time. Other changes are also considered to be within the scope of the present disclosure.

[0026] Figure 1 An illustrative example of an environment 100 is shown in which various embodiments may be practiced. Figure 1 , an environment 100 is presented to illustrate interactions between customers 102 of a service provider 104. A service provider may be an entity that operates a computer system, which may be a distributed computer system, and is configured to provide one or more services, such as cryptographic services described in more detail below. In some examples, the service provider 104 provides other services in addition to cryptographic services, such as services classified as infrastructure as a service, in which the service provider hosts hardware that can be remotely and programmatically managed by the service provider's customers. Note that while a service provider and a service provider's customers are used for illustrative purposes, the techniques described herein may be applicable to other situations where there is no customer / service provider relationship.

[0027] exist Figure 1In the example of FIG. 1 , in an embodiment, customer 102 receives key token 106 from service provider 104. Key token 106 may be a structured collection of information including a cryptographic key that is not decryptable by customer 102 (i.e., not decryptable without special computational effort). Other information such as one or more identifiers may be included in key token 106. Figure 4 Key tokens are discussed in more detail in Figure 1 In the example shown, the key token is generated at least in part within a hardware security module in the hardware security module 108 team of the service provider 104 or another device that provides hardware-based cryptographic material protection, such as described in more detail below. It should be noted that although the hardware security module (HSM) is used entirely for illustrative purposes, other devices that provide hardware-based cryptographic material protection may also be used. Examples of such devices include a trusted platform module (TPM) and a processor that includes secure execution in an environment of a specified address space such as a processor utilizing Intel SafeGuard Extension (SGX) technology.

[0028] The hardware security module involved in generating the key token 106 can generate a cryptographic key for the client 102, and use another cryptographic key (called a domain key) securely maintained in the hardware security module team 108 to encrypt the cryptographic key. For example, each security module in a set of security modules can maintain the domain key as information that is not programmatically exportable. If there is no legal way to programmatically (e.g., through the interface of the device) to make the device provide information, then the information can be said to be programmatically non-exportable. For example, information can be maintained so that there is no request mechanism (e.g., an application programming interface (API) call) for causing the hardware to access the information in plain text so as to reveal the information in plain text. As an example, the security module can be configured to lack the ability to provide a copy of some or all of its memory so that this copy includes information in plain text. However, it should be noted that although for the purpose of illustration, information that there is no legal way to obtain information in plain text is used throughout the disclosure, some information can be maintained so that the information can be obtained through a limited number of authorized uses, which may require the use of various security protocols and can prevent unauthorized access to information in plain text. Typically, programmatically non-exportable information is information (e.g., one or more cryptographic keys) that, if obtained in plain text at all, would require special steps to obtain the information in plain text. Thus, absent extraordinary computational effort, a device lacking access to the domain key used to encrypt the cryptographic key within key token 106 for client 102 is unable to obtain in plain text the cryptographic key within key token 106.

[0029] Having received key token 106 from service provider 104, the customer may maintain a copy of key token 106 in customer-managed storage 110. Storage 110 may be, for example, a storage device in a private network managed by customer 102, or generally any storage device over which the customer has control, or over which an entity other than the customer has control for the benefit of customer 102.

[0030] Client 102 can interact with service provider 104 to utilize its stored key token 106. To this end, Figure 1 In the illustrated embodiment, the client 102, via a computer device, provides a copy of the key token 106 in a request 112 to perform one or more cryptographic operations on data 114. The request 112 may be, for example, a web service request configured to cause the service provider 104 to perform one or more cryptographic operations required to fulfill the request 112. The data 114 may be any data that the client 102 wishes to have operated on by the service provider 104 by performing one or more cryptographic operations. In one example, the data 114 is a cryptographic key used by the client 102 to encrypt other data. However, the scope of the present disclosure is not limited to the data 114 being a cryptographic key.

[0031] To process request 112, service provider 104 may provide key token 106 or a portion thereof including the encrypted cryptographic key of customer 102 to a hardware security module in hardware security module 108 that has access to a copy of a domain key that can be used to decrypt the encrypted cryptographic key. The hardware security module may decrypt the cryptographic key to obtain a copy of the cryptographic key in plain text, and may use the copy of the cryptographic key in plain text to perform the requested one or more cryptographic operations on data 114. Figure 1 In this particular example of , data 114 is provided to service provider 104 in plain text, and the service provider, and in particular the service provider's hardware security module, performs cryptographic operations on data 114 to obtain encrypted data 116, which service provider 104 provides back to customer 102. However, it should be noted that although in Figure 1 Encryption is used in and elsewhere herein, but other cryptographic operations may be requested and subsequently performed. Such operations include, for example, decryption of encrypted data generated by a digital signature and verification of a digital signature and related operations, such as verification of the authenticity of a digital certificate.

[0032] Figure 2204. The present disclosure may be practiced in an environment 200 that is illustrative of various embodiments of the present disclosure. In an embodiment, a client 202 may use a computing device to communicate with a computing resource service provider 206 over a network 204. For example, the communication between the computing resource service provider 206 and the client 202 may be for the purpose of accessing a service 208 operated by the service provider 208, which may be one of a plurality of services operated by the service provider 206. The service may be a cryptographic service, such as described in more detail in U.S. Patent Application No. 13 / 764,963, filed on February 12, 2013, entitled “Data Security Services” and / or U.S. Patent Application No. 14 / 486,741, filed on September 15, 2014, entitled “Distributed System Network for Trust Provisioning”, which are incorporated herein by reference.

[0033] The service 208 may include a service front end 210 and a service back end 214, which may be a component of a service configured to receive an authorization request from the service front end 210 and configured to perform an operation that performs such a request. The principal 202 may send a request to access the service 208 provided by the computing resource service provider 206 (and / or a request to access resources associated with the service 208). The request may be, for example, a web service application programming interface request. The principal may be a user or a group of users or a role associated with a group of users, or may represent a process that may be one or more of these entities running on one or more remote (relative to the computing resource service provider 206) computer systems, or may be some other such computer system entity, user or process. Typically, the principal is an entity corresponding to an identity managed by a computing resource service provider, wherein the computing resource service provider manages the permission to the identity.

[0034] The principal 202 may correspond to an identity managed by a computing resource service provider 206 (such as by a policy management service or another service). The identity may be one of a plurality of identities managed for an account of a customer of the computing resource service provider, and the computing resource service provider may manage accounts of multiple customers. It should be noted that although the principal 202 may correspond to a person, such a person may communicate with the computing resource service provider 206 through a suitably configured computing device, which may perform operations (e.g., generate and transmit requests) on behalf of the principal 202. The principal 202 may communicate with the computing resource service provider 206 through one or more connections (e.g., a transmission control protocol (TCP) connection). The principal 202 may use a computer system client device to connect to the computing resource service provider 206. The client device may include any device capable of connecting to a computer system through a network, such as the exemplary device discussed below. The network 204 may include, for example, the Internet discussed below or another network or a combination of networks.

[0035] Computing resource service provider 206 can provide access to one or more computing resources through service 208, such as virtual machine (VM) instance, automatic scaling group, file-based database storage system, block storage service, redundant data storage service, data archiving service, data warehousing service, user access management service, identity management service, content management service and / or other such computer system services. Other exemplary resources include, but are not limited to, user resources, policy resources, network resources and / or storage resources. In some examples, the resources associated with the computer service can be a physical device, a virtual device, a combination of physical and / or virtual devices, or other such device implementation schemes. It should be noted that such services and resources are provided for illustrative purposes, and the embodiments of the present disclosure can utilize other services and / or resources.

[0036] A request for accessing service 208, which in some examples is a web service application programming interface request (also referred to as a web service request), can be received by service front end 210, which includes a web server in some examples, and the web server is configured to receive such requests and process the request according to one or more policies associated with service 208. The request for accessing service 208 can be a digitally signed request, and therefore a digital signature can be provided. Service front end 210 can then send the request and the digital signature for verification to authentication service 216. Authentication service 216 can be an independent service, or can be part of a service provider or other entity. In an embodiment, authentication service 216 is a computer system configured to perform operations involving authenticating a principal. In some examples, the request submitted to service front end 210 is digitally signed by a principal (i.e., a computing device used by or operated on behalf of a principal) using a symmetric cryptographic key shared between principal 202 and authentication service 216. Therefore, the authentication service can use a copy of the symmetric cryptographic key to verify the digital signature of the request claimed to have been generated by principal 202. However, in other embodiments, the authentication service 216 can be configured to utilize asymmetric cryptography for digital signature verification, such as when the client digitally signs the request using a dedicated cryptographic key. In such embodiments, the authentication service can be configured to trust the certificate authority that digitally signs the certificate of the client 202 corresponding to the dedicated cryptographic key. Therefore, in some embodiments, the authentication service can use the public cryptographic key specified by the certificate. Typically, the authentication service can utilize a cryptographic key that is registered with the authentication service 216 associated with the client 202.

[0037] After a successful authentication request, the authentication service 216 can then obtain a policy applicable to the request. A policy (also referred to as an access control policy) is a collection of permissions associated with a user, group, role, organization, company, or some other such entity. Each permission can be associated with a computing resource and can specify whether an entity (also referred to herein as a "principal") can access the resource, under what conditions access can be allowed or denied, and / or what type of access can be allowed or denied. For example, a permission can specify that a user named "user 1" can access a certain data storage device represented by identifier "12345". A more detailed permission can specify that user 1 can only read from resource 12345, but can not write to resource 12345. Still more detailed permissions can specify that user 1 can read from resource 12345 at any time, but can only write to resource 12345 between the hours between 9:00 and 9:30AM. Permissions can also be associated with a class or set of resources, so that, for example, user 1 can access a set of data storage devices, one of which can be resource 12345. Access control policies may be maintained by a policy management service as a policy document, a record in a database, an access control list (ACL), etc. A service (eg, service 208) may maintain its own policies in addition to or instead of a policy management service.

[0038] The policy may be applicable to the request by being associated with the principal 202, the resources accessed as part of fulfilling the request, the group of which the principal 202 is a member, the role assumed by the principal 202, and / or the like. To obtain the policy applicable to the request, the authentication service 216 may send a query to a policy repository 218 managed by a policy management service 220, which may be a combination of the above. Figure 1 The query may be a request that includes information sufficient to determine a set of policies that apply to the request. For example, the query may include a copy of the request and / or include parameters based at least in part on information in the request, such as information identifying a principal, a resource, and / or an action (an operation to be performed as part of fulfilling the request). A policy repository, which may be a database or other system operable to process queries, may process the query by providing any policies that apply to the request. Note that if authentication of the request is unsuccessful (e.g., because a digital signature cannot be verified), then no policies applicable to the request are available.

[0039] In the event that any policy applicable to the request has been obtained, the authentication service 216 can provide an authentication response, and if applicable (e.g., when there is a positive authentication response), the obtained policy is returned to the service front end 210. The authentication response can indicate whether the response was successfully authenticated. The service front end 210 can then use the authorization module 212 to check whether fulfilling the request to access the service 208 complies with the obtained policy.

[0040] The authorization module 212 can be a process executed on the service front end, which can be operated to compare the request with one or more permissions in the policy to determine whether the service is authorized to implement the request (i.e., whether the request is authorized to be fulfilled). For example, the authorization module can compare the API call associated with the request with the API call of the permission specified by the policy to determine whether the request is allowed. If the authorization module 212 is unable to match the request with the permission specified by the policy, the authorization module 212 can perform one or more default actions, such as providing a message to the service front end causing the service front end to reject the request, and causing the rejected request to be recorded in the policy management service 220. If the authorization matches the request with one or more permissions specified by the policy, the authorization module 212 can solve this problem by selecting the least restrictive response (as defined by the policy) and by notifying the service front end whether the request is authorized to be fulfilled (i.e., in compliance with the applicable policy) based on the selected response. The authorization module 212 can also select the most restrictive response, or can select some other such response, and notify the service front end whether the request is authorized to be fulfilled based on the selected response. It should be noted that although Figure 2 The authorization module 212 is shown as a component of the service front end 210, but in some embodiments, the authorization module 212 is a separate service provided by the computing resource service provider 206, and the front end service can communicate with the authorization module 212 over a network.

[0041] In an embodiment, as described above, the service backend 214 includes a team of hardware security modules 222 or other security modules. In order to process a request received by the service frontend 210 that requires a cryptographic operation to be performed by a hardware security module, the service frontend 210 can send a request to the hardware security module, the request specifying the operation to be performed, the cryptographic key to be used to perform the cryptographic operation, and (if applicable) the data (e.g., plaintext or ciphertext) on which the cryptographic operation should be performed. The frontend 210 can select the hardware security module to perform the operation, or another component (e.g., a load balancer) can make the selection. The execution result of the cryptographic operation can be provided to the service frontend 210 from the hardware security module performing the operation so that the result can be provided in response to the corresponding request.

[0042] In embodiments, computing resource service provider 206 includes data storage service 206, which can be a computer system that provides API to enable data storage service to perform data storage operation (e.g., storage and retrieval of data object). Service front end 210 can communicate with data storage service to store cryptographic keys (e.g., managed customer keys) encrypted by domain keys maintained in hardware security module 222. For example, when the request received by front end 210 needs to use customer keys, front end 210 can submit a request to data storage service 224 to retrieve customer keys (encrypted under domain keys). Front end 210 can receive encrypted customer keys, and provide encrypted customer keys to hardware security module, for decryption and execution of cryptographic operations. Similarly, when hardware security module generates new customer keys (or rotates the domain keys under which customer keys are encrypted), hardware security module can use domain keys to encrypt customer keys, and provide encrypted customer keys to front end 210, which in turn can send requests with encrypted customer keys to data storage service 224, for permanent storage by it.

[0043] Note that although Figure 2 A specific configuration of the distributed system of the computing resource service provider is shown, but other configurations are also considered to be within the scope of the present disclosure. For example, authentication and authorization determination can be performed by different components of the distributed system (e.g., the service front end 210). As another example, one or more hardware security modules or other devices that provide hardware protection of cryptographic materials can be hosted by an entity different from the computing resource service provider 206, such as hosted by another service provider or the customer itself. In order for such a hardware security module to perform cryptographic operations, the server in the service back end 214 can send messages through a network (e.g., the Internet or through an internal network when the hardware security module is hosted in the same data center as the service back end 214). Such messages can be authenticated so that the entity hosting the hardware security module can distinguish between authorized requests and unauthorized requests to perform cryptographic operations. In another example, the hardware security module 222 is hosted by a separate service of the same computing resource service provider 206. For example, service 208 can provide a service (e.g., a virtual data storage device or other service) that utilizes the results of a cryptographic operation. In this example, an inter-service API call can be sent from one service to another service so that other services use the hardware security module to perform cryptographic operations. For example, such calls may be made by a service based on a provisioning or other workflow executed to fulfill a client request.

[0044] Figure 3 An illustrative example of a data structure 300 that may be used to maintain a set of derived domain keys is shown in accordance with an embodiment. Figure 3In the example of , data structure 300 is a table, although other data structures are considered within the scope of the present disclosure. Figure 3 As shown, data structure 300 includes three columns, each corresponding to different information about the corresponding export domain key. The first column 302 is used to record the identifier of the export domain key. The identifier is used as a reference to the export domain key so that the export domain key used to encrypt the cryptographic key can be tracked. For example, the export key token can include an identifier of the export domain key used to encrypt the cryptographic key in the export key token. In this way, when the export key token is provided at another time, the appropriate export domain key can be identified (for example, selected from a plurality of export domain keys) and accessed to decrypt the encrypted cryptographic key in the export key token. In this particular example, the identifier of the export domain key is a serial number. However, it should be noted that other types of identifiers can be used.

[0045] The second column 304 of the data structure 300 corresponds to the expiration of the corresponding export domain key. As described above, the cryptographic service may have access to multiple export domain keys at any given time, each with a different expiration, such that an export key token may be used for a specified amount of time before the export domain key is destroyed and the export key token thereby becomes unusable as a mechanism for accessing the client keys encrypted in the export key token. Figure 3 In the illustrative example of , each entry in the second column 304 of the data structure 300 has a different expiration of 24 hours. In this way, the data structure 300 records the different expiration of the derived domain key for 24 hours. However, it should be noted that the different expiration of 24 hours is illustrative, and other expirations can be used. For example, consecutive expirations can differ by less than 24 hours or more than 24 hours, and the difference between consecutive expirations is not necessarily uniform.

[0046] It is noted that each expiration of the corresponding derived domain key can be enforced by at least one instance of an automated process that causes the derived domain key to become inaccessible (e.g., permanently) to all security modules that have accessed the domain key at a time determined according to the expiration. For example, each security module in the security module fleet can execute an instance of an automated process that inevitably deletes the domain key when its expiration occurs. The security module can be configured so that remote attestation or other cryptographic attestation of the integrity of the code of the automated process must be independently verified (e.g., by another security module or other computing device) before providing access to the domain key. The security module can also be configured with an anti-tampering mechanism that causes the security module to be unable to access the domain key due to tampering, and is also configured so that removing power to the module causes the security module to be unable to access the domain key (e.g., because the storage of the domain key is limited to volatile memory). It is noted that the execution of the expiration can be performed by an automated process executed by another device. In such examples, the device executing the automated process can send a command to the security module to destroy the domain key (e.g., a command in which a specified domain key is identified to be destroyed) according to the expiration of the domain key. Such automated process may include transmitting a notification or other action if the security module does not comply with a command to destroy the domain key.

[0047] A third column 306 in the data structure 300 is used for export domain keys corresponding to their corresponding export domain key identifiers and expiration in the same row. As an illustrative example, in the first row of data structure 300 containing data, the export domain key stored in the entry in the third column 306 has an export domain key identifier of 31415926 and has an expiration of 12:00 a.m. on March 24, 2015.

[0048] By using a data structure such as data structure 300, an export domain key can be selected to allow the use period of the export key token specified by the client or otherwise. For example, a client can request a cryptographic key with a use period of 30 days. Data structure 300 can be used to locate an export domain key that has an expiration that will allow a use period of 30 days. The export domain key can be selected as an export domain key with a maximum use period less than or equal to the requested use period, or in an alternative embodiment, an export domain key with a minimum use period greater than or equal to the requested use period. In some examples, whether the export domain key is selected as an export domain key with a maximum use period less than or equal to the requested use period or an export domain key with a minimum use period greater than or equal to the requested use period is a configurable setting that can be selected in the parameters of the request for the export key token.

[0049] It should be noted that Figure 3The data structure 300 shown is provided for illustrative purposes, and many are considered to be within the scope of the present disclosure. For example, Figure 3 shows a specific type of information stored in a specific order. Different types of information and different orders are considered within the scope of the present disclosure. As another example, Figure 3 An expiration value and an exported domain key identifier are shown to be stored for each exported domain key. In an alternative embodiment, the expiration of the exported domain key can be used as the exported domain key identifier, and thus the column for the exported domain key identifier can be omitted. Other variations are also considered to be within the scope of the present disclosure.

[0050] Figure 4 FIG. 400 is shown, illustrating an exemplary derived key token 402 according to various embodiments. Figure 4 As shown, the export key token 402 includes various components. For example, in an embodiment, the export key token 402 corresponds to a customer key, and in order to identify the customer key, a set of identifiers for the customer key can be included with reference to the export key token 402. In this example, the export key token 402 includes an internal customer key identifier 404 and an external key identifier 406. The internal customer key identifier 404 can be an identifier used by the customer for the customer key. Similarly, the external customer key identifier 406 can be used as an identifier for the customer key used by the service provider that generates the export key token 402. In an exemplary embodiment, a request from a customer to a service provider for a customer key can include the internal customer key identifier 404 as a parameter, and the customer will use the internal customer key identifier 404 for the customer key in the internal part of its own computer system. The external customer key identifier 406 can be generated by the service provider for use by the service provider, such as enabling policies and other access control mechanisms to be associated with the customer key. However, it should be noted that the derived key token 402 may lack the internal client key identifier 404, such as when the client does not specify an internal client key identifier or when support for such an identifier is not provided. In some examples, the external client key identifier 406 may be used as the internal client key identifier, and in such examples, the external client key identifier 406 may be repeated, or a single component of the derived key token 402 may be the external client key identifier 406.

[0051] In addition, if Figure 4As shown, in an embodiment, the export key token 402 includes an encrypted copy 408 of the customer key encrypted under the export domain key. Therefore, in order to be able to identify the specific export domain key used to encrypt the customer key of the export key token 402, the export key token 402 may include an export domain key identifier 410. In this way, when the service provider receives the export key token 402, the service provider can use the export domain key identifier 410 to obtain the appropriate export domain key in order to decrypt the encrypted copy 408 of the customer key in the export key token 402.

[0052] Other information may also be included in the derived key token 402. For example, although such information is not shown in the figure, a non-initialization vector or other information for encrypting a client key may be included in the derived key token 402. As another example, the derived key token 402 may include a digital signature of the information contained in the derived key token 402. The digital signature may enable verification of the integrity of the derived key token 402. For example, a digital signature may be used to verify that the external client key identifier 406 and the derived domain key identifier 410 and or other information including the encrypted copy 408 of the client key have not been modified unintentionally or maliciously. The digital signature may be generated using a cryptographic key accessible to a service provider, such as a dedicated cryptographic key maintained as confidential by the service provider or a symmetric cryptographic key maintained as confidential by the service provider. Typically, any authentication information that may be used by a service provider to verify the integrity of some or all derived key tokens 402 may be used.

[0053] As described above, the cryptographic service may allow a client to request a key token to be exported. Figure 5 An illustrative example of a process 500 for processing a request to derive a key token according to an embodiment is shown. The process 500 can be performed by any suitable system, such as by the cryptographic service discussed above. The execution of various operations participating in the execution of the process 500 can occur through different components of the cryptographic service, such as described in more detail below. In an embodiment, the process 500 includes receiving 502 a request to derive a key token. The request 502 can be, for example, a web service request received from a computing device of a customer of a service provider whose system performs the process 500. The request 502 can be received by an appropriate component of a cryptographic service such as a web server.

[0054] In order to process the request received 502, the web server or another component of the cryptographic service can determine 504 whether the request is authentic. The determination 504 whether the request is authentic can be performed in various ways according to various embodiments. In some examples, the request is digitally signed so that it can be cryptographically verified. Therefore, determining 504 whether the request is authentic can include verifying the digital signature of the request received 502. For example, a symmetric digital signature generated using a symmetric cryptographic key shared as a secret between the customer and the service provider can be a private cryptographic key corresponding to a public cryptographic key provided or otherwise specified with the request, such as in a digital certificate corresponding to the private cryptographic key. Authentication services can be used to verify the digital signature, such as in conjunction with the above Figure 2 In other examples, the request is received 502 over a cryptographically protected communication session, such as a Transport Layer Security (TLS) session. The establishment of the session may require some type of authentication, and thus the fact that the request is received 502 over a cryptographically protected communication session indicates the authenticity of the request. In general, verification of the authenticity of the request can be performed by using authentication information to verify that the request was submitted by the entity associated with the request.

[0055] If it is determined 504 that the request is not authentic (i.e., if the authenticity of the request cannot be verified), then process 500 may include rejecting 506 the request. The request may be rejected in various ways by various embodiments. In some examples, for example, a response to the request is provided indicating the rejection. As another example, no action may be taken, and the request may be allowed to time out. Other operations may also be performed in conjunction with the rejection 506 of the request, and such operations may depend on the specific implementation of the system performing process 500.

[0056] If it is determined 504 that the request is authentic, then process 500 may include the web server or other component of the cryptographic service determining 508 whether to authorize fulfillment of the request. Determining whether to authorize fulfillment of the request may be performed in various ways according to various embodiments. Figure 2 , determining 508 whether fulfillment of the request is authorized may include verifying whether any policy applicable to the request allows fulfillment of the request. Typically, a service provider may maintain conditions that control fulfillment of the request, and verifying 508 whether fulfillment of the request is authorized may include verifying whether such conditions allow fulfillment of the request.

[0057] If it is determined 508 that fulfillment of the request is not authorized, then process 500 may include denying 506 the request, as described above. For example, a web server that receives 502 the request may send a message addressed to the address specified by the request as originating from. If it is determined 508 that fulfillment of the request is authorized, then the system performing process 500 may perform a set of operations to fulfill the request. In this example, process 500 includes selecting 510 an expired export domain key that matches the use period specified in the request received 502. The web server or security module may select the export domain key. The use period may, for example, be specified as a parameter of the request, or may be specified in other ways, such as by default. Process 500 may also include generating 512 a client key. The web server or other component of the system performing process 500 may, for example, send an instruction to a security module, causing the security module to generate 512 a client key. The security module may generate 512 the client key using, for example, a pseudo-random number generator or other mechanism (e.g., a key derivation function applied to information at least some of which is kept confidential). Note that although Figure 5 The generation 512 of the client key is shown as part of process 500, but the client key generation can be performed asynchronously with process 500. For example, the client key can be pre-generated and the pre-generated client key can be obtained. In other examples, the request for the derived key token includes a copy of the client key to be encrypted in the derived key token.

[0058] Once the client key has been generated 512, the security module that generated 512 the client key may encrypt 514 the generated client key using the selected export domain key. For example, the security module may access the selected export domain key from a memory and input the generated client key and the selected export domain key into a cryptographic algorithm that produces an encrypted copy of the generated client key. Once the encrypted copy of the generated client key has been obtained, the system performing process 500 may generate 516 an export key token using the encrypted client key.

[0059] The manner in which the export key token is generated 516 may vary according to various embodiments. In some examples, the security module that generates and encrypts the client key may additionally generate 516 the export key token, and in other examples, the security module may provide a copy of the encrypted client key to another server, such as a web server of the system performing process 500, so that the server will use the copy of the encrypted client key to generate 516 the export key token. Regardless of how it is generated 516, the web server that receives 502 the request may obtain the export key token, and the web server may provide 518 the generated export key token in response to the request.

[0060] Once the generated export key token 518 has been provided or at a time after the export key token 516 has been generated, the system performing process 500 may lose access 520 to the customer key. Access may be lost in various ways according to various embodiments, such as by overwriting a memory location storing some or all of the customer keys with different data such as zero random data or non-random data or by reallocating memory, where some or all of the customer keys are stored to eventually be overwritten with other data when the system performing process 500 continues to operate. As described above, other information (e.g., any copy of the export key token) from which the customer key can be obtained may not be accessible. In this way, to some extent, the service provider cannot access the customer key, and access to the customer key is therefore controlled by the customer, even in the unlikely event that there is a serious security breach at the service provider. For example, unless the customer provides the export key token in a subsequent request or otherwise, the service provider cannot access the customer key.

[0061] As described above, a customer of the service provider may provide a derived key token back to the service provider in order for the service provider to perform cryptographic operations using the cryptographic key encrypted in the derived key token. Figure 6 An illustrative example of a process 600 for processing a request to perform a cryptographic operation using a derived key token is shown. The process 600 may be performed by any suitable system, such as by the cryptographic service discussed above. Different components of the cryptographic service may perform different operations, as described in more detail below. In an embodiment, the process 600 includes receiving 600 a request to perform one or more cryptographic operations using a derived key token. The request may include, for example, the derived key token as a parameter of the request. As with all requests received from a client, the request may be received 602 by a web server of a service front end of the cryptographic service that performs the process 600. As described above in conjunction with Figure 5 As discussed, the system performing process 600 may determine 604 whether the request is authentic, as described above in conjunction with Figure 2 As described above, if it is determined 604 that the request is not authentic (i.e., if the authenticity of the request cannot be verified), then the request can be denied 606. However, if it is determined 604 that the request is authentic, then process 600 can include determining 608 whether fulfillment of the request is authorized. As described above, if it is determined 608 that fulfillment of the request is not authorized, or generally if it cannot be determined that the request has been authorized, then the system performing process 600 can deny 606 the request.

[0062] However, if it is determined that 608 authorization is performed for the request, the system of execution process 600 can determine 610 whether the export domain key is available. As described above, the export domain key with expiration can be used to encrypt the client key for the export key token. When the export domain key expires, the cryptographic service can perform a group of operations that may cause the cryptographic service and the service provider to be unable to access the export domain key. Therefore, when receiving a request for performing one or more cryptographic operations using the export key token, the request may or may not be performed, depending on whether the export domain key is used to encrypt the client key in the expired export key token, and therefore the service provider has been unable to access the export domain key. Determining whether 610 export domain keys are available can be performed in various ways according to various embodiments. In some examples, the web server uses the identifier of the export domain key in the export key token to check whether the identifier appears in the list of active export domain keys or other data structures. This type of operation can also be performed by a security module.

[0063] If it is determined 610 that the export domain key is not available, for example because the export domain key has expired and therefore the service provider has lost access to the export domain key, the system performing process 600 can deny 606 the request, as described above. However, if the system performing process 600, and specifically the portion of the system that determines 610 whether the export domain key is available, determines that the export domain key is available, then the system performing process 600 can select 612 the export domain key identified in the export key token. The selection can occur by a security module storing the export key token or otherwise by a web server that receives 602 the request. In the event that 612 has been selected, the export domain key can be used 614 to decrypt the customer key. The security module of the system performing process 600 can be a component of the system that uses 614 the selected export domain key to decrypt the customer key.

[0064] Once the decrypted client key is accessible to the component of the system that decrypted the client key using the selected exported domain key 614, the component may use the decrypted client key 616 to perform the requested one or more cryptographic operations. For example, the security module of the cryptographic service may use the decrypted client key to encrypt or decrypt data included or specified in the request, such as by being included in the request or referenced in the request to enable retrieval of the data. As described above, other cryptographic operations may be performed instead of or in addition to encryption and / or decryption. For example, a digital signature is included in the request, the request has data by which the digital signature is allegedly generated, and one or more cryptographic operations may include verifying the digital signature. Other operations may include determining whether a digital certificate is trusted and using the digital certificate to perform one or more cryptographic operations.

[0065] Where one or more cryptographic operations have been performed 616 to fulfill the request received 602, a response to the request including one or more results of performing the one or more cryptographic operations may be generated and provided 618 in response to the request. For example, the security module may provide the one or more results of the one or more cryptographic operations to a web server of the system performing the process 600 of receiving 602 the request. The response may be provided to the network destination (e.g., an Internet Protocol (IP) address) identified in the request as the network destination from which the request originated.

[0066] As described above, once one or more cryptographic operations have been performed using the decrypted client key and the system performing process 600 no longer needs the decrypted client key, the system performing process 600 can be rendered inaccessible 620 to the client key by performing a set of operations that causes the system to be unable to access the client key.

[0067] As described above, the export domain keys used by the cryptographic service may be rotated at different times. Figure 7 An illustrative example of a process 700 for maintaining a set of export domain keys and executing rules on export domain key rotation is shown. Process 700 can be performed by any suitable system, such as by each security module in a cryptographic service or other computer system, such as a computer system in a cryptographic service having a role of executing key rotation rules. In an embodiment, process 700 includes detecting 702 export domain key rotation triggers. The export domain key rotation trigger can be an event whose occurrence will cause additional operations of the process 700 to be performed. In some examples, the export domain key rotation trigger is that the clock reaches a certain value. In other examples, the trigger can be receiving a command from another computer system. Other triggers can also be used according to various embodiments. For example, when the count exceeds a threshold, a counter that counts or roughly counts the number of times the export domain key is used in a cryptographic operation can be a trigger. Other triggers are also considered to be within the scope of the present disclosure.

[0068] In the event that an export domain key rotation trigger has been detected 702, the system executing process 704 may select 704 a set of expired export domain keys. Figure 3The described data structure or its variation can be referenced to identify any export domain key that has expired. Once a set of export domain keys that have expired have been selected 704, the system performing process 700 can cause 706 to be unable to access any expired export domain key. The manner in which any expired export domain key is caused to be unable to access 706 can vary according to various embodiments. In some examples, one or more memory locations are used to store expired export domain keys. One or more memory locations storing expired export domain keys can be overwritten with random or non-random data. As another example, such memory can be deallocated so that the memory can be overwritten by any other process that utilizes the memory, so that after a certain amount of time (e.g., one hour or one day), there is a high probability that one or more memory locations will have been overwritten. Generally, any manner in which an expired export domain key may not be accessible is considered to be within the scope of the present disclosure.

[0069] like Figure 7 As shown, process 700 also includes generating 708 a set of replacement export domain keys to replace the set of expired export domain keys. The replacement export domain keys can be generated in various ways according to various embodiments. In some examples, a pseudo-random number generator is used to generate the replacement export domain keys. Other methods of generating replacement export domain keys include using key derivation functions and / or other operations. In general, any way in which cryptographic keys can be generated is considered to be within the scope of the present disclosure.

[0070] An identifier for arriving at a replacement derived domain key may be determined 710. The manner in which the identifier is determined for the replacement derived domain key may vary according to various implementations. For example, in some cases, the identifier of the derived domain key is a sequence value, and the identifier may be selected to be the next unused sequence value in the sequence used. The sequence may be, for example, a sequence of integers. An expiration of each replacement derived domain key may also be determined 712. The expiration may be determined 712 in various manners according to various embodiments. As an illustrative example, a specified amount of time may be added to the expiration of the derived domain key being replaced. The specified amount of time may be, for example, 365 days, although other amounts of time are considered to be within the scope of the present disclosure.

[0071] Once any replacement derived domain keys have been generated 708 with corresponding identifiers and expiration, the set of replacement derived domain keys generated 708 may be stored in association with the identifiers and expiration. Figure 3 As an illustrative example, for example, a row may be added to data structure 300 for each replacement exported domain key generated. In general, any manner in which a replacement exported domain key may be stored in direct or indirect association with a replacement exported domain key identifier and / or expiration may be used.

[0072] As described above, in various embodiments of the present disclosure, cryptographic services may allow customers the flexibility to use escrow cryptographic keys as well as customer keys encrypted in derived key tokens that are not accessible to the service provider. Figure 8 An illustrative example of a process 800 for fulfilling a request received by such a cryptographic service is shown. Process 800 can be performed by any suitable system, such as by the cryptographic service discussed above. The different components of cryptographic services can be such as the different operations of performing process 800 in the manner discussed below. In an embodiment, process 800 includes receiving 802 requests for performing one or more cryptographic operations. As mentioned above, 802 described requests can be received in various ways. For example, 802 described requests can be received by a web server such as the above-mentioned cryptographic service front end.

[0073] As described above, in the event that a request has been received 802, the process may include determining 804 whether the request is authentic, and determining 808 whether fulfillment of the request is authorized. If it is determined 804 that the request is not authentic (i.e., if the authenticity of the request cannot be verified), then the process 800 may include denying 806 the request. Similarly, if it is determined 808 that fulfillment of the request is not authorized, then the process 800 may include denying the request.

[0074] If the system performing process 800 determines that the request is authentic and authorized to fulfill the request, then process 800 may include determining 810 whether the request includes an export key token. As described above, the export key token may optionally be provided in a parameter of a request to perform one or more cryptographic operations. Therefore, determining 810 whether the request has an export key token may include parsing the request and determining whether such an export key token is included as a parameter of the request. For example, a web server at the front end of a cryptographic service may determine whether the request includes an export key token.

[0075] If it is determined 810 that the request does not have an export key token, then process 800 may include processing the request using 812 a provider-hosted client key. As an illustrative example, a web or other server of a cryptographic service performing process 800 may obtain an encrypted copy of a provider-hosted client key from a data storage location, such as from a separate data storage service. Once obtained, the server may provide the encrypted copy of the provider-hosted client key to the security module. Note that the request may include an identifier of the provider-hosted client key, which the system performing process 800 uses to select the provider-hosted client key from a plurality of provider-hosted client keys hosted for a plurality of clients. Other ways of determining a provider-hosted client key may also be used, such as when a client has a default provider-hosted client key that does not need to be specifically specified with an identifier.

[0076] Once provided to the security module, the security module may decrypt the encrypted copy using the domain key to obtain the provider-hosted client key in plain text. The security module may then perform one or more cryptographic operations using the provider-hosted client key to fulfill the request, and may provide the results of performing the one or more cryptographic operations to the server for inclusion in a response to the request received 802. The security module may then be unable to access the plain text copy of the provider-hosted client key that the security module obtained from the encrypted copy of the provider-hosted client key.

[0077] If the system executing in process 800 determines 810 that the request does in fact have an export key token, then the system executing process 800 can use 814 the export key token to process the request. The export key token can be used to process the request as described above in conjunction with Figure 6 The request stated.

[0078] As described above, when a client requests an export key token, such request may specify a usage period for the client key encrypted in the export key token returned as a result of fulfilling the request. In some cases, a client of a service provider utilizing an export key token may wish to extend the usage period of the cryptographic key encrypted in the export key token. For example, a client may need to access data at a time after the usage period of the export key token cryptographic key expires. Fig. 9 An illustrative example of a process 900 for processing a request to extend the life of a client key encrypted in a derived key token is shown. The process 900 may be performed by any suitable system, such as by a cryptographic service as described above, and different components of the cryptographic service may perform different operations in the process 900, such as described in more detail below.

[0079] In an embodiment, process 900 includes receiving a request to extend the usage period of a client key encrypted in a derived key token. The request may be received 902 in various ways, such as by combining the above Figure 2 The web server of the cryptographic service front end is received. As with the other requests described above, process 900 may include determining 904 whether the request is authentic, and determining 908 whether the request is authorized to be fulfilled. As described above, if it is determined 904 that the request is not authentic (i.e., if the authenticity of the request cannot be verified) or if it is determined that the request is not authorized to be fulfilled, then process 900 may include rejecting 906 the request.

[0080] like Fig. 9As shown, if the system performing process 900 determines 904 that the request is authentic, and also determines 908 that the request is authorized to be fulfilled, then process 900 may include determining 910 whether the export domain key is available. For example, if the request is received before the cryptographic key encrypted in the export key token expires, then the export domain key may be available. Similarly, if the request is received 902 after the client key encrypted in the export key token expires, then the export domain key may be unavailable. Determining 910 whether the export domain key is available can be performed by different components according to different implementations. For example, in some embodiments, determination 910 is performed by a web or other server of a cryptographic service, while in other embodiments, determination 910 is performed by a security module.

[0081] As described above, if the system performing process 900 determines 910 that the export domain key is not available, then process 900 may include denying 906 the request. However, if it is determined 910 that the export domain key is available, then the export domain key may be selected 912 as the export domain key identified in the export key token. Figure 3 The data structure may be used to select 912 the export domain key identified in the export key token. The export key token may then be used 914 to decrypt the client key.

[0082] As described above, the export key token may only be available within an authorized security module, and thus the selection 912 of the export domain key and the decryption of the client key in the export key token may be performed by the security module. The export domain key that matches the requested lifetime specified in the request received 902 may be selected 916. The selection 916 may be made as described above in conjunction with Figure 3 The security module that selects 916 the exported domain key that matches the requested lifetime may encrypt the client key using 918 the selected exported domain key.

[0083] Once the client key encrypted under the export domain key of selection 916 is obtained, process 900 can include generating 920 export key token with the encrypted client key. The generation of the export key token can occur by the security module that encrypts the client key or by the server. For example, in some implementations, the export key token is digitally signed by the security module using a cryptographic key that is inaccessible outside the authorized security module team. Therefore, the security module can be responsible for generating 920 export key tokens. If the security module generates 920 export key tokens, the security module can provide the export key token to the front-end web server of the cryptographic service of execution process 900. No matter how the web server at the front-end obtains the export key token, the web server can provide 922 the generated export key token in response to the request. As other processes described herein, as described above, at the time after the client key is no longer needed for performing any cryptographic operation, process 900 can include being unable to access 924 the client key.

[0084] In some examples, a customer of a service provider may utilize an export key token to allow the service provider limited access to its customer keys. For example, the customer may begin to trust the service provider more and / or may wish to have additional services performed by the service provider to relieve the customer of the burden of maintaining its own computing resources. Fig.10 An illustrative example of a process 1000 for processing a request to convert an exported client key into an escrow client key is shown. The process 1000 may be performed by any suitable system, such as by a cryptographic service as described above, and different components of the cryptographic service may perform different operations of the process 1000. In an embodiment, the process 1000 includes receiving 1002 a request to convert an exported client key into an escrow client key. The request may be received 1002 by a web server at the front end of the cryptographic service as described above. The request may include, for example, an exported key token as a parameter of the request to receive 1002. As with other processes described above involving requests to perform various operations involving exported key tokens, as described above, the process 1000 may include determining 1004 whether the request is authentic, determining 1008 whether the request is authorized to be fulfilled, and determining 1010 whether a suitable exported domain key is available.

[0085] The appropriate export domain key may be an export domain key that can be used to obtain a plaintext copy of the client key from the export key token received in the request. If it is determined that the request is not authentic (i.e., if the authenticity of the request cannot be verified), then fulfillment of the request is not authorized, or if it is determined that the appropriate export domain key is not available, then process 1000 may include denying 1006 the request. However, if it is determined 1004 that the request is authentic, then it is determined 1008 that fulfillment of the request is authorized, and if it is determined 1010 that the appropriate export domain key is available, then the system performing process 1000 may select 1012 the export domain key identified in the export key token received in the request.

[0086] As described above, selection of the derived domain key may be performed by a security module of a cryptographic service or a web or other service performing process 1000. The security module of the cryptographic service performing process 1000 may use 1014 the derived key token to decrypt the client key. The security module may then select 1016 a domain key, which may be a cryptographic key that the security module is configured to use to host the client keys, such as a cryptographic key that has a shorter rotation schedule than at least some of the derived domain keys. The security module may then use 1018 the domain key to encrypt the client key. The security module of the cryptographic service or a web or other server may generate 1020 a key token with the encrypted client key. The key token may be structured, such as in conjunction with the above. Figure 4 In some implementations, the key token is constructed as a combination of the above Figure 4 The derived key token 402 is described except that the key token may lack the internal client identifier 404, although some implementations allow for the use of an internal client key identifier for escrow client keys.

[0087] After the security module generates 1020 the key token, the security module may provide the key token to the web server of the cryptographic service, which receives 1002 the request so that the web server can store 1022 the key token generated 1020. In some examples, the web server sends the request to the data storage service so that the data storage service uses the computing resources of the data storage device such as the data storage service to store the key token. Generally, any manner in which the key token can be stored in hardware hosted and / or controlled by the service provider of its cryptographic service execution process 1000 is considered to be within the scope of the present disclosure. It should also be noted that in some embodiments, the security module may send the request to the data storage service itself, and provide a notification of such storage to the web server to provide a response to the request indicating that the request has been fulfilled. In addition, in some alternative embodiments, the security module may not generate the key token, but may store the key token in its own local memory that cannot be accessed outside the security module. A secure transfer between security modules may be performed so that multiple security modules can access the client key in such alternative embodiments.

[0088] In some examples, for various reasons, a customer of a service provider may wish to convert their managed customer keys into exported customer keys. Fig.11 An illustrative example of a process 1100 for processing a request to convert a escrow client key into an export client key is shown. Process 1100 can be performed by any suitable system, such as a cryptographic service as described above. In an embodiment, process 1100 includes receiving 1102 requests to convert a escrow client key into an export client key. The web server at the front end of the cryptographic service that performs process 1100 receives 1102 of the requests. The request can include an identifier of the escrow client key as a parameter, which can be used to distinguish the escrow client key from other escrow client keys that are hosted by a service provider. As other processes described herein, process 1100 can include determining whether the request is true in 1104, and determining whether to authorize the fulfillment of the request in 1108. If it is not determined that 1104 requests are true or if it is determined that 1108 does not authorize the fulfillment of the request, process 1100 can include rejecting 1106 requests, so

[0089] However, if it is determined 1104 that the request is authentic and it is determined 1108 that authorization to fulfill the request is provided, then process 1100 may include obtaining 1110 a key token from a data storage device, wherein the key token includes an encrypted copy of the escrow customer key specified in the request received 1102. As many of the operations described herein do not involve access to a plaintext copy of the customer key, the key token may be obtained 1110 by different components according to different embodiments, such as by a web or other server of a cryptographic service executing process 1100 or a security module thereof.

[0090] Regardless of how the key token is obtained 1110 from the data storage device, the key token can be obtained by the security module of the cryptographic service performing the process 1100. Fig.11 As shown, the security module may decrypt the customer key using 1112 the domain key. The security module may select 1114 an export domain key that matches a lifetime specified as a parameter or implicitly specified (e.g., as a default) in the request received 1102, and may encrypt the customer key using 1116 the selected export domain key. Appropriate components as described above may generate 1118 an export key token having the encrypted customer key.

[0091] The derived key token generated 1118 may be configured as above in conjunction with Figure 4 1102, and may include, for example, the various identifiers described above, wherein the internal client key identifier 404 may be specified as a parameter of the request received 1102. A web server at the front end of the cryptographic service executing process 1100 may provide 1120 the generated derived key token in response to the request. As with other processes described herein, as described above, process 1100 may include disabling access 1122 to the client key when the plaintext copy of the client key is no longer needed.

[0092] Figures 5 to 11Various processes that can be performed by a cryptographic service or other computer system are shown. The process shows various operations performed in a specific order. It should be noted that the order of operations can be different from the order shown, such as when the execution of one operation does not depend on another operation. For example, the determination of the authenticity of the request and the authorization of the request fulfillment can be performed in a different order or in parallel. It is not necessary to perform other pairs of operations in a specific order, such as when the output of one operation is not used as the input of another operation, it can be performed in a different order or in parallel. As an illustrative example, many processes described herein include performing a set of operations that cause the cryptographic service to be unable to access any plaintext copy of the client key. In all processes shown in the figure, the set of operations that cause inaccessibility occurs at the end of the process. However, the operation that causes the system to be inaccessible can be performed at any suitable time point, such as after any operation performed on the plaintext copy of the client key has been completed or any operation performed using the plaintext copy of the client key in other ways. Other changes are also considered to be within the scope of the present disclosure.

[0093] For example, in some embodiments, the expiration of the export domain key results in a complete inability to access the export domain key, making the information encrypted under the export domain key (e.g., the customer key) unrecoverable in the absence of a special computing workload. In some embodiments, the service provider may allow the export domain key to be retrieved after its expiration, such as allowing data to be restored after the use period of the export domain key. For example, the service provider may maintain a copy of the export domain key in an offline repository for a limited time after the expiration of the export domain key, so that the export domain key can be retrieved to decrypt information, and a copy of the export domain key can be retrieved from the offline repository. As another example, a private cryptographic key may be maintained in an offline repository (e.g., in a safe in a locked room of a data center or in other locations). The corresponding public key may be used to encrypt a copy of the export domain key, and the encrypted copy may be stored in a data storage system. At a later point in time, the private cryptographic key may be accessed and destroyed, thereby eliminating any potential ability to restore the export domain key. Other changes are also considered to be within the scope of the present disclosure.

[0094] As discussed, many variations of the present disclosure relate to performing various cryptographic operations that can utilize symmetric and / or asymmetric cryptographic primitives. Symmetric key algorithms can include various schemes for performing cryptographic operations on data including block ciphers, stream ciphers, and digital signature schemes. Exemplary symmetric key algorithms include Advanced Encryption Standard (AES), Data Encryption Standard (DES), Triple DES (3DES), Serpent, Twofish, blowfish, CAST5, RC4, and International Data Encryption Algorithm (IDEA). Symmetric key algorithms can also include those algorithms for generating the output of a one-way function, and include algorithms utilizing a hash-based message authentication code (HMAC), a common message authentication code (MAC), PBKDF2, and Bcrypt. Asymmetric key algorithms can also include various schemes for performing cryptographic operations on data. Exemplary algorithms include those utilizing the Diffie-Hellman key exchange protocol, the Digital Signature Standard (DSS), the Digital Signature Algorithm, the ElGamal algorithm, various elliptic curve algorithms, password-authenticated key agreement techniques, the Paillier cryptosystem, the RSA encryption algorithm (PKCS#1), the Cramer-Shoup cryptosystem, the YAK authenticated key agreement protocol, the NTRUEncrypt cryptosystem, the McEliece cryptosystem, and the like. Elliptic curve algorithms include the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme, the Elliptic Curve Integrated Encryption Scheme (ECIES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the ECMQV key agreement scheme, and the ECQV implicit certificate scheme. Other algorithms and combinations of algorithms are also considered to be within the scope of the present disclosure, and the above is not intended to be an exhaustive list.

[0095] Fig.12The various aspects of the exemplary environment 1200 for implementing various aspects according to various embodiments are shown. As will be appreciated, although a web-based environment is used for explanation purposes, various embodiments can be implemented using different environments as appropriate. The environment includes an electronic client device 1202, which may include any suitable device operable to send and / or receive requests, messages or information through a suitable network 1204 and transmit information back to the device user in some embodiments. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, tablet computers, set-top boxes, personal data assistants, embedded computer systems, e-book readers, etc. The network may include any suitable network, including intranets, the Internet, cellular networks, local area networks, satellite networks or any other such networks and / or combinations of the above-mentioned networks. The components used for such a system may depend at least in part on the type of selected network and / or environment. The protocols and components used for communicating through such networks are well known, and thus will not be discussed in detail herein. Communication through a network may be implemented through wired or wireless connections and combinations thereof. In this example, the network includes the Internet, as the environment includes a web server 1206 for receiving requests and providing content in response to the requests, but for other networks, alternative devices serving similar purposes may be used, as will be apparent to one of ordinary skill in the art.

[0096] The illustrative environment includes at least one application server 1208 and a data storage area 1210. It should be understood that there may be several application servers, layers or other elements, processes or components that can be linked or otherwise configured, and these application servers, layers or other elements, processes or components can interact to perform tasks such as obtaining data from appropriate data storage areas. The server as used herein can be implemented in various ways, such as a hardware device or a virtual computer system. In some contexts, a server can refer to a programming module executed on a computer system. As used herein, unless otherwise noted or clearly known from the context, the term "data storage area" refers to any device or device combination that can store, access and retrieve data, and the device or device combination can include any combination and any number of data servers, databases, data storage devices and data storage media in any standard, distributed, virtual or clustered environments. The application server can include any appropriate hardware, software and firmware, and the hardware, software and firmware are integrated with the data storage area and process some or all data access and business logic of the application depending on the needs of various aspects of one or more applications of the execution client device. The application server can provide access control services that cooperate with the data storage area, and can generate content that can be provided to the user, including but not limited to text, pictures, audio, video and / or other content, which can be provided to the user by the web server in the form of hypertext markup language ("HTML"), extensible markup language ("XML"), JavaScript, cascading style sheets ("CSS"), or another suitable client-side structured language. The content transmitted to the client device can be processed by the client device to provide content in one or more forms, including but not limited to forms that the user can perceive by hearing, vision and / or by other senses (including touch, taste and / or smell). The processing of all requests and responses and the delivery of content between the client device 1202 and the application server 1208 can be handled by the web server using PHP: Hypertext Preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, or another suitable server-side structured language in this example. It should be understood that the web server and the application server are not necessary and are merely exemplary components, because the structured code discussed herein can be executed on any suitable device or host as discussed elsewhere herein. Furthermore, unless the context clearly dictates otherwise, operations described herein as being performed by a single device may be collectively performed by multiple devices, which may form a distributed and / or virtual system.

[0097] The data storage area 1210 may include several separate data tables, databases, data files, dynamic data storage schemes, and / or other data storage mechanisms and media for storing data related to specific aspects of the present disclosure. For example, the data storage area shown may include mechanisms for storing production data 1212 and user information 1216, which can be used to provide content on the production side. The data storage area is also shown as including a mechanism for storing log data 1214, which can be used for reporting, analysis, or other such purposes. It should be understood that there may be many other aspects that may need to be stored in the data storage area, such as page image information and access rights information, which can be stored in any of the mechanisms listed above or in additional mechanisms stored in the data storage area 1210 as appropriate. The data storage area 1210 can be operated by logic associated therewith so as to receive instructions from the application server 1208 and obtain, update, or otherwise process data in response to the instructions. The application server 1208 can provide static data, dynamic data, or a combination of static data and dynamic data in response to the received instructions. Dynamic data (such as data used in web logs (blogs), shopping applications, news services, and other such applications) can be generated by a server-side structured language as described herein, or can be provided by a content management system ("CMS") operating on an application server or under its control. In one example, a user can submit a search request for a certain type of item through a device operated by the user. In this case, the data storage area may access user information to verify the identity of the user, and the directory details may be accessed to obtain information about the type of item. Subsequently, the information may be returned to the user in the form of a result list on a web page, and the user can view the web page through a browser on the user device 1202. Information about a specific item of interest can be viewed in a dedicated page or window of the browser. However, it should be noted that the embodiments of the present disclosure are not necessarily limited to the context of a web page, but can be more generally applicable to processing basic requests, wherein the request is not necessarily a request for content.

[0098] Each server will typically include an operating system that provides executable program instructions for basic management and operation of the server, and will typically include a computer-readable storage medium (e.g., hard disk, random access memory, read-only memory, etc.) that stores instructions that, when executed by the server's processor, allow the server to perform its intended functions. Suitable implementations of the server's operating system and basic functionality are known or commercially available and are readily implemented by one of ordinary skill in the art, particularly in light of the present disclosure herein.

[0099] In one embodiment, the environment is a distributed and / or virtual computing environment utilizing multiple computer systems and components interconnected by communication links, using one or more computer networks or direct connections. However, it should be appreciated by those of ordinary skill in the art that such a system may be used in a variety of environments having more than Fig.12 The system may operate equally well with fewer or more components than shown. Fig.12 The depiction of system 1200 in FIG. 1 should be regarded as illustrative in nature and not limiting the scope of the present disclosure.

[0100] Various embodiments can also be implemented in various operating environments, which can include one or more user computers, computing devices or processing devices that can be used to operate any one of multiple applications in some cases.Users or client devices can include any one of many general personal computers, such as desktops, laptops or tablet computers running standard operating systems, and cellular, wireless and handheld devices that run mobile software and can support multiple networks and message transmission protocols. This system can also include many workstations running any one of a variety of commercially available operating systems and other known applications, for purposes such as development and database management. These devices can also include other electronic devices, such as virtual terminals, thin clients, gaming systems and other devices that can communicate through a network. These devices can also include virtual devices, such as virtual machines, hypervisors and other virtual devices that can communicate through a network.

[0101] Various embodiments of the present disclosure utilize at least one network that may be familiar to those skilled in the art to support communications using any of a variety of commercially available protocols, such as the Transmission Control Protocol / Internet Protocol ("TCP / IP"), the User Datagram Protocol ("UDP"), protocols operating in various layers of the Open Systems Interconnection ("OSI") model, the File Transfer Protocol ("FTP"), the Universal Plug and Play ("UPnP"), the Network File System ("NFS"), the Common Internet File System ("CIFS"), and AppleTalk. The network may be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, a satellite network, and any combination of the above networks.

[0102] In embodiments utilizing a web server, the web server may run any of a variety of server or middle-tier applications, including a Hypertext Transfer Protocol ("HTTP") server, an FTP server, a Common Gateway Interface ("CGI") server, a data server, a Java server, an Apache server, and a business application server. The server may also be capable of executing programs or scripts in response to requests from user devices, such as by executing a program that may be implemented in any programming language, such as C, C# or C++) or any scripting language (such as Ruby, PHP, Perl, Python or TCL) and their combinations. The server may also include a database server, including but not limited to, and Commercially available database servers, as well as open source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. The database servers may include table-based servers, file-based servers, unstructured servers, relational servers, non-relational servers, or a combination of these and / or other database servers.

[0103] Environment can include various data storage areas and other memories and storage media as discussed above. These can reside in various locations, such as on storage media, which are local to one or more computers (and / or reside therein), or away from any or all computers in the network. In a group of specific embodiments, information can reside in a storage area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing functions attributed to computers, servers or other network devices can be stored locally and / or remotely, where appropriate. In the case where the system includes a computerized device, each such device can include hardware elements that can be electrically coupled by a bus, and the elements include, for example, at least one central processing unit ("CPU" or "processor"), at least one input device (e.g., mouse, keyboard, controller, touch screen or keypad) and at least one output device (e.g., display device, printer or speaker). Such a system can also include one or more storage devices such as disk drives, optical storage devices and solid-state storage devices such as random access memory ("RAM") or read-only memory ("ROM"), and removable media devices, memory cards, flash memory cards, etc.

[0104] Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and a working memory as described above. The computer-readable storage medium reader may be connected to or configured to receive a computer-readable storage medium representing a remote, local, fixed, and / or removable storage device and a storage medium for temporarily and / or more permanently containing, storing, sending, and retrieving computer-readable information. The system and various devices will also typically include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or a web browser. It should be understood that alternative embodiments may have many variations different from those described above. For example, custom hardware and / or specific elements may also be used that may be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections with other computing devices (such as network input / output devices) may be employed.

[0105] Storage media and computer-readable media for containing code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information, such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technology, compact disk read-only memory ("CD-ROM"), digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other medium that can be used to store the desired information and can be accessed by the system device. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will understand other ways and / or methods of implementing various embodiments.

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

[0107] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the invention to the specific form or forms disclosed, but rather, the invention is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the invention, as defined in the appended claims.

[0108] The use of the terms "a" and "an" and "the" and similar indicators in the context of describing the disclosed embodiments (particularly in the context of the appended claims) should be interpreted as covering the singular and the plural, unless otherwise specified herein or clearly contradicted by the context. The terms "include", "have", "include" and "comprise" are all interpreted as open terms (i.e., meaning "including but not limited to") unless otherwise specified. The term "connected" should be interpreted as partially or entirely contained, attached to or joined together when unmodified and referring to a physical connection, even if there are some objects in between. Unless otherwise specified herein, the description of the range of values ​​herein is only used as a shorthand method of individually referring to each individual value falling within the range, and each individual value is incorporated into this specification as if each individual value is listed separately herein. The use of the term "set" (e.g., "set of items") or "subset" should be interpreted as a non-empty set including one or more members unless otherwise specified or contradicted by the context. Furthermore, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but a subset and a corresponding set may be equivalent.

[0109] Unless specifically stated otherwise or otherwise clearly contradicted by context, connective language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C," together with context, is understood to be generally used to present that an item, term, etc. can be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set having three members, the connective phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such connective language is generally not intended to imply that certain embodiments require that at least one of A, at least one of B, and at least one of C each be present.

[0110] The operations of the processes described herein may be performed in any suitable order, unless otherwise specified herein or otherwise the context is clearly contradictory. The processes described herein (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as codes (e.g., executable instructions, one or more computer programs, or one or more applications) that are executed together on one or more processors by hardware or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program that includes multiple instructions that may be executed by one or more processors. The computer-readable storage medium may be non-transitory.

[0111] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present invention and does not limit the scope of the present invention unless otherwise specified. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the present invention.

[0112] Embodiments of the present disclosure are described herein, including the best mode known to the inventor for carrying out the present invention. After reading the foregoing description, variations of these embodiments may become apparent to those of ordinary skill in the art. The inventor expects those skilled in the art to use such variations where appropriate, and the inventor wishes that the embodiments of the present disclosure be implemented in a manner different from that specifically described herein. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter described in the appended claims as permitted by applicable law. In addition, unless otherwise specified herein or otherwise the context is clearly contradictory, any combination of the above-mentioned elements of all possible variations is included within the scope of the present disclosure.

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

[0114] Embodiments of the present disclosure may be described in terms of:

[0115] 1. A computer-implemented method comprising:

[0116] receiving, at a web server of a cryptographic service, a request for a cryptographic key, the request specifying a usage period, the request coming from a device associated with a client of the cryptographic service;

[0117] generating said cryptographic key in a device providing hardware protection of cryptographic material;

[0118] selecting, from a set of domain keys stored within the device and programmatically non-derivable from the device, a domain key having an expiration matching the specified lifetime, the expiration being enforced by at least one instance of an automated process that causes the domain key to become permanently inaccessible to the device at a time determined according to the expiration;

[0119] encrypting the generated cryptographic key in the device;

[0120] generating a token comprising the encrypted cryptographic key and an identifier of the cryptographic key;

[0121] providing the token to the device associated with the customer in response to the received request; and

[0122] One or more operations are performed that render the cryptographic key inaccessible to the device.

[0123] 2. The computer-implemented method of clause 1, further comprising associating a policy with the identifier of the cryptographic key such that the cryptographic service uses the policy to control fulfillment of requests to perform cryptographic operations using the cryptographic key.

[0124] 3. The computer-implemented method of clause 1 or 2, further comprising:

[0125] receiving, at the web server, a second request for an escrow cryptographic key;

[0126] generating the escrow cryptographic key in the device;

[0127] encrypting the escrow cryptographic key using a second domain key stored in the device; and

[0128] The encrypted escrow cryptographic key is stored in a location accessible to the cryptographic service.

[0129] 4. The computer-implemented method of clause 3, wherein:

[0130] The domain key is a first domain key from a first subset of the set of domain keys provided for deriving a cryptographic key; and

[0131] The second domain key is from a second subset of the set of domain keys provided for escrow cryptographic keys.

[0132] 5. A system comprising:

[0133] At least one computing device configured to implement one or more services configured to:

[0134] receiving a request for a cryptographic key; and

[0135] Fulfilling the request for the cryptographic key by:

[0136] obtaining the cryptographic key;

[0137] encrypting the obtained cryptographic key using cryptographic material, the cryptographic material being inaccessible outside of a set of hardware devices that each provide hardware protection for the cryptographic material, the cryptographic material having an expiration corresponding to a time after which the cryptographic material becomes inaccessible to the set of hardware devices, wherein the expiration is enforced by an automated process executed by the system;

[0138] providing a cryptographic key for said encryption; and

[0139] The obtained cryptographic key is rendered inaccessible to the set of hardware devices.

[0140] 6. A system as described in clause 5, wherein:

[0141] The one or more services are further configured to generate a token comprising an identifier of the cryptographic key; and

[0142] Providing the encrypted cryptographic key includes providing the generated token.

[0143] 7. The system of clause 5 or 6, wherein the one or more services are further configured to:

[0144] receiving a second request to perform a cryptographic operation using the cryptographic key, the second request including the encrypted cryptographic key; and

[0145] The second request is fulfilled by decrypting the encrypted cryptographic key and performing the cryptographic operation using the cryptographic key, subject to the cryptographic material still being available.

[0146] 8. The system of clause 7, wherein the one or more services are further configured to:

[0147] receiving a third request to perform the cryptographic operation, the request specifying an identifier of a second cryptographic key managed by the one or more services; and

[0148] The request is fulfilled by at least:

[0149] obtaining an encrypted copy of the second cryptographic key from a data storage location;

[0150] decrypting the encrypted copy of the second cryptographic key; and

[0151] The cryptographic operation is performed using the second cryptographic key.

[0152] 9. The system of any of clauses 5-8, wherein the one or more services are further configured to:

[0153] associating a policy with the cryptographic key, the policy specifying a set of permissions for the cryptographic key;

[0154] Fulfillment of requests to use the cryptographic key is controlled according to the policy.

[0155] 10. A system as described in any of clauses 5-9, wherein the one or more services are further configured to select the cryptographic material based at least in part on an expiration of the cryptographic material, the expiration indicating a time after which the one or more services will be unable to access the cryptographic material.

[0156] 11. The system of any of clauses 5-10, wherein the hardware device is a hardware security module.

[0157] 12. The system of any of clauses 5-11, wherein obtaining the cryptographic key comprises:

[0158] retrieving an encrypted copy of the cryptographic key from a data storage system accessible to the one or more services; and

[0159] The encrypted copy of the cryptographic key is decrypted using other cryptographic material different from the cryptographic material.

[0160] 13. A non-transitory computer-readable storage medium having executable instructions stored thereon, which, when executed by one or more processors of a computer system of a first entity, cause the computer system to at least:

[0161] For the first request for a secret token:

[0162] obtaining a key token including an encrypted copy of a first cryptographic key and information usable to identify a second cryptographic key used to encrypt the first cryptographic key, the second cryptographic key being inaccessible from outside of a set of hardware devices that manage the second cryptographic key, wherein obtaining the key token causes the first cryptographic key to become inaccessible to the entity after the key token is generated, and wherein the second cryptographic key has an expiration indicating a time after which the second cryptographic key becomes inaccessible to the set of hardware devices; and

[0163] For a second request for a key token, the second request being associated with a second entity:

[0164] Obtaining the key token;

[0165] if the time indicated by the expiration has not passed, causing a hardware device in the set of hardware devices to decrypt the first cryptographic key and perform one or more cryptographic operations using the decrypted first cryptographic key, and provide results of the one or more cryptographic operations to the computer system; and

[0166] A response to the second request is provided based at least in part on the provided result.

[0167] 14. A non-transitory computer-readable storage medium as described in clause 13, wherein the instructions are configured such that the instructions to obtain the key token, when executed by the one or more processors, cause the computer system to cause the key token to be generated as a result of receiving the first request.

[0168] 15. A non-transitory computer-readable storage medium as described in clause 13 or 14, wherein the instructions are configured such that the instructions for obtaining the key token, when executed by the one or more processors, cause the computer system to send a command to one of the hardware devices in the set of hardware devices to cause the key token to be generated.

[0169] 16. The non-transitory computer-readable storage medium of any of clauses 13-15, wherein the instructions further comprise instructions that, when executed for the second request, cause the computer system to:

[0170] determining, based at least in part on an identifier of the first cryptographic key, a set of policies defining a set of permissions for using the first cryptographic key;

[0171] determining whether fulfilling the request complies with the determined set of policies; and

[0172] Execution of the instructions that cause the computer system to cause the hardware device to decrypt the first cryptographic key and perform the one or more cryptographic operations using the decrypted first cryptographic key is contingent upon determining that fulfilling the request complies with the determined set of policies.

[0173] 17. The non-transitory computer-readable storage medium of any of clauses 13-16, wherein the first entity is a service provider operating the computer system and the second entity is a customer of the service provider.

[0174] 18. The non-transitory computer-readable storage medium of any of clauses 13-17, wherein:

[0175] The second request includes the key token; and

[0176] The instructions that cause the computer system to obtain the key token, when executed by the one or more processors, cause the computer system to determine the key token from the second request.

[0177] 19. The non-transitory computer-readable storage medium of any of clauses 13-18, wherein the set of hardware devices comprises a plurality of hardware security modules.

[0178] 20. A non-transitory computer-readable storage medium as described in any of clauses 13-19, wherein the instructions that cause the computer system to obtain the key token, when executed by the one or more processors, cause the computer system to obtain the key token in a manner that results in the second cryptographic key being selected because the second cryptographic key has an expiration that matches the usage period specified in the first request.

Claims

1. A method for cryptographic operation security performed by a service provider, comprising: Obtaining, by a computer, a cryptographic operation request to encrypt a data object, the cryptographic operation request including a token, the token including an encrypted copy of a client key for performing a cryptographic operation; The computer sends the cryptographic operation request to a hardware security module, the hardware security module providing hardware-based protection of the cryptographic material, the hardware security module being configured to perform one or more operations, the one or more operations comprising: verifying the cryptographic operation request; and as a result of the cryptographic operation request being determined to be valid and the access policy authorizing access to the client key of the cryptographic operation request, encrypting the data object by using the client key in accordance with the cryptographic operation request; Obtaining, by the computer, a response from the hardware security module, the response including a result of processing the cryptographic operation request; sending, by the computer, a response in response to the cryptographic operation request; and The client key is rendered inaccessible to the hardware security module after sending the response.

2. The method according to claim 1, wherein: The token is usable for a predetermined amount of time.

3. The method according to claim 1 or 2, wherein: The token is generated based at least in part on the client key.

4. The method according to any one of claims 1 to 3, wherein: The token includes an identifier of the client key.

5. A system for cryptographic operation security for use by a service provider, comprising: one or more hardware security modules that provide hardware-based protection of cryptographic material; as well as At least one computing device configured with a processor and a memory, the memory comprising instructions that, when executed, cause the system to: Obtaining a cryptographic operation request to decrypt data, the cryptographic operation request including a token, the token including an encrypted copy of a client key for performing the cryptographic operation; determining whether an access policy associated with a client key for the cryptographic operation request is authorized to govern access to the client key; Verifying the cryptographic operation request; as a result of determining that the cryptographic operation request is valid and that the access policy is authorized to govern access to the client key for the cryptographic operation request, processing the cryptographic operation request by decrypting the data using the client key; as well as The client key is rendered inaccessible to the system after processing the cryptographic operation request.

6. The system according to claim 5, wherein: The token includes a digital signature that can be used to verify the integrity of the token.

7. The system according to claim 5 or 6, wherein: The cryptographic operation request is digitally signed with the requester's certificate.

8. A system according to any one of claims 5 to 7, wherein: The cryptographic operation request is provided to an authentication service to verify a digital signature associated with the cryptographic operation request.

9. A system according to any one of claims 5 to 8, wherein: The client key is encrypted based on a domain key selected from a set of domain keys stored in the one or more hardware security modules.

10. The system according to claim 9, wherein: The set of domain keys is inaccessible outside of the one or more hardware security modules.

11. The system according to claim 9 or 10, wherein: Each domain key in the set of domain keys is associated with a validity period.

12. A system according to any one of claims 9 to 11, wherein: The instructions for processing the cryptographic operation request also include instructions for causing the system to decrypt the client key using the domain key.

13. A computer program product comprising instructions which, when executed by one or more processors of a computer system of a service provider, cause the computer system to at least perform the following operations: obtaining, at one or more systems including at least one hardware security module, a cryptographic operation request, wherein the at least one hardware security module provides hardware-based protection of cryptographic material, the cryptographic operation request including a token including an encrypted copy of a client key for performing the cryptographic operation; determining, by the one or more systems, whether an access policy associated with a client key for the cryptographic operation request is authorized to govern access to the client key; verifying, by the one or more systems, the cryptographic operation request by verifying a digital signature associated with the cryptographic operation request; processing, by the one or more systems, the cryptographic operation request as a result of determining that the cryptographic operation request is valid and that the access policy is authorized to govern access to a client key for the cryptographic operation request; as well as Instructions to render the client key inaccessible to the system after processing the cryptographic operation request.

14. The computer program product of claim 13, wherein: The cryptographic operation request includes a request for encrypting or decrypting data.

15. The computer program product of claim 13, wherein: The cryptographic operation request includes a request to verify a digital signature associated with the data.

16. A computer program product according to any one of claims 13 to 15, wherein: The access policy includes information indicating a set of permissions that are allowed to fulfill the cryptographic operation request.

17. A computer program product according to any one of claims 13 to 15, wherein: The instructions also include instructions that cause the system to determine whether a lifetime of a derived domain key included in the token exceeds a validity period.

18. The computer program product of claim 17, wherein: The instructions also include instructions for causing the system to refuse to process the cryptographic operation request as a result of determining that the age of the derived domain key included in the token has exceeded a validity period.

19. The computer program product of claim 17, wherein: The instructions also include instructions that cause the system to extend a usage period of a client key encrypted in the token.

Images