Enabling protection of password operations

Abstract

The present disclosure relates to a method for implementing protection of cryptographic operations performed by a stateless hardware security module for a client workload, the method comprising: a key generation request and an attestation document from the client workload, verifying the key generation request and the attestation document, determining a workload requirement for the client workload, and transmitting the workload requirement to the client workload. A cryptographic key is generated, and the determined workload requirement is encoded as an attribute of the generated cryptographic key. The generated cryptographic key and attributes (cryptographically protected using the hardware security module key) are returned to the client workload.

Description

Background Technology

[0001] This invention relates to the field of digital computer systems, and more specifically, to a method for implementing protection for cryptographic operations performed by a stateless hardware security module against a client workload.

[0002] Stateless hardware security modules can be used to perform cryptographic operations on client workloads. However, protecting cryptographic operations on client workloads performed by stateless hardware security modules can be a challenging task. Summary of the Invention

[0003] Various embodiments provide a method, computer program product, and stateless hardware security module for implementing protection against cryptographic operations performed by a stateless hardware security module against a client workload, as described in the subject matter of the independent claims. Advantageous embodiments are described in the dependent claims. Embodiments of the invention may be freely combined with each other if they are not mutually exclusive.

[0004] In one aspect, the present invention relates to a method for protecting cryptographic operations performed by a stateless hardware security module against a client workload. The method includes receiving a key generation request from the client workload by the hardware security module. The hardware security module receives a proof document for the key generation request signed by a first attestation service using a first cryptographic proof signing key. The hardware security module verifies the key generation request and the proof document using one or more predefined requirements of a workload allocation strategy. After successfully verifying the key generation request and the proof document for the key generation request, the hardware security module determines one or more sets of workload requirements for the client workload. The hardware security module generates a first cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload, and encodes one or more workload requirements into one or more attributes of the generated first cryptographic key for the client workload to allocate the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload. The hardware security module returns the generated first cryptographic key for the client workload along with one or more attributes of the generated first cryptographic key to the client workload. The generated first cryptographic key, along with one or more attributes of the generated first cryptographic key, is cryptographically protected using a hardware security module key for the client workload.

[0005] In another aspect, the present invention relates to a computer program product for implementing protection of cryptographic operations performed by a stateless hardware security module for a client workload. The computer program product includes a computer-readable storage medium having computer-readable program code. This computer-readable program code is configured to implement a method comprising receiving a key generation request from a client workload by a hardware security module. The hardware security module receives a proof document for the key generation request signed by a first proof service using a first cryptographic proof signing key. The hardware security module verifies the key generation request and the proof document using one or more predefined requirements of a workload allocation strategy. After successfully verifying the key generation request and the proof document for the key generation request, the hardware security module determines one or more sets of workload requirements for the client workload. The hardware security module generates a first cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload, and encodes one or more workload requirements into one or more attributes of the generated first cryptographic key for the client workload to allocate the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload. The hardware security module returns the generated first cryptographic key for the client workload along with one or more attributes of the generated first cryptographic key to the client workload. The generated first cryptographic key, along with one or more attributes of the generated first cryptographic key, is cryptographically protected using a hardware security module key for the client workload.

[0006] In another aspect, the present invention relates to a stateless hardware security module for protecting cryptographic operations performed by the hardware security module for a client workload. The hardware security module is configured to receive a key generation request from the client workload. The hardware security module is further configured to receive a proof document for the key generation request, signed by a first proof service using a first cryptographic proof signing key. The hardware security module is also configured to verify the key generation request and the proof document using one or more predefined requirements of a workload allocation strategy. The hardware security module is further configured to determine one or more workload requirements for the client workload upon successful verification of the key generation request and the proof document for the key generation request. The hardware security module is also configured to generate a first cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload, and to encode one or more workload requirements into one or more attributes of the generated first cryptographic key for the client workload to allocate the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload. The hardware security module is also configured to return the generated first cryptographic key for the client workload, along with one or more attributes of the generated first cryptographic key, to the client workload. The generated first cryptographic key, along with one or more attributes of the generated first cryptographic key, is cryptographically protected using a hardware security module key for the client workload. Attached Figure Description

[0007] The embodiments of the present invention will now be explained in more detail by way of example and with reference to the accompanying drawings, wherein:

[0008] Figure 1 This is a block diagram of a system including a stateless hardware security module, based on examples from the content of this topic.

[0009] Figure 2 This is a flowchart illustrating an example method based on the content of this topic.

[0010] Figure 3 This is a flowchart illustrating an example method based on the content of this topic.

[0011] Figure 4 This is a flowchart illustrating an example method based on the content of this topic.

[0012] Figure 5 This is a flowchart illustrating an example method based on the content of this topic.

[0013] Figure 6 This is a flowchart illustrating an example method based on the content of this topic.

[0014] Figure 7 This is a block diagram of a system including a stateless hardware security module, based on examples from the content of this topic.

[0015] Figure 8 This is a computing environment based on examples from the content of this topic.

[0016] Figure 9 A cloud computing environment according to an embodiment of the present invention is described.

[0017] Figure 10 An abstract model layer according to an embodiment of the present invention is shown. Detailed Implementation

[0018] The description of various embodiments of the present invention is presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles of the embodiments, their practical application, or technical improvements to existing technologies on the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0019] The hardware security module (HSM) considered here is a stateless HSM, particularly a remote stateless HSM. The method described here enables workload-scoping of cryptographic keys in such stateless HSMs. Compared to known methods, workload-scoping of cryptographic keys in stateless HSMs provides additional protection for sensitive cryptographic keys. Therefore, a higher level of protection can be achieved against attacks, for example, those based on malicious client workloads, that are used by the stateless HSM.

[0020] An HSM client refers to a system that sends requests to the HSM, i.e., a computer system, similar to the client role in a client-server model. A client workload refers to a containerized image, program, software, and / or application running on a client that handles the sending of requests and the processing of responses.

[0021] HSM can provide the cryptographic keys generated by HSM for client workloads, along with the attributes assigned to those keys by HSM, in the form of a cryptographically protected dataset (also known as a key blob). This dataset (i.e., the key blob) can be encrypted by HSM using HSM keys, such that only HSM can decrypt and use the generated cryptographic keys, which have the attributes of the cryptographic keys included in the corresponding dataset. Since HSM is stateless, the key blob, containing the attributes of the cryptographic keys generated for client workloads, can be sent by HSM to the client workload for storage. When a cryptographic key is required for performing a cryptographic operation by HSM for a client workload, the client workload can, for example, send the encrypted key blob to HSM. HSM can, for example, decrypt the encrypted key blob and use the attributes to check whether the cryptographic keys included in the key blob were indeed assigned to the client workload requesting the cryptographic operation. In other words, it checks whether the client workload is allowed to use the key blob, i.e., the cryptographic keys included in the key blob. If the check is positive, HSM can perform the requested cryptographic operation using the cryptographic keys included in the key blob provided by the client workload requesting the cryptographic operation.

[0022] Using attributes that include the workload requirements of the client workloads, the availability of a generated cryptographic key can be assigned to the cryptographic operation requests of the client workloads. This workload-wide determination of the cryptographic key via attributes can limit the scope of the cryptographic key to a single client workload. In other words, a cryptographic key is generated for a single client workload, and its availability is restricted to that single client workload via attributes. Therefore, only client workloads for which the cryptographic key is scoped can successfully request any use of that cryptographic key by the HSM. Another client workload (e.g., a malicious client workload) that enters the location of the cryptographically protected key may not be able to use the key, for example, to request cryptographic operations performed by the HSM, where the cryptographically protected key is not scoped to that other client workload. Proof (e.g., documentation provided for another malicious client workload) can reveal that it is not the same client workload to which the cryptographic key is scoped, because documentation for other malicious client workloads is generally different from documentation provided for the client workload to which the cryptographic key is scoped.

[0023] Proof mechanisms can be used to prevent tampering with the scope determination mechanism. For example, a tampered client workload may not be able to use a cryptographic key whose scope has been defined for an undisturbed client workload. Proof (such as a proof document provided for the tampered client workload) can reveal the tampering because it is typically different from the proof document provided for the undisturbed client workload. Therefore, neither the tampered version of the original client workload nor another malicious client workload can use the key generated for the original undisturbed client workload.

[0024] The determination of the scope of the cryptographic keys in a stateless HSM based on the workload of interest can identify potential attack vectors that can provide protection. These include, for example, malicious actors, such as malicious administrators, who steal key blocks generated by the HSM for individual client workloads from external storage devices and insert the stolen key blocks into the malicious client workloads. The malicious client workloads can be created by the malicious actors, for example, to sign malicious transactions. The malicious client workloads might attempt to request cryptographic operations from the HSM using the stolen key blocks, for example, to authorize malicious transactions using the cryptographic keys included in the stolen key blocks. Examining the proof document provided for the malicious client workload, which differs from the proof document provided for the client workload, reveals that the workload for which the proof document generated the cryptographic keys included in the stolen key blocks and encoded them into attributes restricts the availability of the cryptographic keys. Therefore, the proof document provided for the malicious client workload does not meet the workload requirements encoded into the attributes included in the key blocks, and the HSM refuses to perform the requested cryptographic operations, such as authorizing malicious transactions.

[0025] Another potential attack vector is a tampered client workload. The determination of the scope of the cryptographic keys in a stateless HSM based on the workload of interest can provide protection against this attack vector. For example, a malicious actor with malicious administrator privileges could tamper with the client workload, including the key block generated for that client workload, by inserting code into the client workload and / or modifying the client workload's code to sign malicious transactions using the key block of the undisturbed client workload. When the tampered code in the client workload is executed, it can attempt to request cryptographic operations from the HSM using the key block, such as authorizing a malicious transaction using the cryptographic keys included in the key block. Examining the proof document provided for the tampered client workload reveals that, due to the differences in the code caused by the tampering, the proof document provided for the tampered client workload is different from the proof document provided for the undisturbed client workload. Therefore, the proof document provided for the tampered client workload does not meet the workload requirements encoded in the attributes included in the key block generated for the undisturbed client workload, and the HSM refuses to perform the requested cryptographic operation, such as authorizing a malicious transaction.

[0026] By examining the documentation provided for client workloads using a workload allocation policy, HSM can identify and reject vulnerable client workloads and / or client workloads deployed to vulnerable execution environments. Furthermore, by examining the documentation provided for client workloads requesting the use of the cryptographic key included in the key block and the attributes provided by the key block, HSM can identify or reject malicious and / or tampered client workloads and / or client workloads deployed to malicious and / or tampered execution environments.

[0027] Furthermore, for example, controlled switching of cryptographic keys can be implemented between different versions of the client workload. Therefore, client workload updates can be achieved.

[0028] Determining the scope of cryptographic keys based on the workload of concern in a stateless HSM can achieve one or more of the following beneficial effects: An additional layer of protection can be provided to the cryptographic key by assigning attributes that encode the availability of the corresponding cryptographic key to the workload requirements of individual client workloads. Authorization to use the cryptographic key can be proven using a certificate document generated for the individual client workload and verified using the attributes assigned to the cryptographic key. Cryptographic keys and stateless HSMs can be protected against potential attack vectors, such as those outlined above. Typical DevOps operations, such as client workload updates, are not hindered. DevOps refers to a set of practices designed to reduce the time between committing changes to a system and getting that change into production while ensuring high quality. DevOps can be characterized by one or more of the following key principles: shared ownership, workflow automation, and rapid feedback. DevOps refers to a methodology in the software development and IT industry that uses a set of practices and tools to integrate and automate the work of software development (Dev) and IT operations (Ops) as a means to improve and shorten the system development lifecycle. DevOps can complement flexible software development, which has several aspects of DevOps that come from flexible work styles.

[0029] The workload-based scope determination of cryptographic keys in stateless HSMs can further enable new types of licensing for cryptographic keys per client workload in both HSMs and cloud cryptographic services. Furthermore, this workload-based scope determination of cryptographic keys in stateless HSMs can be combined with confidential computing security build provisioning, for example, provided by a secure build server. Finally, a novel cryptographic key licensing and pricing model can be implemented. For example, cryptographic keys can be priced according to cryptographic key usage and / or according to client workload.

[0030] The first local proof service can be, for example, a local proof service. Such a local proof service can be implemented, for example, as a component of an execution environment in which client workloads are executed. The first local proof service can use a first cryptographic proof signing key to sign the proof document. The HSM can trust the first cryptographic proof signing key. The HSM can, for example, be provided with a first cryptographic proof signature verification key. For example, the first cryptographic proof signing key is the encrypted private key of a first asymmetric cryptographic key pair. The first asymmetric cryptographic key pair may further include a cryptographic public key, which is provided to the HSM as the first cryptographic proof signature verification key. For example, the first cryptographic proof signature verification key is provided to the HSM as part of the digital credentials of the first proof service.

[0031] The hardware security module key can be, for example, a domain master key for an HSM. For instance, the HSM key can be a symmetric or asymmetric cryptographic key. To cryptographically protect data, such as keys generated by the HSM and / or attributes of those keys, the HSM can use the hardware security module key to encrypt the data. The HSM key used for encryption can be, for example, the public key of an asymmetric cryptographic key pair of the HSM. The asymmetric key pair of the HSM may also include a private cryptographic key of the HSM, which is required to decrypt data encrypted using the public cryptographic key of the HSM. Using the HSM key to encrypt data (e.g., the symmetric cryptographic key or the public cryptographic key of the HSM) ensures that only the HSM can decrypt the encrypted data. Access to the symmetric cryptographic key or the public cryptographic key of the HSM can be restricted to the HSM.

[0032] Stateless HSMs can be implemented, for example, as EP11-based CEX cards, or as cloud HSMs, such as in the form of Hyper Protect Crypto Services (HPCS), i.e., cloud HSMs based on CEX HSMs that support the PKCS #11 API.

[0033] With PKCS #11 (EP11) enabled, as in the case of Linux on Enterprise Z systems, applications can use the PKCS #11 API to run secure key cryptographic operations on an IBM® CryptoExpress adapter configured as a Crypto Express EP11 coprocessor (referred to as CEX*P). This Crypto Express adapter represents any type of Crypto Express EP11 coprocessor. An IBM® CryptoExpress adapter configured with Enterprise PKCS #11 (EP11) firmware is referred to as a Crypto Express EP11 coprocessor. The CEX4S adapter is the first CryptoExpress adapter that can be configured as an EP11 coprocessor. For example, CEX5P, CEX6P, CEX7P, or CEX8P on suitable IBM Z® systems can be used as EP11 coprocessors.

[0034] Application requests can first be submitted to the PKCS #11 API, implemented, for example, by the openCryptoki library and EP11 tokens. From this token, the request can be propagated to the Crypto Express EP11 coprocessor. The request can then be processed on this coprocessor. The final output can ultimately be returned to the application through the relevant interfaces. The EP11 cryptographic architecture provides a secure key infrastructure.

[0035] PKCS #11 refers to the Public Key Cryptography Standard (PKCS), a set of cryptographic standards that provide guidelines and application programming interfaces (APIs) for using cryptographic methods. As the name PKCS suggests, these standards emphasize the use of public-key (i.e., asymmetric) cryptography. openCryptoki is an open-source implementation of the Cryptoki API defined by the PKCS #11 cryptographic token interface standard.

[0036] Key material can be generated, for example, on the HSM, returned in an HSM key (e.g., an HSM domain master key), protecting a so-called key block to the client workload, and subsequently returned by the client workload to the HSM for use by the HSM on behalf of the client workload during subsequent requests. The client workload manages and stores the key block, which provides cryptographic material generated by the HSM for the client workload in cryptographically protected form. The key material protected by the HSM key (e.g., an HSM domain master key) can only be used by the specific HSM (e.g., the HSM domain) to which that HSM key (e.g., the HSM domain master key) is assigned. The HSM can, for example, use additional access control mechanisms, such as Transport Layer Security (TLS) or Identity and Access Management (IAM) in the case of an HPCS cloud HSM.

[0037] The client workload may, for example, request proof documents from a first proof service, which may be, for example, a local proof service. The local proof service may be, for example, a component of the execution environment in which the client workload is executed.

[0038] When a client workload requests a certificate, the first proof service can, for example, create a certificate document for the client workload. The first proof service can examine certain characteristics related to the client workload and prove the examination results by signing the certificate document generated for the client workload using a first cryptographic proof signing key. The HSM can, for example, use the first cryptographic proof signing verification key to verify the signature and thus verify the proof characteristics related to the client workload provided by the certificate document.

[0039] Figure 1This is a block diagram of an exemplary system 101 including a remote stateless HSM 100 that provides cryptographic services and / or cryptographic operations for one or more client workloads 110, 130. To enable secure use of the cryptographic services and / or cryptographic operations, client workload 110 can request a cryptographic key from the stateless HSM 100. The HSM 100 can examine a certificate document provided by a certificate service 120 for the client workload 110. Thus, the HSM 100 can check whether the client workload 110 is authorized to request the cryptographic key. The certificate document can be provided to the HSM 100 via the client workload 110 or alternatively directly. If the client workload 110 is authorized to request the cryptographic key, the HSM 100 can generate the requested cryptographic key and assign attributes to the generated cryptographic key that define the workload requirements satisfied by the client workload requesting the HSM 100 to use the cryptographic key on behalf of the requesting client workload 110. A workload allocation strategy provided by the HSM 100 can be used to verify the certificate document. For example, attributes can be determined using the proof document of client workload 110. For example, characteristics proven by the proof document of client workload 110 regarding client workload 110 can be included in the attributes. The generated requested cryptographic key and assigned attributes can be returned to client workload 110 by HSM 100 in a cryptographically secure form. For example, key blocks can be encrypted by HSM 100 using the HSM key, such that only HSM 100 can decrypt and use the cryptographic key provided by the key blocks for client workload 110. Client workload 110 can receive and store the key blocks.

[0040] If client workload 110 needs to perform a cryptographic operation using the cryptographic key included in the key block, client workload 110 can send the cryptographic operation request along with the key block to HSM 100. Furthermore, the authentication document for client workload 110 can be provided by authentication service 120. HSM 100 can, for example, decrypt the key block and use the authentication document and the attributes assigned to the cryptographic key to verify that client workload 110 is authorized to request HSM 100 to use the cryptographic key. If client workload 110 is authorized, HSM 100 can use the cryptographic key of client workload 110 provided in the key block to perform the requested cryptographic operation of client workload 110. After performing the cryptographic operation, HSM 100 can delete the key block.

[0041] Therefore, HSM 100 can be configured, for example, to generate a cryptographic key for client workload 110 upon request and to use the cryptographic key for client workload 110 to provide cryptographic operations for client workload 110. Furthermore, HSM 100 can be configured, for example, to provide an updated cryptographic key, i.e., a second cryptographic key for an updated client workload 130. The second cryptographic key for the updated client workload can be provided, for example, upon request from client workload 110, the updated client workload 130, or a third party (e.g., security build server 150) representing the client workload. The updated client workload 130 can, for example, be executed in the same execution environment. The proof service 140 that provides proof documentation for the updated client workload 130 can be, for example, the same as, or different from the proof service 120 that provides proof documentation for client workload 110.

[0042] Secure build server 150 may be configured, for example, to build and provide updated client workloads 130. For instance, secure build server 150 may be configured to request a second cryptographic key for updated client workloads 130. The authorization of secure build server 150 for requesting the second cryptographic key for updated client workloads 130 can be verified using a verification document provided by verification service 160 for secure build server 150. The resulting updated key block, including the second cryptographic key for updated client workloads 130, may be forwarded by the requesting secure build server 150 to the updated client workloads 130 for use.

[0043] Figure 2 This is a flowchart of an exemplary method for protecting cryptographic operations performed by a stateless HSM against a client workload. In box 200, the HSM receives a key generation request from the client workload. In box 202, the HSM receives a proof document for the key generation request, signed by a first proof service using a first cryptographic proof signing key. For example, the proof document can be received from the client workload or directly from the proof service. In box 204, the HSM verifies the key generation request and the proof document using one or more predefined requirements of a workload allocation policy. Verification may include verifying the integrity and validity of the proof document. Verification may be successful if the proof document meets the requirements defined by the workload allocation policy for the key generation request.

[0044] Workload distribution policies can be defined by an administrator, for example. These policies may include requirements regarding trusted cryptographic proof signing keys. For instance, a workload distribution policy might include a set of trusted credentials with a cryptographic proof signature verification key, which can be used to verify signatures generated using that key. Furthermore, workload distribution policies may include checksums, such as hashes, of multiple characteristics associated with client workloads authorized to use the HSM.

[0045] Workload allocation strategies may include, for example, an allowed list of proof signing keys trusted by the HSM or an allowed list of credentials for proof signing keys trusted by the HSM, as well as requirements for content provided by the proof document.

[0046] In box 206, after successfully verifying the key generation request and its supporting documentation, the HSM determines a set of one or more workload requirements for the client workload. This determination may, for example, include extracting characteristics of the client workload validated by the supporting documentation and using these characteristics as workload requirements.

[0047] Upon unsuccessful verification, the HSM can, for example, reject the key generation request. For instance, if the proof document cannot be verified, or if the workload allocation strategy requires additional requirements that the proof document does not provide, the HSM can temporarily reject the key generation request. Where the workload allocation strategy requires a proof document in the form of a random number protection, this additional requirement could be, for example, a random number. Alternatively, the HSM can, for example, invoke a remote proof API associated with the client workload, provided, for example, by the execution environment in which the client workload is executed. A first proof service trusted by the HSM can, for example, be contacted by the HSM via the remote proof API to obtain the proof of the additional requirements directly from the first proof service. In the event of a temporary rejection by the HSM, the first proof service can, for example, regenerate the proof document for the client workload upon request from the client workload. The regenerated proof document for the client workload can, for example, include additional required information. This regenerated proof document can be used by the client workload to reissue the key generation request. For example, the HSM can use the regenerated proof document to accept the reissued key generation request.

[0048] The attributes of the first cryptographic key define the workload requirements, which are met by the client workload's credentials, enabling the client workload to use the first cryptographic key. The attributes define which client workload is authorized to use the generated first cryptographic key. In the case of a use request by the HSM on behalf of a client workload using the first cryptographic key, the requesting client workload can, for example, be identified and its credentials verified as authorized client workloads, against the workload requirements defined by the attributes.

[0049] To determine one or more workload requirements for a client workload, the HSM may, for example, use proof documents and / or workload allocation strategies. For instance, a workload allocation strategy could define characteristics related to the client workload, proven by the proof document of the client workload, as the workload requirements for that client workload. Therefore, it can be ensured that the cryptographic key generated by the HSM for the client can only be used by the client workload that requested the generation of the cryptographic key. For example, the proof document of the client workload issuing the key generation request can be included in the workload requirements. Furthermore, the ID of the first cryptographic proof signing key, the first cryptographic proof signing key, and / or credentials with a cryptographic proof signature verification key can be used to verify the signature generated using the cryptographic proof signing key.

[0050] In box 208, the HSM generates a first cryptographic key for the client workload, which will be used by the HSM to provide cryptographic operations for the client workload, and encodes one or more workload requests into one or more attributes of the generated first cryptographic key for the client workload in order to assign the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload.

[0051] In box 210, the HSM returns a first cryptographic key for the generated client workload, along with one or more attributes of the generated first cryptographic key, to the client workload. The generated first cryptographic key for the client workload, along with one or more attributes of the generated first cryptographic key, is cryptographically protected using the HSM key. The first cryptographic key with attributes may be provided, for example, in the form of a key block encrypted by the HSM using the HSM key.

[0052] In the example, a first cryptographic key generated for the client workload, along with one or more attributes of the generated first cryptographic key, is cryptographically protected by using an HSM key. Therefore, after decryption with the HSM key, only the HSM can use the first cryptographic key.

[0053] In the example, one or more of the following are used to determine one or more workload requirements for the client workload: a certificate document for the key generation request, and a workload allocation strategy. For example, a workload allocation strategy could define the use of a certificate document to determine workload requirements. Furthermore, in addition to the workload requirements provided by the certificate document for the key generation request, the workload allocation strategy could also provide other workload requirements.

[0054] In the example, the client workload receives a proof document for the key generation request, along with the key generation request itself. In addition to the key generation request, the example also receives a proof document for the key generation request from a first proof service.

[0055] In the example, a random number is used to generate the proof document for the key generation request. Using a random number allows the HSM to ensure, for example, that the proof document used for the key generation request is used only once and will not be used again later to request the generation of another cryptographic key. To successfully request the generation of another cryptographic key, another proof document must be generated, which includes another random number. For example, the HSM can define and provide the random number to be incorporated into the proof document.

[0056] In the example, the proof document used for the key generation request includes one or more of the following: the machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, the root partition used for the first boot; a checksum of the root partition at the build time of the execution environment of the client workload, the root partition used for the build execution environment; a checksum of the client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; the ID of the cryptographic proof signature verification key used to verify the signature generated using the first cryptographic proof signature key; and credentials used to verify the signature generated using the first cryptographic proof signature key.

[0057] In the example, the workload allocation strategy includes one or more of the following: the ID of the cryptographic proof signature verification key used to verify the signature generated using the first cryptographic proof signature key; the credentials used to verify the signature generated using the first cryptographic proof signature key; the cryptographic proof signature verification key used to verify the signature generated using the first cryptographic proof signature key; the machine type ID of the machine on which the client workload is executed; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition of the execution environment at the first boot of the execution environment of the client workload, the root partition used for the first boot; the checksum of the root partition of the execution environment at the build time of the execution environment of the client workload, the root partition used for the build of the execution environment; the client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; one or more predefined constraints for using the first cryptographic key generated for the client workload; and one or more rules for updating the first cryptographic key generated for the client workload.

[0058] In the example, the proof requirements defined by the workload distribution strategy are based on one or more of the following: client, tenant, key type of the first cryptographic key, client workload, and the geographical location of the machine on which the client workload is executed. A tenant refers to the party interacting with the client. The client may, for example, send requests on behalf of the tenant, including, for example, the tenant ID.

[0059] In the example, the workload allocation strategy includes one or more selection rules for selecting the proof requirements to be met based on one or more of the following: client type, tenant type, key type of the first cryptographic key, client workload type, and the geographical location of the machine on which the client workload is executed.

[0060] In the example, one or more predefined constraints for using the first cryptographic key generated for the client workload include one or more of the following: a predetermined maximum allowed number of times the first cryptographic key is used to perform cryptographic operations; the expiration date of the first cryptographic key; a list of allowed networks for receiving requests containing the first cryptographic key by the HSM; and a list of allowed originators for updating requests containing the first cryptographic key.

[0061] In the example, one or more rules for updating the first cryptographic key generated for a client workload include one or more of the following: constraints on the workload that can use the updated cryptographic key; a policy type containing a list of values ​​that can be changed; a shared secret credential shared between workloads using the cryptographic key; a build server that can build workloads using the cryptographic key; and constraints on the use of the cryptographic key that restrict the use of the cryptographic key based on one or more of the following: client, tenant, key type, workload, geographical location of the workload, number of cryptographic operations, expiration date of the cryptographic key, and networks that are allowed to send requests to the HSM.

[0062] In the example, one or more attributes of the first cryptographic key generated for the client workload include one or more of the following: an ID of a cryptographic proof signature verification key used to verify a signature generated using the first cryptographic proof signature key; a cryptographic proof signature verification key used to verify a signature generated using the first cryptographic proof signature key; a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition of the execution environment at the first boot of the execution environment of the client workload, the root partition being used for the first boot; a checksum of the root partition of the execution environment at the build time of the execution environment of the client workload, the root partition being used for the build of the execution environment; a client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; and the ID of the first cryptographic key generated for the client workload.

[0063] In the example, the first proof service is a component of the execution environment for the client workload.

[0064] Figure 3 This is a flowchart of an exemplary method for performing cryptographic operations on a client workload using a first cryptographic key. In block 300, the HSM receives a cryptographic operation request from the client workload. The cryptographic operation request is received along with the client workload's first cryptographic key and one or more attributes of the first cryptographic key, which are cryptographically protected using the HSM key. The requested cryptographic operation may, for example, include encrypting, decrypting, and / or signing using the client workload's first cryptographic key.

[0065] At box 302, the HSM receives a proof document for a cryptographic operation request signed by a first proof service using a first cryptographic proof signing key. A client workload may request a cryptographic operation to be performed by the HSM, for example, by optionally passing a key block including the first cryptographic key and attributes assigned to the first cryptographic key as part of the cryptographic operation request, along with the proof document. If the client workload does not provide a proof document along with the cryptographic operation request, or provides an insufficient proof document, the HSM may, for example, temporarily reject the cryptographic operation request and request a proof document from the client workload. The requested proof document may, for example, be requested to include a random number. Alternatively, the HSM may, for example, invoke a remote proof protocol to receive a suitable proof document from the client workload requesting the cryptographic operation.

[0066] In box 304, the HSM uses one or more attributes of the first cryptographic key of the client workload to verify the cryptographic operation request and the supporting documentation for the cryptographic operation request. The cryptographic operation request and the supporting documentation can be verified if the supporting documentation received for the cryptographic operation request meets the workload requirements defined by the attributes of the first cryptographic key.

[0067] In box 306, after successfully verifying the cryptographic operation request and the proof document used for the cryptographic operation request, the HSM performs the cryptographic operation requested by the cryptographic operation request using the first cryptographic key of the client workload. After performing the requested cryptographic operation, the first cryptographic key and attributes of the received client workload can be deleted on the stateless HSM. If verification fails, the HSM can, for example, reject the cryptographic operation request. For example, an error code can be used to reject the cryptographic operation request. If the cryptographic operation request is temporarily rejected, the client workload can repeat the cryptographic operation request by retrieving, for example, an additional proof record from a local first proof service and providing it to the HSM.

[0068] In the example, the first cryptographic key received by the client workload, which is cryptographically protected using the HSM key, along with one or more attributes of the first cryptographic key, is decrypted by the HSM for use by the HSM. Therefore, after the encryption is decrypted using the HSM key, only the HSM can use the first cryptographic key.

[0069] In the example, the client workload receives the proof document for the password operation request along with the password operation request. In the example, the proof document for the password operation request is received from a first proof service, in addition to the password operation request itself.

[0070] In the example, random numbers are used to generate the proof document for the cryptographic operation request. Using random numbers allows the HSM to ensure, for example, that the proof document for the cryptographic operation request is used only once and will not be used again later to request another cryptographic operation. To successfully request another cryptographic operation, another proof document must be generated, which includes another random number. For example, the HSM can define and provide the random number to be incorporated into the proof document.

[0071] Figure 4 This is a flowchart of an exemplary method for preparing an update for a client workload. In box 400, the HSM receives an update preparation request from the client workload. The update preparation request is received along with a first cryptographic key for the client workload and one or more attributes of the first cryptographic key, which are cryptographically protected using the HSM key. In box 402, the HSM receives a proof document for the update preparation request, signed by a first proof service using a first cryptographic proof signing key. In box 404, the HSM receives the updated proof document. The updated proof document may, for example, include values ​​of workload requirements to be met by the updated client workload.

[0072] In box 406, the HSM uses one or more attributes of the first cryptographic key of the client workload to verify the update preparation request and the proof document used for the update preparation request. In box 408, the HSM uses the updated proof document to determine a set of one or more updated workload requirements for the updated client workload. For example, the values ​​of the workload requirements that the updated client workload must meet, as defined by the updated proof document, may be used for the updated client workload.

[0073] In box 410, after successfully verifying the update preparation request and the supporting documentation for the update preparation request, the HSM generates a second cryptographic key for the updated client workload and encodes one or more updated workload requests into one or more attributes of the generated second cryptographic key for the updated client workload to assign the availability of the generated second cryptographic key to the cryptographic operation request of the updated client workload. If verification fails, the HSM may, for example, reject the update preparation request.

[0074] The attributes of the second cryptographic key define the updated workload requirements, that is, the workload requirements that the proof documents of the updated client workload must meet so that the updated client workload can use the second cryptographic key.

[0075] In box 412, the HSM returns the generated updated second cryptographic key for the client workload, along with one or more attributes of the generated second cryptographic key, to the client workload for transmission to the updated client workload. The generated second cryptographic key for the client workload, along with one or more updated attributes of the generated second cryptographic key, is cryptographically protected using the HSM key.

[0076] Alternatively, in box 410, after successfully verifying the update preparation request and the supporting documentation for the update preparation request, the HSM can supplement one or more attributes of the first cryptographic key of the client workload with one or more additional attributes encoded for one or more updated workload requirements. Therefore, the availability of the first cryptographic key can be additionally assigned to the cryptographic operation request of the updated client workload. Thus, the client workload, as well as the updated client workload, can use the first cryptographic key. In this case, the HSM returns the first cryptographic key, along with one or more attributes of the first cryptographic key and one or more updated attributes of the first cryptographic key, to the client workload in box 412 for transmission to the updated client workload. The first cryptographic key of the client workload, having one or more attributes and one or more updated attributes, is cryptographically protected using the HSM key.

[0077] In the example, the first cryptographic key received by the client workload, which is cryptographically protected using the HSM key, along with one or more attributes of the first cryptographic key, is decrypted by the HSM for use by the HSM. Therefore, after the encryption is decrypted using the HSM key, only the HSM can use the first cryptographic key.

[0078] In the example, the updated proof document is the proof document of the updated client workload, signed by a second proof service using a second cryptographic proof signing key. The second proof service may be identified, for example, together with the first proof service. Alternatively, the second proof service may be, for example, different from the first proof service.

[0079] In the example, the updated proof document is received from the client workload along with the update preparation request. In the example, the updated proof document is also received from a second proof service, in addition to the update preparation request.

[0080] In the example, the updated proof document is a prediction of the proof document used to predict the updated client workload. In the example, random numbers are used to generate the updated proof document request.

[0081] In the example, the proof document used to update the preparation request is received from the client workload along with the update preparation request. In the example, in addition to the update preparation request, the proof document used to update the preparation request is received from the first proof service.

[0082] In the example, random numbers are used to generate the proof document for the update preparation request. Using random numbers allows the HSM to ensure, for example, that the proof document used for the update preparation request is used only once and will not be used again later to request another update preparation. To successfully request another update preparation, another proof document must be generated that includes another random number. For example, the HSM can define and provide the random number to be incorporated into the proof document.

[0083] In the example, the update preparation request from the client workload includes a shared secret. The shared secret is the secret to be passed from the client workload to the updated client workload. The shared secret is encoded by the HSM into one or more attributes of a generated second cryptographic key for the updated client workload.

[0084] In the example, an HSM key, independent of a first cryptographic key of the client workload, along with one or more attributes of the first cryptographic key of the client workload, is used to cryptographically protect a second cryptographic key generated for the updated client workload, along with one or more attributes of the generated second cryptographic key.

[0085] In the example, a second cryptographic key generated for the updated client workload, along with one or more attributes of the first cryptographic key of the client workload, is cryptographically protected in combination with the first cryptographic key of the client workload. This combination is configured to be used by both the client workload and the updated client workload.

[0086] Figure 5 This is a flowchart of an exemplary method for requesting an updated cryptographic key for an updated client workload. In block 500, the HSM receives a key update request from the updated client workload. The key update request is received together with a combination of a first cryptographic key for the client workload along with one or more attributes of the first cryptographic key for the client workload and a second cryptographic key for the updated client workload along with one or more attributes of the second cryptographic key for the updated client workload. This combination is cryptographically protected using the HSM key. Thus, in cases where client workload updates and key transfers are used, for example, the first cryptographic key is determined to be scoped to the client workload, while the second cryptographic key was generated during a previous iteration of the method and is determined to be scoped to the updated client workload.

[0087] In box 502, the HSM receives a proof document for a key update request signed by a second proof service using a second cryptographic proof signing key. In box 504, the HSM uses one or more attributes of the second cryptographic key for the updated client workload to verify the key update request and the proof document for the key update preparation request. In box 506, after successfully verifying the key update request and the proof document for the key update request, the HSM generates a third cryptographic key for the updated client workload and encodes one or more attributes of the second cryptographic key into one or more attributes of the generated third cryptographic key for the updated client workload to assign the availability of the generated third cryptographic key to the cryptographic operation requests of the updated client workload. If verification fails, the HSM may, for example, reject the key update request.

[0088] In box 508, the HSM returns the generated updated third cryptographic key of the client workload, along with one or more attributes of the generated third cryptographic key, to the updated client workload as an alternative to the first cryptographic key of the client workload along with one or more attributes of the first cryptographic key of the client workload, and the updated second cryptographic key of the client workload along with one or more attributes of the updated second cryptographic key. The generated third cryptographic key of the client workload, along with one or more attributes of the third cryptographic key, is cryptographically protected using the HSM key.

[0089] In the example, the first cryptographic key of the received client workload, encrypted using the HSM key, along with one or more attributes of the first cryptographic key of the client workload, and the second cryptographic key of the updated client workload, along with one or more attributes of the second cryptographic key of the updated client workload, are decrypted by the HSM. Therefore, after decryption using the HSM key, only the HSM can use the cryptographic key.

[0090] In the example, a third cryptographic key generated for updated client workloads, along with one or more attributes of the generated third cryptographic key, is cryptographically protected by using the HSM key. Therefore, after the encryption is decrypted using the HSM key, only the HSM can use the third cryptographic key.

[0091] In the example, the client workload receives a proof document for the key update request, along with the key update request itself. In addition to the key update request, the example also receives a proof document for the key update request from a first proof service.

[0092] In the example, a random number is used to generate the proof document for the key update request. Using a random number allows the HSM to ensure, for example, that the proof document used for the key update request is used only once and is not subsequently used to request the generation of another updated cryptographic key. To successfully request the generation of another updated cryptographic key, another proof document must be generated, which includes another random number. For example, the HSM can define and provide the random number to be incorporated into the proof document.

[0093] Figure 6 This is a flowchart of an exemplary method for a secure build server to request a cryptographic key for an updated client workload. In box 600, the HSM receives an update enable request from the secure build server. In box 602, the HSM receives a proof document for the enable request, signed by a third proof service using a third cryptographic proof signing key. In box 604, the HSM receives the updated proof document. In box 606, the HSM verifies the update enable request and the proof document used for the update enable request using a set of one or more predefined requirements of a workload allocation policy.

[0094] In box 608, the HSM uses the updated proof document to determine a set of one or more updated workload requirements for the updated client workload. In box 610, after successfully verifying the update enable request and the proof document used for the update enable request, the HSM generates a second cryptographic key for the updated client workload and encodes one or more updated workload requirements into one or more attributes of the generated second cryptographic key for the updated client workload to assign the availability of the generated second cryptographic key to the cryptographic operation request of the updated client workload. If verification fails, the HSM may, for example, reject the update enable request.

[0095] In box 612, the HSM returns the generated updated second cryptographic key for the client workload, along with one or more attributes of the generated second cryptographic key, to the security build server to pass it on to the updated client workload. The generated second cryptographic key for the client workload, along with one or more updated attributes of the generated second cryptographic key, is cryptographically protected using the HSM key.

[0096] Figure 7This is a block diagram of an exemplary system 101 including a remote stateless HSM 100 that provides stateless remote cryptography services for client workload 110. Client workload 110 can communicate with the remote stateless HSM 100 via network 714. Furthermore, the client workload provided by client 700 and executed by trusted execution entity 703 may be identified, for example, by hash 706 "SHA A", which provides the execution environment for client workload 110. Trusted execution entity 703 may be controlled, for example, by system administrator 702. In step 1, a local authentication service 140, for example, included by trusted execution entity 703, may examine client workload 110, and in step 2, generate an authentication document for client workload 110. The authentication document may include, for example, the following: {"machine": x390x, "hostname": webportal.com, “geo_location”: EU-South, "boadloader_csum": 549a2e…, "image_csum": 39dfa103…, "software_csum": 892df1d…, "hypervisor_csum": 64e1d2…, …}

[0097] In step 3, client workload 110 may request a cryptographic key, for example, from HSM 100. In step 4, HSM 100 may use component 720 to check and verify the request. Furthermore, HSM 100 may use workload allocation strategy 726 for checking. If the proof document has not yet been provided to HSM 100, HSM 100 may send the proof in step 5 and receive the proof document as a response to the proof query in step 6. In step 7, the received proof document may be verified by HSM 100 using component 720 and workload allocation strategy 726. The workload allocation strategy 726 may define the workload requirements that the proof document of client workload 110 must meet, for example, {"attest1": "image_csum", "attest2": "machine_csum", "attest3": "geo-location", …}.

[0098] For authentication, component 720 can, for example, use credentials provided by credential cache 722. Management service component 724 can manage the stateless remote cryptographic service provided by HSM 100 and define its characteristics, such as... {"hostname": cryptservice.com, "allow_net": 10.1.0.0 / 24, …}.

[0099] In step 8, the remote HSM access API can be used with HSM attributes provided by component 718 to generate the requested cryptographic key for the attributed client workload 110 using one or more cryptographic hardware components 728, 730. HSM attributes may include, for example: {"hsm_category": cex8s, "max_ops_per_sec": 5000, "max_tenants": 24, …}.

[0100] In step 9, the encrypted key block includes the generated cryptographic key and the attributes assigned to the generated cryptographic key. This key block can be used by the client workload 110 to request cryptographic operations performed by the HSM 100 upon request by the client workload 110. An exemplary key block encrypted by the HSM 100 may include, for example: {"key_id": 12345, "key_material": ac91392db54c…, “key_attributes”: { "expiry_time": 31_12_2022, "total_operations": 1000000, …}, “attestation_document”: { “machine_type”: s390x, "secret": secretorpubkey, "image_csum": 39dfa103…, "software_csum": 892df1d…, …}, “hsm_record”: { "hsm_category": cex8s, …}}.

[0101] Additionally, client workload 110 can be updated, resulting in an updated client workload 130. The updated client workload 130 can, for example, be executed by trusted execution entity 703 and can be identified by a hash 712 “SHA A*” different from the hash 712 “SHA A” of client workload 110. For the updated client workload 130, client workload 110 can, for example, request an updated cryptographic key with updated attributes. The resulting updated key block can be provided to the updated client workload 130 via an encrypted permanent keystore 706 of trusted execution entity 703. Therefore, the updated client workload 130 can also be enabled to use the stateless remote cryptographic service provided by HSM 100. For example, client workload 110 and the updated client workload 130 can share public secrets 704 and 710. Public secret 704 can, for example, be passed from client workload 110 to the updated client workload 130 via an encrypted permanent keystore 706. The local certification service 140 can also be configured to generate certification documents for updated client workloads 130.

[0102] Using a workload proof strategy, the HSM can, for example, maintain a hierarchical set of client workload requirements, containing requirements for proof records related to the characteristics of the client workload. Requirements may include, for example, expected proof record values, conditions regarding the proof signing key, and / or pointers to other requirements and / or pointers to expected values ​​within key blocks of keys stored in a cryptographic range. For example, these requirements may be stored in the workload proof strategy on the HSM side. Furthermore, for example, requirements may be stored as attributes in key blocks of cryptographically ranged keys returned to and stored by the client workload, with the HSM generating cryptographically ranged keys for that client workload.

[0103] The proof service can be, for example, a security service enabled on or from an execution environment where a client workload is executed, and the proof service will prove characteristics against that client workload. For example, the proof service can be based on a Trusted Platform Module (TPM) or implemented and provided by a Super Supervisor. A Super Supervisor is trusted firmware that uses memory protection hardware to implement memory protection. The proof service can, for example, implement the spirit of a TPM, namely that the measurement of the client workload is performed by a trusted component, i.e., trusted by the proof service. An alternative technology to a TPM that can implement this proof service is a Super Supervisor for secure clients, for example, proof functionality added to the secure execution of z16.

[0104] Workload distribution policies can be established, for example, by the HSM administrator. Alternatively, the workload distribution policy can be stored by the management server component. The HSM and the management server, which includes the management server component, can establish trust, for example. An exemplary workload distribution policy can be, for example, an implicit workload distribution policy. An implicit workload distribution policy can be, for example, a default workload distribution policy. For example, the attributes included in a key block can be defined to precisely match the provable characteristics of the client workload that generated the key block. Therefore, the key block can only be used by the client workload that generated it.

[0105] An exemplary workload allocation strategy could be, for example, an updatable workload allocation strategy. An updatable workload allocation strategy allows for the updating, i.e., modification, of the properties of a key block. For example, a client workload authorized to use the key block can request an update to the workload scope determination requirement, for instance, by providing proof that the updated client workload is also capable of using the key block. The HSM can then update the key block properties accordingly. The original client workload and the updated client workload can then use the resulting key block.

[0106] An exemplary workload allocation strategy could be, for example, a protected, updatable workload allocation strategy. A protected, updatable workload allocation strategy could, for example, enable additional steps for authenticating updated client workloads. For example, the original client workload and the updated client workload might have to share a common secret or credential. The original client workload requests that a public secret or credential be added to a key block. The public secret or credential can be added to the key block. The updated client workload can, for example, request the HSM to update the workload requirements, i.e., attributes, in the key block, while providing the expected public secret or credential along with its current proof document. If the public secret or credential provided by the updated client workload matches the public secret or credential previously added to the key block, the HSM can, for example, update the proof document. Alternatively or additionally, this can be combined with requirements for a proof signing key (e.g., having the same proof signing key, a public root certification authority (CA), and / or an intermediate CA) used to sign the proof documents of the original client workload and the updated client workload.

[0107] An exemplary workload allocation strategy could be, for example, a secure build workload allocation strategy. A secure build workload allocation strategy can enable a secure build server to be trusted to provide claims of range compatibility between different versions of client workloads (e.g., container sha1 is compatible with container sha2), or claims of range compatibility between proof documents. A secure build workload allocation strategy can, for example, define trusted client workloads, including, for example, reference proof documents and / or proof signing keys for the trusted workloads. This, for example, can establish a hierarchy of trusted client workloads.

[0108] The following example provides an evidence strategy that can be used to manage key usage and / or key updates. For example, strategies can be mixed and / or developed, and parameters can be updated, redefined, and / or inserted as needed by the system.

[0109] Exemplary implicit proof strategies may include, for example: {"policy_id": f9231, "client_id": 856ef3, "policy_name": implicit, “create_policy_vector”: { “key”: {“key_id”: 12345, “type”: symmetric, …}, “machine”: {“machine_type”: s390x, “fixed”: true}, "workload": {"image_csum": 39dfa103..., "fixed": true}, “software”: {“software_csum”: 892df1d…, “fixed”: true}, “boot”: {“bootloader_csum”: a31b03…, “fixed”: true}, “allow_list”: {“geo_location”: EU-South, “fixed”: true}, …} “use_policy_vector”: { “machine” : &key.attestation.machine, “workload”: &key.attestation.workload, “software”: &key.software.workload, …}}

[0110] Exemplary security attestation policies may include, for example: {"policy_id": 105ed8, “client_id”: f1903b, “policy_name”: secure, “policy_vector”: { “key”: {"key_id": 12345, ”type”: symmetric, …}, “machine”: {"machine_type": s390x, ”fixed”: false}, “workload”: {"image_csum": 39dfa103..., ”fixed”: false}, “software”: {"software_csum": 892df1d…, ”fixed”: false}, “boot”: {"bootloader_csum": a31b03…, ”fixed”: false}, “allow_list”: {"geo_location": EU - South, ”fixed”: false}, …}, use_policy_vector: { …}, “update_allow_list”: { “build_server”: { “key”: {"key_id": 12345, ”type”: symmetric, …}, “machine”: {"machine_type": s390x, ”fixed”: false}, “workload”: {"image_csum": 39dfa103..., ”fixed”: false}, “software”: {“software_csum”: 892df1d…, “fixed”: false}, “boot”: {“bootloader_csum”: a31b03…, “fixed”: false}, …}}}

[0111] Exemplary updatable proof strategies may include, for example: {"policy_id": 31dac3, "client_id": ab3103, "policy_name": updateable, “policy_vector”: { “key”: {“key_id”: 12345, “type”: symmetric, …}, “machine”: {“machine_type”: s390x, “fixed”: true}, "workload": {"image_csum": 39dfa103..., "fixed": false}, “software”: {“software_csum”: 892df1d…, “fixed”: false}, “boot”: {“bootloader_csum”: a31b03…, “fixed”: true}, “allow_list”: {“geo_location”: EU-South, “fixed”: false}, …}, use_policy_vector: { …}, “update_policy_vector”: { “machine” : &key.attestation.machine, "workload": {"image_csum": 49dfa103..., "fixed": false}, “software”: &key.software.workload, …}}

[0112] Exemplary protected updatable proof strategies may include, for example: {"policy_id": 932b1c, "client_id": ab923e, "policy_name": protected, "policy_vector": { "key": {"key_id": 12345, "type": symmetric, …}, "machine": {"machine_type": s390x, "fixed": false}, "workload": {"image_csum": 39dfa103..., "fixed": false}, "software": {"software_csum": 892df1d…, "fixed": false}, "boot": {"bootloader_csum": a31b03…, "fixed": false}, "allow_list": {"geo_location": EU - South, "fixed": false}, …}, use_policy_vector: { …}, "protected_update_policy_vector": { "key": {"key_id": 12345, "type": symmetric, …}, "machine": {"machine_type": s390x, "fixed": false}, "workload": {"image_csum": 39dfa103..., "fixed": false}, "software": {"software_csum": 892df1d…, "fixed": false}, "boot": {"bootloader_csum": a31b03…, "fixed": false}, …}}

[0113] Exemplary implicit proof strategies can for example include: {"policy_id": f9231, "client_id": 856ef3, "policy_name": implicit, "policy_vector": { "key": {"key_id": 12345, "type": symmetric, …}, "machine": {"machine_type": s390x, "fixed": true}, "workload": {"image_csum": 39dfa103..., "fixed": true}, "software": {"software_csum": 892df1d…, "fixed": true}, "boot": {"bootloader_csum": a31b03…, "fixed": true}, "allow_list": {"geo_location": EU - South, "fixed": true}, …}}

[0114] Exemplary security proof policies may include, for example: {"policy_id": 105ed8, "client_id": f1903b, "policy_name": secure, "policy_vector": { "key": {"key_id": 12345, "type": symmetric, …}, "machine": {"machine_type": s390x, "fixed": false}, "workload": {"image_csum": 39dfa103..., "fixed": false}, "software": {"software_csum": 892df1d…, "fixed": false}, "boot": {"bootloader_csum": a31b03…, "fixed": false}, "allow_list": {"geo_location": EU-South, "fixed": false}, …}}, "update_allow_list": { "build_server": { "build_server-0": {"secret": secretorfile, "machine_type": s390x,…}, "build_server-1": {"secret": secretorfile, "machine_type": x86, …},…}}}

[0115] Exemplary updatable attestation policies may include, for example: {"policy_id": 31dac3, "client_id": ab3103, "policy_name": updateable, "policy_vector": { "key": {"key_id": 12345, "type": symmetric, …}, "machine": {"machine_type": s390x, "fixed": true}, "workload": {"image_csum": 39dfa103..., "fixed": false}, "software": {"software_csum": 892df1d…, "fixed": false}, "boot": {"bootloader_csum": a31b03…, "fixed": true}, "allow_list": {"geo_location": EU-South, "fixed": false}, …}, "update_allow_list": { "host": { “host-0”: {“secret”: secretorfile, “machine_type”: x86, …}, “host-1”: {“secret”: secretorfile, “machine_type”: s390x, …},…}}}

[0116] Exemplary protected updatable proof strategies may include, for example: {"policy_id": 932b1c, "client_id": ab923e, "policy_name": protected, “policy_vector”: { “key”: {“key_id”: 12345, “type”: symmetric, …}, "machine": {"machine_type": s390x, "fixed": false}, "workload": {"image_csum": 39dfa103..., "fixed": false}, “software”: {“software_csum”: 892df1d…, “fixed”: false}, “boot”: {“bootloader_csum”: a31b03…, “fixed”: false}, “allow_list”: {“geo_location”: EU-South, “fixed”: false}, …}, “update_allow_list”: { “originator”: {“secret”: secretorfile, “machine_type”: x390x, …}, ”destination”: {“secret”: secretorfile, “machine_type”: s390x, …},…}}

[0117] The proof-based cryptographic key workload scope determination described herein can, for example, implement the scope determination of a cryptographic key to a specific client workload. For instance, only the individual client workload for which the cryptographic key was generated can be authorized to use the key. Workload scope determination can be implemented and verified by the HSM based on proof of the client workload's use of a proof document, which requests cryptographic services and / or operations provided by the HSM for the proven client workload. For example, client workload scope determination and related information can be implemented using requirements determined by the HSM during key generation based on the provided workload allocation policy and / or proof document. These requirements are, for example, stored within a key block. The key block can be stored independently of the HSM, for example, by the client workload. Furthermore, novel mechanisms for controlled client workload scope updates can be implemented. For example, a client workload can request the HSM to transfer or extend the workload scope defined by the key block to a newer workload. For example, a trusted third party, such as a secure build server, can request a transfer or extension of the workload scope on behalf of the client workload. Workload scope updates can, for example, be controlled using a shared secret passed between workloads.

[0118] HSMs can be enabled to control workload rights, such as requesting the generation and / or use of cryptographic workload-scoped keys using proof documentation provided for client workloads. Workload allocation policies can be used to define the requirements and control mechanisms for generating cryptographic workload-scoped keys and / or updating cryptographic workload-scoped keys.

[0119] This topic may include the following terms.

[0120] Clause 1. A method for implementing protection against cryptographic operations performed by a stateless hardware security module against a client workload, the method comprising: receiving a key generation request from the client workload by the hardware security module; receiving a proof document for the key generation request signed by a first proof service using a first cryptographic proof signing key by the hardware security module; verifying the key generation request and the proof document using one or more predefined requirements of a workload allocation strategy by the hardware security module; after successfully verifying the key generation request and the proof document for the key generation request, determining one or more sets of workload requirements for the client workload by the hardware security module; and generating a client... The first cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload, and to encode one or more workload requests into one or more attributes of the generated first cryptographic key for the client workload, so as to allocate the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload; and the hardware security module returns the generated first cryptographic key for the client workload, together with one or more attributes of the generated first cryptographic key, to the client workload, which is cryptographically protected using a hardware security module key.

[0121] Clause 2. The method of claim 1, wherein the first cryptographic key generated for the client workload, together with one or more attributes of the generated first cryptographic key, is cryptographically protected by encrypting it using a hardware security module key.

[0122] Clause 3. The method as described in any of the preceding claims uses one or more of the following to determine one or more workload requirements for the client workload: a proof document for the key generation request, and a workload allocation strategy.

[0123] Clause 4. The method as described in any of the preceding claims, wherein the proof document for the key generation request includes one or more of the following: a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition during the first boot of the execution environment of the client workload, wherein the first boot is performed using the root partition; a checksum of the root partition during the construction of the execution environment of the client workload, wherein the root partition is used to build the execution environment; a checksum of the client workload container image including the client workload; the geographical location of the machine on which the client workload is executed; an ID of a cryptographic proof signature verification key for verifying a signature generated using the first cryptographic proof signature key; and a credential for verifying a signature generated using the first cryptographic proof signature key.

[0124] Clause 5. The method as described in any of the preceding claims, wherein the workload allocation strategy comprises one or more of the following: an ID of a cryptographic proof signature verification key for verifying a signature generated using a first cryptographic proof signature key; a credential for verifying a signature generated using the first cryptographic proof signature key; a cryptographic proof signature verification key for verifying a signature generated using the first cryptographic proof signature key; a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, wherein the first boot is performed using the root partition; a checksum of the root partition at the build time of the execution environment of the client workload, wherein the root partition is used for the build of the execution environment; a client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; one or more predefined constraints for using the first cryptographic key generated for the client workload; and one or more rules for updating the first cryptographic key generated for the client workload.

[0125] Clause 6. The method as described in any of the preceding claims, wherein one or more attributes of the first cryptographic key generated for the client workload include one or more of the following: an ID of a cryptographic proof signature verification key for verifying a signature generated using the first cryptographic proof signature key; a cryptographic proof signature verification key for verifying a signature generated using the first cryptographic proof signature key; a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, wherein the first boot is performed using the root partition; a checksum of the root partition at the build time of the execution environment of the client workload, wherein the root partition is used for the build of the execution environment; a client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; and the ID of the first cryptographic key generated for the client workload.

[0126] Clause 7. The method as described in any of the preceding claims, further comprising: receiving a cryptographic operation request from a client workload by a hardware security module, the cryptographic operation request being received together with a first cryptographic key of the client workload and one or more attributes of the first cryptographic key, and cryptographically protecting it using a hardware security module key; receiving by the hardware security module a proof document for the cryptographic operation request signed by a first proof service using a first cryptographic proof signing key; verifying the cryptographic operation request and the proof document for the cryptographic operation request by the hardware security module using one or more attributes of the first cryptographic key of the client workload; and, after successful verification of the cryptographic operation request and the proof document for the cryptographic operation request, performing the cryptographic operation requested by the cryptographic operation request using the first cryptographic key of the client workload.

[0127] Clause 8. The method of claim 7, wherein the first cryptographic key of the received client workload, together with one or more attributes of the first cryptographic key, is cryptographically protected by encrypting it using a hardware security module key, which is then decrypted by the hardware security module for use by the hardware security module.

[0128] Clause 9. The method as claimed in any of the preceding claims, further comprising: receiving an update preparation request from a client workload by a hardware security module, the update preparation request being received together with a first cryptographic key of the client workload and one or more attributes of the first cryptographic key, and cryptographically protecting it using a hardware security module key; receiving, by the hardware security module, a proof document for the update preparation request signed by a first proof service using a first cryptographic proof signing key; receiving, by the hardware security module, an updated proof document; verifying, by the hardware security module, the update preparation request and the proof document for the update preparation request using one or more attributes of the first cryptographic key of the client workload; and using, by the hardware security module, determining one or more update workload requirements for the updated client workload using the updated proof document. The set; upon successful verification of the update preparation request and the proof document for the update preparation request, generating a second cryptographic key for the updated client workload, and encoding one or more update workload requests into one or more attributes of the generated second cryptographic key for the updated client workload for use in cryptographic operation requests to allocate the availability of the generated second cryptographic key to the updated client workload; and the hardware security module returning the generated second cryptographic key for the updated client workload, together with one or more attributes of the generated second cryptographic key, to the client workload for transmission to the updated client workload, using a hardware security module key to cryptographically protect the generated second cryptographic key for the client workload, together with one or more updated attributes of the generated second cryptographic key.

[0129] Clause 10. The method of claim 9, wherein the first cryptographic key of the received client workload, together with one or more attributes of the first cryptographic key, is cryptographically protected by encrypting it using a hardware security module key, which is then decrypted by the hardware security module for use by the hardware security module.

[0130] Clause 11. The method as described in any one of claims 9 to 10, wherein the updated proof document is the proof document of the updated client workload implemented by the second proof service, which is signed using the second cryptographic proof signing key.

[0131] Clause 12. The method as described in any one of claims 9 to 10, wherein the updated proof document is a prediction of the proof document used to predict the updated client workload.

[0132] Clause 13. The method of any one of claims 9 to 12, wherein the update preparation request from the client workload includes a shared secret, the shared secret being a secret to be passed from the client workload to the updated client workload, the shared secret being encoded by the hardware security module as an attribute of one or more attributes of a second cryptographic key generated by the updated client workload.

[0133] Clause 14. The method of any one of claims 9 to 13, wherein a generated, updated second cryptographic key for the client workload, together with one or more attributes of the first cryptographic key for the client workload, is cryptographically protected using a hardware security module key independent of a first cryptographic key for the client workload.

[0134] Clause 15. The method of any one of claims 9 to 13, wherein the generated updated client workload's second cryptographic key, together with one or more attributes of the generated second cryptographic key, is cryptographically protected in combination with the client workload's first cryptographic key, together with one or more attributes of the client workload's first cryptographic key, the combination being configured for use by the client workload and the updated client workload.

[0135] Clause 16. The method of claim 15, further comprising: receiving a key update request from an updated client workload by a hardware security module, the key update request being received together with a first cryptographic key of the client workload along with one or more attributes of the first cryptographic key of the client workload and a second cryptographic key of the updated client workload along with one or more attributes of the second cryptographic key of the updated client workload, the combination being cryptographically protected using a hardware security module key; receiving by the hardware security module a proof document for the key update request signed by a second proof service using a second cryptographic proof signing key; verifying the key update request and the proof document for the key update request by the hardware security module using one or more attributes of the second cryptographic key of the updated client workload; and, after successfully verifying the key update request and the proof document for the key update request, generating an updated client workload. The third cryptographic key of the client workload is used to encode one or more attributes of the second cryptographic key into one or more attributes of the generated third cryptographic key of the updated client workload for use in cryptographic operation requests that allocate the availability of the generated third cryptographic key to the updated client workload; and the generated third cryptographic key of the updated client workload, together with one or more attributes of the generated third cryptographic key, is returned to the updated client workload by the hardware security module as a replacement for a combination of the first cryptographic key of the client workload together with one or more attributes of the first cryptographic key of the client workload and the second cryptographic key of the updated client workload together with one or more attributes of the second cryptographic key of the updated client workload, and the generated third cryptographic key of the client workload together with one or more attributes of the third cryptographic key is cryptographically protected using a hardware security module key.

[0136] Clause 17. The method of claim 16, wherein the combination of the first cryptographic key of the received client workload together with one or more attributes of the first cryptographic key of the client workload and the second cryptographic key of the received updated client workload together with one or more attributes of the second cryptographic key of the updated client workload is cryptographically protected by using a hardware security module key, which is decrypted by the hardware security module.

[0137] Clause 18. The method as described in any of the preceding clauses, further comprising: receiving an update enable request from a security building server by a hardware security module; receiving, by the hardware security module, a proof document for the enable request signed by a third proof service using a third cryptographic proof signing key; receiving an updated proof document by the hardware security module; verifying the update enable request and the proof document for the update enable request using a set of one or more predefined requirements of a workload allocation strategy by the hardware security module; determining, by the hardware security module, a set of one or more updated workload requirements for updated client workloads using the updated proof document; and generating, upon successful verification of the update enable request and the proof document for the update enable request. The updated client workload's second cryptographic key, and encoding one or more updated workload requests into one or more attributes of the generated second cryptographic key of the updated client workload for use in cryptographic operation requests that allocate the availability of the generated second cryptographic key to the updated client workload; and the hardware security module returning the generated second cryptographic key of the updated client workload, along with one or more attributes of the generated second cryptographic key, to the security building server for delivery to the updated client workload, using a hardware security module key to cryptographically protect the generated second cryptographic key of the client workload, along with one or more updated attributes of the generated second cryptographic key.

[0138] Clause 19. A computer program product for implementing protection against cryptographic operations performed by a stateless hardware security module against a client workload, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therein, the computer-readable program code being configured to implement a method comprising: receiving a key generation request from a client workload by a hardware security module; receiving, by the hardware security module, a proof document for the key generation request signed by a first proof service using a first cryptographic proof signing key; verifying the key generation request and the proof document by the hardware security module using one or more predefined requirements of a workload allocation strategy; and, after successfully verifying the key generation request and the proof document for the key generation request, the hardware security module... The hardware security module determines a set of one or more workload requests for a client workload; generates a cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload, and encodes one or more workload requests into one or more attributes of the generated cryptographic key for the client workload to allocate the availability of the generated cryptographic key to the cryptographic operation requests of the client workload; and returns the generated cryptographic key for the client workload, along with one or more attributes of the generated cryptographic key, to the client workload using a hardware security module key to cryptographically protect the generated cryptographic key for the client workload, along with one or more attributes of the generated cryptographic key.

[0139] Clause 20. A stateless hardware security module for implementing protection against cryptographic operations performed by the hardware security module against a client workload, the hardware security module being configured to: receive a key generation request from the client workload; receive a proof document for the key generation request signed by a first proof service using a first cryptographic proof signing key; verify the key generation request and the proof document using a set of one or more predefined requirements of a workload allocation strategy; after successfully verifying the key generation request and the proof document for the key generation request, determine a set of one or more workload requirements for the client workload; generate a cryptographic key for the client workload, the cryptographic key being used to provide cryptographic operations for the client workload, and encode one or more workload requirements into one or more attributes of the generated cryptographic key for the client workload to allocate the availability of the generated cryptographic key to the cryptographic operation requests of the client workload; and return the generated cryptographic key for the client workload, together with one or more attributes of the generated cryptographic key, to the client workload, using a hardware security module key to cryptographically protect the generated cryptographic key for the client workload, together with one or more attributes of the generated cryptographic key.

[0140] Now for reference Figure 8 The illustration depicts a computing environment 800. The computing environment 800 includes examples of environments for executing at least some of the computer code involved in performing the methods of the present invention, such as table storage code 900. In addition to box 900, the computing environment 800 includes, for example, a computer 801, a wide area network (WAN) 802, an end-user equipment (EUD) 803, a remote server 804, a public cloud 805, and a private cloud 806. In this embodiment, the computer 801 includes a processor group 810 (including processing circuitry 820 and cache 821), a communication structure 811, volatile memory 812, persistent storage device 813 (including an operating system 822 and box 900, as described above), a peripheral device group 814 (including a user interface (UI) device group 823, a storage device 824, and an Internet of Things (IoT) sensor group 825), and a network module 815. The remote server 804 includes a remote database 830. The public cloud 805 includes a gateway 840, a cloud coordination module 841, a host physical unit 842, a virtual machine unit 843, and a container unit 844.

[0141] Computer 801 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or to be developed in the future capable of running programs, accessing networks, or querying databases such as remote database 830. As is well known in the field of computer technology, and depending on the technology, the performance of a computer-implemented method can be distributed across multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 800, the detailed discussion focuses on a single computer, specifically computer 801, to keep the presentation as simple as possible. Computer 801 can reside in the cloud, even... Figure 8 It is not shown in the cloud. On the other hand, computer 801 does not need to be in the cloud unless it can be definitively indicated to any extent.

[0142] Processor group 810 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 820 may be distributed across multiple packages, such as multiple cooperating integrated circuit chips. Processing circuitry 820 may implement multiple processor threads and / or multiple processor cores. Cache 821 is memory located within the processor chip package and is typically used for data or code that should be readily accessible by the threads or cores running on processor group 810. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache in the processor group may be located “off-chip.” In some computing environments, processor group 810 may be designed to work with qubits and perform quantum computing.

[0143] Computer-readable program instructions are typically loaded onto computer 801 to cause a series of operational steps to be executed by processor assembly 810 of computer 801, thereby implementing a computer-implemented method, such that the instructions thus executed instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively, the “method of the invention”). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 821 and other storage media discussed below. The program instructions and associated data are accessed by processor assembly 810 to control and direct the execution of the method of the invention. In computing environment 800, at least some of the instructions for performing the method of the invention may be stored in persistent storage device 813 in block 900.

[0144] The communication structure 811 is a signal transmission path that allows the various components of the computer 801 to communicate with each other. Typically, this structure consists of switches and conductive paths, such as switches and conductive paths that form buses, bridges, physical input / output ports, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0145] Volatile memory 812 is any type of volatile memory known now or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 812 is characterized by random access, but this is not necessary unless explicitly stated otherwise. In computer 801, volatile memory 812 is located in a single package and is internal to computer 801; however, as an alternative or supplement, volatile memory may be distributed across multiple packages and / or located externally relative to computer 801.

[0146] The persistent storage device 813 is any form of non-volatile storage device for a computer, now known or to be developed in the future. The non-volatility of this storage device means that the stored data is retained regardless of whether power is supplied to the computer 801 and / or directly to the persistent storage device 813. The persistent storage device 813 may be a read-only memory (ROM), but typically at least a portion of the persistent storage device allows data to be written, deleted, and rewritten. Some common forms of persistent storage devices include hard disks and solid-state storage devices. The operating system 822 may take several forms, such as various known proprietary operating systems or operating systems employing an open-source portable operating system interface type with a kernel. The code included in box 900 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0147] Peripheral device group 814 includes a collection of peripheral devices for computer 801. Data communication connections between peripheral devices and other components of computer 801 can be implemented in various ways, such as Bluetooth connectivity, near field communication (NFC) connectivity, connections made by cables (such as Universal Serial Bus (USB) type cables), plug-in connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device group 823 may include components such as displays, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage device 824 is external memory, such as an external hard drive, or pluggable memory, such as an SD card. Storage device 824 may be persistent and / or volatile. In some embodiments, storage device 824 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 801 requires a large amount of storage (e.g., where computer 801 locally stores and manages a large database), the storage device can be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor group 825 consists of sensors that can be used in IoT applications. For example, one sensor could be a thermometer, while another could be a motion detector.

[0148] Network module 815 is a collection of computer software, hardware, and firmware that allows computer 801 to communicate with other computers via WAN 802. Network module 815 may include hardware such as a modem or Wi-Fi transceiver, software for packetizing and / or depacketizing data transmitted over the communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control and network forwarding functions of network module 815 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 815 are executed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for performing the methods of the present invention can typically be downloaded to computer 801 from an external computer or external storage device via a network adapter card or network interface included in network module 815.

[0149] A WAN 802 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology known now or developed in the future for transmitting computer data. In some embodiments, a WAN 802 may be replaced by and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include computer hardware such as copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0150] End User Equipment (EUD) 803 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 801) and can take any of the forms discussed above in conjunction with computer 801. EUD 803 typically receives helpful and useful data from the operation of computer 801. For example, assuming computer 801 is designed to provide recommendations to the end user, these recommendations are typically transmitted from network module 815 of computer 801 to EUD 803 via WAN 802. In this way, EUD 803 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 803 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0151] Remote server 804 is any computer system that provides at least some data and / or functionality to computer 801. Remote server 804 can be controlled and used by the same entity operating computer 801. Remote server 804 represents a machine that collects and stores helpful and useful data used by other computers, such as computer 801. For example, if computer 801 is designed and programmed to provide recommendations based on historical data, that historical data can be provided to computer 801 from a remote database 830 of remote server 804.

[0152] Public cloud 805 is any computer system that can be used by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities (particularly data storage (cloud storage) and computing power) without the need for direct, active management by users. Cloud computing typically leverages resource sharing to achieve scalability and economy. Direct and active management of the computing resources of public cloud 805 is performed by the computer hardware and / or software of cloud coordination module 841. The computing resources provided by public cloud 805 are typically implemented by virtual computing environments that run on various computers constituting host physical machine group 842, which is the entire domain of physical computers in public cloud 805 and / or available to the public cloud. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine group 843 and / or containers from container group 844. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after the VCE is instantiated. Cloud coordination module 841 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages the active instantiation of VCE deployments. Gateway 840 is a collection of computer software, hardware, and firmware that allows public cloud 805 to communicate via WAN 802.

[0153] Now, we will provide some further explanation of Virtualized Computing Environments (VCEs). A VCE can be stored as an "image." New active instances of a VCE can be instantiated from this image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows multiple isolated user-space instances, called containers, to exist. From the perspective of the programs running within them, these isolated user-space instances typically appear as actual computers. Computer programs running on a regular operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices allocated to the container; this is a characteristic known as containerization.

[0154] Private cloud 806 is similar to public cloud 805, except that computing resources are available only to a single enterprise. While private cloud 806 is depicted as communicating with WAN 802, in other embodiments, private cloud can be completely disconnected from the internet and accessed only via a local / private network. Hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types) typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardization or proprietary technology that enables coordination, management, and / or data / application portability across the multiple component clouds. In this embodiment, public cloud 805 and private cloud 806 are both part of a larger hybrid cloud.

[0155] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0156] The characteristics are as follows:

[0157] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

[0158] Wide Area Network (WAN) Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0159] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Location independence has significance because consumers typically do not control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0160] Rapid Flexibility: In some cases, the ability to scale outwards and inwards quickly and flexibly can be provided. For consumers, the available capacity often appears unlimited and can be purchased in any quantity at any time.

[0161] Measurement services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the providers and consumers of the services being utilized.

[0162] The service model is as follows:

[0163] Software as a Service (SaaS): The capability offered to consumers is the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0164] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications onto cloud infrastructure using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environments.

[0165] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating system, storage, deployed applications, and possibly limited control over chosen networking components (e.g., host firewalls).

[0166] The deployment model is as follows:

[0167] Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0168] Community cloud: Cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0169] Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0170] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0171] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure of a network of interconnected nodes.

[0172] Now for reference Figure 9 The diagram illustrates an illustrative cloud computing environment 1050. As shown, the cloud computing environment 1050 includes one or more cloud computing nodes 1010 to which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, personal digital assistants (PDAs) or cellular phones 1054A, desktop computers 1054B, laptop computers 1054C, and / or automotive computer systems 54N. The nodes 1010 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 1050 to provide infrastructure, platform, and / or software as a service, without requiring cloud consumers to maintain resources on their local computing devices. It is understood that... Figure 9 The types of computing devices 1054A-N shown are for illustrative purposes only, and computing node 1010 and cloud computing environment 1050 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0173] Now for reference Figure 10 This demonstrates the 1050 cloud computing environment ( Figure 9 This provides a set of functional abstractions. These can be understood in advance. Figure 10 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0174] The hardware and software layer 1060 includes hardware and software components. Examples of hardware components include: a host 1061; a server 1062 based on a RISC (Reduced Instruction Set Computer) architecture; a server 1063; a blade server 1064; a storage device 1065; and network and networking components 1066. In some embodiments, software components include network application server software 1067 and database software 1068. Furthermore, hardware components may include encryption hardware 1069 according to the content of this subject matter, for example, as referenced... Figure 1 Or as described in 7, it is configured to perform methods according to the content of this topic, for example, as referenced. Figures 2 to 6As described, the encryption hardware 1069 can, for example, implement a remote stateless HSM.

[0175] The virtualization layer 1070 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 1071; virtual storage 1072; virtual network 1073, including virtual private network; virtual application and operating system 1074; and virtual client 1075.

[0176] In one example, management layer 1080 may provide the functionality described below: Resource Provisioning 1081 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 1082 provides cost tracking when utilizing resources in the cloud computing environment, as well as billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 1083 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 1084 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 1085 provides pre-scheduling and procurement of cloud resources, where future needs are anticipated according to the SLA.

[0177] Workload layer 1090 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: map creation and navigation 1091; software development and lifecycle management 1092; virtual classroom education delivery 1093; data analysis and processing 1094; transaction processing 1095; and stateless remote encryption services 1096 using encryption hardware 1069 according to the content of this topic, for example, as referenced. Figures 1 to 7 As described.

[0178] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0179] Various aspects of this disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). Regarding any flowchart, depending on the technology involved, operations may be performed in a different order than that shown in a given flowchart. For example, again according to the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0180] Computer Program Product Embodiment (“CPP Embodiment” or “CPP”) is a term used in this disclosure to describe any collection of one or more storage media (also referred to as “media”) collectively included in a collection of one or more storage devices, the collection of one or more storage devices collectively including machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A “storage device” is any tangible device capable of holding and storing instructions used by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / platforms formed in the main surface of the disk), or any suitable combination of the foregoing. Computer-readable storage media, as used in this disclosure, should not be construed as storing transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As those skilled in the art will understand, data is typically moved at certain incidental points in time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection; however, this does not make the storage device transient, because the data is not transient when it is stored.

Claims

1. A method for protecting cryptographic operations performed by a stateless hardware security module against a client workload, the method comprising: The hardware security module receives a key generation request from the client workload. The hardware security module receives a proof document for the key generation request, signed by the first proof service using the first cryptographic proof signing key; The hardware security module uses a set of one or more predefined requirements based on a workload allocation strategy to verify the key generation request and proof document; After successfully verifying the key generation request and the proof document for the key generation request, the hardware security module determines a set of one or more workload requirements for the client workload; The hardware security module generates a first cryptographic key for the client workload. The first cryptographic key will be used by the hardware security module to provide cryptographic operations for the client workload. The hardware security module also encodes one or more workload requests into one or more attributes of the generated first cryptographic key for the client workload to assign the availability of the generated first cryptographic key to the cryptographic operation requests of the client workload. as well as The hardware security module returns the first cryptographic key generated by the client workload, along with one or more attributes of the first cryptographic key, to the client workload, and uses the hardware security module key to cryptographically protect the first cryptographic key generated by the client workload, along with one or more attributes of the first cryptographic key.

2. The method according to the preceding claim, wherein the first cryptographic key generated for the client workload, together with one or more attributes of the generated first cryptographic key, is cryptographically protected by encrypting it using the hardware security module key.

3. The method according to any one of the preceding claims, using one or more of the following to determine the one or more workload requirements for the client workload: the proof document for the key generation request, and a workload allocation strategy.

4. The method according to any one of the preceding claims, wherein the proof document for the key generation request comprises one or more of the following: a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, the root partition being used for the first boot; and a checksum of the root partition at the construction of the execution environment of the client workload, the root partition being used for constructing the execution environment. The checksum of the client workload container image, including the client workload; the geographic location of the machine executing the client workload thereon; The ID of the cryptographic proof signature verification key used to verify the signature generated using the first cryptographic proof signature key; and the credential used to verify the signature generated using the first cryptographic proof signature key.

5. The method according to any one of the preceding claims, wherein the workload allocation strategy comprises one or more of the following: an ID of the cryptographic proof signature verification key for verifying the signature generated using the first cryptographic proof signature key; a credential for verifying the signature generated using the first cryptographic proof signature key; the cryptographic proof signature verification key for verifying the signature generated using the first cryptographic proof signature key; a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, the root partition being used for the first boot; a checksum of the root partition at the build time of the execution environment of the client workload, the root partition being used for the build of the execution environment; a client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; one or more predefined constraints for using the first cryptographic key generated for the client workload; and one or more rules for updating the first cryptographic key generated for the client workload.

6. The method according to any one of the preceding claims, wherein, The first cryptographic key generated by the client workload includes one or more of the following attributes: an ID of the cryptographic proof signature verification key for verifying the signature generated using the first cryptographic proof signature key; an ID of the cryptographic proof signature verification key for verifying the signature generated using the first cryptographic proof signature key; a machine type ID of the machine on which the client workload is executed; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the first boot of the execution environment of the client workload, the root partition being used for the first boot; a checksum of the root partition at the build time of the execution environment of the client workload, the root partition being used for the build of the execution environment; a client workload container image including the client workload; the geographic location of the machine on which the client workload is executed; and the ID of the first cryptographic key generated by the client workload.

7. The method according to any one of the preceding claims, further comprising: The hardware security module receives a password operation request from the client workload. The password operation request is received together with the first password key of the client workload and one or more attributes of the first password key, and is passwordally protected using the hardware security module key. The hardware security module receives a proof document for the cryptographic operation request, which is signed by the first proof service using the first cryptographic proof signing key. The hardware security module uses one or more attributes of the first cryptographic key of the client workload to verify the cryptographic operation request and the proof document for the cryptographic operation request; After successfully verifying the cryptographic operation request and the proof document of the cryptographic operation request, the cryptographic operation requested by the cryptographic operation request is performed using the first cryptographic key of the client workload.

8. The method according to the preceding claims, wherein the first cryptographic key received by the client workload, together with one or more attributes of the first cryptographic key, is cryptographically protected by encryption using the hardware security module key, the hardware security module key being decrypted by the hardware security module for use by the hardware security module.

9. The method according to any one of the preceding claims, further comprising: The hardware security module receives an update preparation request from the client workload. The update preparation request is received together with the first cryptographic key of the client workload and one or more attributes of the first cryptographic key, and is cryptographically protected using the hardware security module key. The hardware security module receives the proof document for the update preparation request, which is signed by the first proof service using the first cryptographic proof signing key; The updated proof document is received by the hardware security module; The hardware security module uses one or more attributes of the first cryptographic key of the client workload to verify the update preparation request and the proof document for the update preparation request; The hardware security module uses the updated certification documents to determine a set of one or more updated workload requirements for the updated client workloads; Upon successful verification of the update preparation request and the proof document for the update preparation request, a second cryptographic key for the updated client workload is generated, and the one or more update workload requirements are encoded into one or more attributes of the generated second cryptographic key for the updated client workload, for use in allocating the availability of the generated second cryptographic key to the cryptographic operation request of the updated client workload. as well as The hardware security module returns the generated second cryptographic key of the updated client workload, along with one or more attributes of the generated second cryptographic key, to the client workload for transmission to the updated client workload. The hardware security module key is used to cryptographically protect the generated second cryptographic key of the client workload, along with the one or more updated attributes of the generated second cryptographic key.

10. The method according to the preceding claim, wherein the first cryptographic key received by the client workload, together with one or more attributes of the first cryptographic key, is cryptographically protected by encryption using the hardware security module key, the hardware security module key being decrypted by the hardware security module for use by the hardware security module.

11. The method according to any one of the preceding two claims, wherein the updated proof document is an updated client workload proof document implemented by a second proof service using a second cryptographic proof signing key.

12. The method according to any one of the preceding three claims, wherein the updated proof document is a prediction of the proof document used to predict the updated client workload.

13. The method according to any one of the preceding four claims, wherein the update preparation request from the client workload includes a shared secret, the shared secret being a secret to be passed from the client workload to the updated client workload, the shared secret being encoded by the hardware security module as an attribute of one or more attributes of a second cryptographic key generated by the updated client workload.

14. The method according to any one of the preceding five claims, wherein the first cryptographic key, independent of the client workload, together with one or more attributes of the first cryptographic key of the client workload, and the second cryptographic key generated by the updated client workload, together with one or more attributes of the generated second cryptographic key, are cryptographically protected using the hardware security module key.

15. The method according to any one of the preceding six claims, wherein the generated second cryptographic key of the updated client workload, together with one or more attributes of the generated second cryptographic key, is cryptographically protected in combination with the first cryptographic key of the client workload and one or more attributes of the first cryptographic key of the client workload, the combination being configured for use by the client workload and the updated client workload.

16. The method according to the preceding claim, further comprising: The hardware security module receives a key update request from the updated client workload. The key update request is received together with a combination of the first cryptographic key of the client workload and one or more attributes of the first cryptographic key of the client workload, and a combination of the second cryptographic key of the updated client workload and one or more attributes of the second cryptographic key of the updated client workload, the combination being cryptographically protected using the hardware security module key. The hardware security module receives a proof document for the key update request, which is signed by the second proof service using the second cryptographic proof signing key. The hardware security module uses one or more attributes of the second cryptographic key of the updated client workload to verify the key update request and the proof document for the key update preparation request; After successfully verifying the key update request and the proof document for the key update request, a third cryptographic key for the updated client workload is generated, and one or more attributes of the second cryptographic key are encoded as one or more attributes of the generated third cryptographic key for the updated client workload, for use in allocating the availability of the generated third cryptographic key to cryptographic operation requests of the updated client workload. as well as The hardware security module returns the generated third cryptographic key of the updated client workload, along with one or more attributes of the generated third cryptographic key, to the updated client workload as a replacement for the combination of the first cryptographic key of the client workload along with one or more attributes of the first cryptographic key of the client workload and the second cryptographic key of the updated client workload along with one or more attributes of the second cryptographic key of the updated client workload. The hardware security module key is used to cryptographically protect the generated third cryptographic key of the client workload along with one or more attributes of the third cryptographic key.

17. The method according to the preceding claim, wherein the first cryptographic key of the received client workload, together with one or more attributes of the first cryptographic key of the client workload and the combination of the second cryptographic key of the updated client workload, together with one or more attributes of the second cryptographic key of the updated client workload, are cryptographically protected by encrypting the hardware security module key, the hardware security module key being decrypted by the hardware security module.

18. The method according to any one of the preceding claims, further comprising: The hardware security module receives an update activation request from the security build server; The hardware security module receives a proof document for the enable request, which is signed by a third proof service using a third cryptographic proof signing key. The updated proof document is received by the hardware security module; The hardware security module uses a set of one or more predefined requirements of the workload allocation policy to verify the update enable request and the proof document for the update enable request; The hardware security module uses the updated certification documents to determine a set of one or more updated workload requirements for the updated client workload; After successfully verifying the update enable request and the proof document for the update enable request, a second cryptographic key for the updated client workload is generated, and the one or more updated workload requirements are encoded into one or more attributes of the generated second cryptographic key for the updated client workload for allocating the availability of the generated second cryptographic key to the cryptographic operation request of the updated client workload. as well as The hardware security module returns the generated second cryptographic key of the updated client workload, along with one or more attributes of the generated second cryptographic key, to the security building server for transmission to the updated client workload. The hardware security module key is used to cryptographically protect the generated second cryptographic key of the client workload, along with one or more updated attributes of the generated second cryptographic key.

19. A computer program product for implementing protection against cryptographic operations performed by a stateless hardware security module on a client workload, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therein, the computer-readable program code being configured to implement a method comprising: The hardware security module receives a key generation request from the client workload. The hardware security module receives a proof document for the key generation request, signed by the first proof service using the first cryptographic proof signing key; The hardware security module uses a set of one or more predefined requirements based on a workload allocation strategy to verify the key generation request and proof document; After successfully verifying the key generation request and the proof document for the key generation request, the hardware security module determines a set of one or more workload requirements for the client workload; The hardware security module generates a cryptographic key for the client workload, which will be used by the hardware security module to provide cryptographic operations for the client workload. The hardware security module also encodes one or more workload requests into one or more attributes of the generated cryptographic key for the client workload to allocate the availability of the generated cryptographic key to the cryptographic operation requests of the client workload. as well as The hardware security module returns the generated cryptographic key of the client workload, along with one or more attributes of the generated cryptographic key, to the client workload, and uses the hardware security module key to cryptographically protect the generated cryptographic key of the client workload along with one or more attributes of the generated cryptographic key.

20. A stateless hardware security module for protecting cryptographic operations performed by the hardware security module against client workloads, the hardware security module being configured to: Receive a key generation request from the client workload; Receive a proof document for a key generation request that has been signed by a first proof service using a first cryptographic proof signing key; The key generation request and proof document are verified using a set of one or more predefined requirements of a workload distribution strategy. After successfully verifying the key generation request and the proof document for the key generation request, a set of one or more workload requirements for the client workload is determined; Generate a cryptographic key for the client workload, the cryptographic key will be used to provide cryptographic operations for the client workload, and encode the one or more workload requests into one or more attributes of the generated cryptographic key for the client workload to assign the availability of the generated cryptographic key to the cryptographic operation requests of the client workload; as well as The generated cryptographic key of the client workload, along with one or more attributes of the generated cryptographic key, is returned to the client workload, and the generated cryptographic key of the client workload, along with one or more attributes of the generated cryptographic key, is cryptographically protected using a hardware security module key.

Images