How to enable security for encryption operations, security module

Abstract

This disclosure relates to a method for enabling the security of cryptographic operations performed by a stateless hardware security module for a client workload, the method comprising the steps of: a key generation request from the client workload and an authentication document; a step of verifying the key generation request and the authentication document; a step of determining workload requirements for the client workload; a step of generating an encryption key; and a step of encoding the determined workload requirements as attributes of the generated encryption key. The generated encryption key and attributes, cryptographically protected using the hardware security module key, are returned to the client workload. (Figure 2)

Description

Background Art

[0001] The present invention relates to the field of digital computer systems, and more specifically, to a method for enabling the security of encryption operations performed by a stateless hardware security module for client workloads.

[0002] A stateless hardware security module can be used to perform encryption operations for client workloads. However, enabling the security of encryption operations performed by a stateless hardware security module for client workloads can be a challenging task.

Summary of the Invention

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

[0004] In one embodiment, the present invention relates to a method for enabling security for cryptographic operations performed by a stateless hardware security module for a client workload. The method comprises the step of receiving a key generation request from a client workload by the hardware security module. The hardware security module receives an authentication document for the key generation request signed by a first authentication service using a first cryptographic authentication signing key. The hardware security module verifies the key generation request and the authentication document using one or more predefined sets of requirements for a workload assignment policy. When the verification of the key generation request and the authentication document for the key generation request is successful, the hardware security module determines one or more sets of workload requirements for the client workload. The hardware security module generates a first encryption key for the client workload to be used by the hardware security module to provide cryptographic operations for the client workload, and encodes one or more workload requirements as one or more attributes of the first encryption key generated by the client workload to assign the availability of the generated first encryption key to the cryptographic operation request by the client workload. The hardware security module returns the first encryption key generated by the client workload, with one or more attributes of the generated first encryption key, to the client workload. The first encryption key generated by a client workload, which has one or more attributes of the first encryption key it generates, is cryptographically protected using a hardware security module key.

[0005] In another embodiment, the present invention relates to a computer program product for enabling security of cryptographic operations performed by a stateless hardware security module for a client workload. The computer program product comprises a computer-readable storage medium in which computer-readable program code is embodied. The computer-readable program code is configured to implement a method comprising the step of receiving a key generation request from a client workload by the hardware security module. The hardware security module receives an authentication document for the key generation request signed by a first authentication service using a first cryptographic authentication signing key. The hardware security module verifies the key generation request and the authentication document using one or more predefined sets of requirements of a workload assignment policy. When the verification of the key generation request and the authentication document for the key generation request is successful, the hardware security module determines one or more sets of workload requirements for the client workload. The hardware security module generates a first encryption key for the client workload to be used by the hardware security module to provide cryptographic operations for the client workload, and encodes one or more workload requirements as one or more attributes of the first encryption key generated by the client workload to assign the availability of the generated first encryption key to the cryptographic operation request by the client workload. The hardware security module returns the first encryption key generated by the client workload to the client workload, which has one or more attributes of the first encryption key it generated. The first encryption key generated by the client workload, which has one or more attributes of the first encryption key it generated, is cryptographically protected using the hardware security module key.

[0006] In another embodiment, the present invention relates to a stateless hardware security module for enabling security of cryptographic operations performed by a hardware security module for a client workload. The hardware security module is configured to receive key generation requests from a client workload. The hardware security module is further configured to receive authentication documents for key generation requests signed by a first authentication service using a first cryptographic authentication signing key. The hardware security module is further configured to validate the key generation requests and authentication documents using one or more predefined sets of requirements for a workload assignment policy. The hardware security module is further configured to determine one or more sets of workload requirements for a client workload when the validation of the key generation requests and authentication documents for key generation requests is successful. The hardware security module is further configured to generate a first encryption key for the client workload to be used by the hardware security module to provide cryptographic operations for the client workload, and to encode one or more workload requirements as one or more attributes of the first encryption key generated by the client workload to assign the availability of the generated first encryption key to cryptographic operation requests by the client workload. The hardware security module is further configured to return the first encryption key generated by the client workload to the client workload, which has one or more attributes of the first encryption key it generated. The first encryption key generated by the client workload, which has one or more attributes of the first encryption key it generated, is cryptographically protected using the hardware security module key. [Brief explanation of the drawing]

[0007] Embodiments of the present invention will be described in more detail below with reference to the following drawings, which are merely illustrative examples.

[0008] [Figure 1]This is a block diagram of a system including a stateless hardware security module, which is an example related to this subject.

[0009] [Figure 2] This is a flowchart of a method related to one example of this subject.

[0010] [Figure 3] This is a flowchart of a method related to one example of this subject.

[0011] [Figure 4] This is a flowchart of a method related to one example of this subject.

[0012] [Figure 5] This is a flowchart of a method related to one example of this subject.

[0013] [Figure 6] This is a flowchart of a method related to one example of this subject.

[0014] [Figure 7] This is a block diagram of a system including a stateless hardware security module, which is an example related to this subject.

[0015] [Figure 8] This is a computing environment related to one example of this subject.

[0016] [Figure 9] This document illustrates a cloud computing environment according to one embodiment of the present invention.

[0017] [Figure 10] An abstraction model layer relating to one embodiment of the present invention is shown. [Modes for carrying out the invention]

[0018] The descriptions of various embodiments of the present invention are presented for illustrative purposes and are not intended to be exhaustive or to limit 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 terms used herein are chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvements over the technologies found in the marketplace, or to enable other skilled artisans to understand the embodiments disclosed herein.

[0019] The hardware security module (HSM) considered herein is a stateless HSM, and in particular, a remote stateless HSM. The methods described herein enable the implementation of attention-based workload scoping of encryption keys in such stateless HSMs. Attention-based workload scoping of encryption keys in stateless HSMs may be able to further protect highly confidential encryption keys as compared to known approaches. Therefore, it can be achieved that the encryption keys used by the stateless HSM are protected at a higher level against attacks based on malicious client workloads and the like.

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

[0021] Encryption keys generated by an HSM for client workloads may be provided by the HSM in the form of a cryptographically protected dataset, also known as a key blob, along with the attributes assigned to the encryption keys generated by the HSM. Such a dataset, i.e., a key blob, can be encrypted by the HSM with an HSM key, and only the HSM can decrypt and use the generated encryption key with the attributes of the encryption key composed of each dataset. Because the HSM is a stateless HSM, a key blob containing an encryption key with the attributes of the encryption key generated for a client workload can be sent by the HSM to the client workload for storage. If an encryption key is required for an encryption operation performed by the HSM for a client workload, the client workload may, for example, send an encrypted key blob to the HSM. The HSM can, for example, decrypt the encrypted key blob and use the attributes to verify whether the encryption key composed of the key blob is indeed assigned to the client workload requesting the encryption operation. In other words, it verifies whether the client workload is authorized to use the key blob, i.e., the encryption key composed of the key blob. If the confirmation is positive, the HSM may perform the requested encryption operation using the encryption key, which consists of the key blob provided by the client workload requesting the encryption operation.

[0022] The usability of an encryption key generated using attributes including workload requirements for a client workload can be assigned to an encryption operation request by the client workload. This workload scoping of the encryption key by attributes can scope the encryption key to individual client workloads. In other words, the encryption key can be generated for an individual client workload and its usability can be restricted to this individual client workload via attributes. Therefore, only the client workload to which the encryption key is scoped can be enabled to properly request the use of this encryption key by the HSM. If another client workload, for example, a malicious client workload, comes to the location of an encrypted encryption key that is not scoped to this other client workload, the encryption key may not be usable, for example, for a request for an encryption operation by the HSM. Authentication, for example, authentication documents for other malicious client workloads, are generally in a different form from the authentication documents provided for the client workload to which the encryption key is scoped. Therefore, for example, the authentication documents provided for other malicious client workloads can reveal that they are not the same client workload as the client workload to which the encryption key is scoped.

[0023] The authentication mechanism can be used to prevent tampering with the scoping mechanism. For example, a tampered client workload may not be able to use an encryption key scoped to an untampered client workload. Authentication, for example, authentication documents provided for a tampered client workload, are generally different from the authentication documents provided for an untampered client workload, so it may reveal tampering of the client workload. Therefore, neither the tampered version of the original client workload nor another malicious client workload may be able to use the encryption key generated for the original untampered client workload.

[0024] Potential attack vectors against which attention-based workload scoping of encryption keys in a stateless HSM may offer protection include malicious actors, such as a malicious administrator, who steals key blobs generated by the HSM for individual client workloads from external storage and inserts the stolen key blobs into a malicious client workload. A malicious client workload may be created by a malicious actor, for example, to sign a malicious transaction. The malicious client workload may use the stolen key blob to request an encryption operation from the HSM, attempting to authorize a malicious transaction using the encryption key configured in the stolen key blob. The authentication document provided for a malicious client workload is different from the authentication document provided for a client workload. The encryption key configured in the stolen key blob is generated for that purpose, and the workload requirements are encoded in attributes that limit the usability of the encryption key. Therefore, the authentication document provided for a malicious client workload does not satisfy the workload requirements encoded in the attributes configured in the key blob, and the HSM refuses to perform the requested encryption operation, such as authorizing a malicious transaction.

[0025] Another potential attack vector against which attention-based workload scoping of encryption keys in stateless HSMs may offer protection is a tampered client workload. For example, a malicious actor, such as a malicious administrator, may tamper with a client workload, including the key blob generated for that client workload, by, for example, injecting code into the client workload and / or modifying the code of the client workload, in order to sign a malicious transaction using the key blob of an untampered client workload. When executed, the tampered code of the client workload may attempt to use the key blob to request an encryption operation from the HSM, such as authorizing a malicious transaction using the encryption key configured in the key blob. Examining the authentication document provided for the tampered client workload will differ from the authentication document provided for the untampered client workload due to the differences in the code resulting from the tampering. Therefore, the authentication document provided for the tampered client workload will not satisfy the workload requirements encoded in the attributes configured in the key blob generated for the untampered client workload, and the HSM will refuse to perform the requested encryption operation, such as authorizing a malicious transaction.

[0026] By verifying the authentication documents provided for client workloads using the workload assignment policy, the HSM recognizes and rejects client workloads that are enabled and / or deployed to vulnerable execution environments. Furthermore, by verifying the authentication documents provided for client workloads that request the use of encryption keys composed of key blobs, using the attributes assigned to encryption keys and provided by the key blobs, the HSM recognizes and / or rejects malicious and / or tampered client workloads that are enabled and / or deployed to malicious and / or tampered execution environments.

[0027] Furthermore, it is possible to enable controlled handover of encryption keys, for example, between different versions of client workloads. Therefore, updates to client workloads can be enabled.

[0028] Attention-based workload scoping of encryption keys in stateless HSMs can enable one or more of the following beneficial effects: an additional layer of protection can be provided for encryption keys by assigning attributes to encryption keys that encode workload requirements for individual client workloads, scoping the availability of each encryption key; authorization using encryption keys can be proven using authentication documents generated for individual client workloads and can be proven using attributes assigned to encryption keys; encryption keys and stateless HSMs can be protected against the aforementioned potential attack vectors; typical DevOps, such as client workload updates, are not hindered. DevOps refers to a set of practices aimed at reducing the time between committing changes to a system and bringing those changes into normal production, while simultaneously enabling high quality. DevOps is characterized by one or more key principles of 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 software development (Dev) and IT operations (Ops) work as a means of improving and shortening the system development lifecycle. DevOps complements agile software development, and some aspects of DevOps stem from agile work methods.

[0029] Attention-based workload scoping of encryption keys in stateless HSMs can further enable a new type of encryption key licensing per client workload for HSM and cloud encryption services. Furthermore, attention-based workload scoping of encryption keys in stateless HSMs can be combined with the provision of secure builds, for example, by a security build server, such as confidential computing. Ultimately, a new type of encryption key licensing and pricing can be implemented. For example, encryption keys could be priced per encryption key usage and / or per client workload.

[0030] The first local authentication service could be, for example, a local authentication service. Such a local authentication service might be implemented, for example, as a component of the execution environment, within which the client workload runs. The first local authentication service might use a first cryptographic authentication signing key to sign authentication documents. The first cryptographic authentication signing key might be trusted by the HSM. The HSM might be provided with, for example, a first cryptographic authentication signature verification key. For example, the first cryptographic authentication signing key is the cryptographic secret key of a first asymmetric encryption key pair. The first asymmetric encryption key pair may further include a cryptographic public key provided to the HSM as the first cryptographic authentication signature verification key. For example, the first cryptographic authentication signature verification key is provided to the HSM as part of the digital certificate of the first authentication service.

[0031] A hardware security module key could be, for example, the domain master key of an HSM. For example, an HSM key could be a symmetric or asymmetric encryption key. To cryptographically protect data such as keys generated by the HSM and / or attributes about such keys, the HSM may use the hardware security module key to encrypt data. The HSM key used for encryption could be, for example, the public encryption key of an HSM asymmetric encryption key pair. An HSM asymmetric encryption key pair may further include a private encryption key of the HSM, which must be used to decrypt data encrypted using the HSM's public encryption key. Using an HSM key to encrypt data, such as the HSM's symmetric encryption key or public encryption key, may enable only the HSM to decrypt the encrypted data. Access to the HSM's symmetric encryption key or public encryption key may be restricted to the HSM.

[0032] Stateless HSMs can be implemented, for example, as EP11-based CEX cards, or as cloud HSMs such as a CEX HSM-based cloud HSM that supports the Hyper Protect Crypto Service (HPCS), i.e., the PKCS#11 API.

[0033] Enabling PKCS#11 (EP11), as in the case of Linux on Z Enterprise, allows applications to use the PKCS #11 API to perform secure key encryption operations on an IBM® Crypto Express adapter configured as a Crypto Express EP11 coprocessor. Here, the Crypto Express EP11 coprocessor is abbreviated as CEX*P, meaning all types of Crypto Express EP11 coprocessors. An IBM® Crypto Express adapter configured with Enterprise PKCS #11 (EP11) firmware is called a Crypto Express EP11 coprocessor. The CEX4S adapter card is the first Crypto Express adapter configured as an EP11 coprocessor. For example, a CEX5P, CEX6P, CEX7P, or CEX8P on a suitable IBM Z® system can be used as an EP11 coprocessor.

[0034] An application request can first be submitted to a PKCS #11 API and EP11 token, for example, implemented by the openCryptoki library. From this token, the request can be propagated to the Crypto Express EP11 coprocessor. Next, the request can be processed by this coprocessor. The resulting output can finally be returned to the application via the involved interfaces. The EP11 cryptographic architecture can provide a secure key infrastructure.

[0035] PKCS#11 refers to the Public Key Cryptography Standard (PKCS), a group of cryptographic standards that provide guidelines and application programming interfaces (APIs) for the use of cryptographic methods. As the name PKCS suggests, these standards focus on 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, for example, is generated on the HSM and returned to the client workload as a protected so-called key blob, such as an HSM domain master key, and can be passed back by the client workload during subsequent requests to the HSM for use by the HSM on behalf of the client workload. The client workload manages and stores key blobs that provide cryptographically protected cryptographic material generated by the HSM for the client workload. Key material protected by an HSM key, such as an HSM domain master key, can only be used for this particular HSM, such as the HSM domain to which the HSM key, such as an HSM domain master key, is assigned. The HSM can use additional access control mechanisms such as TLS (Transport Layer Security) or IAM (Identify and Access Management), for example, in the case of HPCS Cloud HSMs.

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

[0038] In response to a request from a client workload, the first authentication service may, for example, create an authentication document for the client workload. The first authentication service may verify certain characteristics relating to the client workload and authenticate the verification result by signing the authentication document generated for the client workload using a first cryptographic authentication signing key. The HSM may, for example, use the first cryptographic authentication signature verification key to verify the signature relating to the client workload provided by the authentication document, and thus the authenticated characteristics.

[0039] Figure 1 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 be enabled to use the cryptographic services and / or cryptographic operations in a protected manner, a client workload 110 may request an encryption key format from the stateless HSM 100. The HSM 100 may verify an authentication document provided by an authentication service 120 for the client workload 110. This allows the HSM 100 to determine whether the client workload 110 has the right to request an encryption key. The authentication document may be provided to the HSM 100 via the client workload 110, or alternatively, directly. If the client workload 110 has the right to request an encryption key, the HSM 100 may generate the requested encryption key and assign attributes to the generated encryption key that define the workload requirements to be met by the client workload requesting the use of the encryption key by the HSM 100 on behalf of the client workload 110. The authentication document can be verified using the workload assignment policy provided by HSM100. Attributes may be determined, for example, using the authentication document for client workload 110. For example, the characteristics authenticated with respect to client workload 110 by the authentication document for client workload 110 may include attributes. The generated requested encryption key and assigned attributes can be returned to client workload 110 by HSM100 in a cryptographically protected form. The key blob can be encrypted by HSM100, for example, using the HSM key, thereby enabling only HSM100 to decrypt and use the encryption key provided by the key blob for client workload 110. Client workload 110 can receive and store the key blob.

[0040] If a client workload 110 requests that an encryption operation be performed using an encryption key configured in a key blob, the client workload 110 may send an encryption operation request to the HSM 100 along with the key blob. Furthermore, an authentication document for the client workload 110 may be provided by the authentication service 120. The HSM 100 may, for example, decrypt the key blob and use the authentication document and the attributes assigned to the encryption key to verify that the client workload 110 is authorized to request the use of the encryption key by the HSM 100. If the client workload 110 is authorized, the HSM 100 may perform the requested encryption operation for the client workload 110 using the encryption key for the client workload 110 provided by the key blob. After the encryption operation is performed, the HSM 100 may delete the key blob.

[0041] Therefore, the HSM 100 may be configured to generate an encryption key for a client workload 110 in response to a request, and to use the encryption key for the client workload 110 to provide encryption operations to the client workload 110. Furthermore, the HSM 100 may be configured to provide an updated encryption key, i.e., a second encryption key for the updated client workload 130. The second encryption key for the updated client workload may be provided in response to a request from a third party acting on behalf of the client workload, such as the client workload 110, the updated client workload 130, or the security build server 150. The updated client workload 130 may run in the same execution environment, for example. The authentication service 140 that provides authentication documents for the updated client workload 130 may be identical to, or different from, the authentication service 120 that provides authentication documents for the client workload 110.

[0042] The security build server 150 may be configured, for example, to build and provide an updated client workload 130. For example, the security build server 150 may be configured to request a second encryption key for the updated client workload 130. The authorization of the security build server 150 to request a second encryption key for the updated client workload 130 may be proven using an authentication document provided by the authentication service 160 for the security build server 150. The resulting updated key blob, including the second encryption key for the updated client workload 130, may be transferred to the updated client workload 130, for example, by requesting the security build server 150 for use.

[0043] Figure 2 is a flowchart illustrating an exemplary method for enabling security for cryptographic operations performed by a stateless HSM for a client workload. In block 200, the HSM receives a key generation request from the client workload. In block 202, the HSM receives an authentication document for the key generation request, signed by a first authentication service using a first cryptographic authentication signing key. The authentication document may be received, for example, from the client workload or directly from the authentication service. In block 204, the HSM verifies the key generation request and the authentication document using one or more predefined sets of requirements of a workload assignment policy. Verification may include verifying the integrity and validity of the authentication document. Verification may be successful if the authentication document satisfies the requirements defined by the workload assignment policy for the key generation request.

[0044] Workload allocation policies may be defined, for example, by an administrator. Workload allocation policies may include, for example, requirements regarding trusted cryptographic authentication signing keys. For example, a workload allocation policy may include a set of trusted certificates with cryptographic authentication signature verification keys used to verify signatures generated using the cryptographic authentication signing key. Furthermore, a workload allocation policy may include, for example, a checksum such as a hash of several features relating to client workloads authorized to use the HSM.

[0045] The workload allocation policy may include, for example, an allowlist of authenticated signing keys trusted by the HSM, or an allowlist of content requirements provided by certificates and authentication documents for authenticated signing keys trusted by the HSM.

[0046] In block 206, upon successful verification of the key generation request and the authentication document for the key generation request, the HSM determines one or more sets of workload requirements for the client workload. The determination steps may include, for example, extracting the features authenticated by the authentication document for the client workload and using these features as workload requirements.

[0047] If verification fails, the key generation request may be rejected by the HSM, for example. For example, the HSM may temporarily reject the key generation request and the authentication document will not be provided if the authentication document is not verified or if the workload assignment policy requires further requirements. Such further requirements may be, for example, a nonce protection format for the authentication document if required by the workload assignment policy. Alternatively, the HSM may call a remote authentication API associated with the client workload, for example, provided by the execution environment in which the client workload runs. Through the remote authentication API, a first authentication service trusted by the HSM may be contacted by the HSM, for example, to obtain authentication for further requirements that directly constitute the first authentication service. If the HSM temporarily rejects the request, the first authentication service may regenerate an authentication document for the client workload, for example, when requested by the client workload. The regenerated authentication document for the client workload may include, for example, further requested information. This regenerated authentication document may be used by the client workload to reissue the key generation request. For example, an HSM may receive a key generation request that has been reissued using a recreated authentication document.

[0048] The attributes of the first encryption key define the workload requirements that are met by the client workload's authentication document in order to enable the client workload to use the first encryption key. The attributes define which client workloads are authorized to use the first encryption key they generated. In the case of a request for use of the first encryption key by the HSM on behalf of the client workload, the request from the client workload can be identified and verified as an authorized client workload using the authentication document for the client workload. It is verified against the workload requirements defined by the attributes.

[0049] To determine one or more workload requirements for a client workload, the HSM may use, for example, authentication documents and / or workload assignment policies. For example, a workload assignment policy may define that the characteristics authenticated with respect to the client workload by the client workload's authentication document are to be used as workload requirements for the client workload. Thus, the cryptographic key generated by the HSM for a client may be enabled to be used only by the client workload that requested the generation of the cryptographic key. For example, the authentication document of the client workload that issued the key generation request may be included in the workload requirements. Furthermore, a certificate containing the ID of a first cryptographic authentication signing key, the first cryptographic authentication signing key, and / or a cryptographic authentication signature verification key may be used to verify the signature generated using the cryptographic authentication signing key.

[0050] In block 208, the HSM generates a first encryption key for the client workload to be used by the HSM to provide cryptographic operations for the client workload, and encodes one or more workload requirements as one or more attributes of the first encryption key generated by the client workload to assign the availability of the generated first encryption key to the cryptographic operation requests by the client workload.

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

[0052] In one example, a first encryption key generated for a client workload having one or more attributes of the generated first encryption key is cryptographically protected by encryption using an HSM key. This allows only the HSM to be enabled to use the first encryption key with the HSM key after decryption of the encryption.

[0053] In one example, one or more workload requirements for a client workload are determined using one or more of the following: an authentication document for a key generation request, a workload allocation policy. For example, a workload allocation policy may be defined to use an authentication document to determine workload requirements. Furthermore, the workload allocation policy may provide additional workload requirements in addition to those provided by the authentication document for a key generation request.

[0054] In one example, the authentication document for a key generation request is received from the client workload along with the key generation request. In another example, the authentication document for a key generation request is received from the first authentication service in addition to the key generation request.

[0055] In one example, an authentication document for a key generation request is generated using a nonce. Using a nonce can enable the HSM to ensure, for example, that an authentication document for a key generation request is used only once to request the generation of another encryption key, and then not again. To ensure the success of the request for the generation of another encryption key, a different authentication document containing a different nonce is always generated. For example, the nonce incorporated into the authentication document may be defined and provided by the HSM.

[0056] In one example, the authentication document for the key generation request includes: the machine type ID of the machine, on which the client workload runs; a checksum of the base image of the execution environment for the client workload; a checksum of the root partition at the time of the first boot of the execution environment for the client workload, the root partition used for the first boot; a checksum of the root partition at the time of building the execution environment for the client workload, the root partition used to build the execution environment; a checksum of the client workload container image containing the client workload; the geographical location of the machine, on which the client workload runs; the ID of a cryptographic authentication signature verification key for verifying the signature generated using the first cryptographic authentication signature key; and one or more certificates for verifying the signature generated using the first cryptographic authentication signature key.

[0057] In one example, the workload assignment policy includes: the ID of the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; a certificate for verifying the generated signature using the first cryptographic authentication signing key; the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of the first boot of the execution environment of the client workload, where the root partition is used for the first boot; the checksum of the root partition at the time of the build of the execution environment of the client workload, where the root partition is used for the build of the execution environment; the client workload container image containing the client workload; the geographic location of the machine on which the client workload runs; one or more predefined constraints using the first encryption key generated for the client workload; and one or more rules for updating the first encryption key generated for the client workload.

[0058] In one example, the authentication requirements defined by the workload assignment policy are defined based on one or more of the following: the client, the tenant, the key type of the first encryption key, the client workload, and the geographical location of the machine on which the client workload is executed. The tenant refers to the party that interacts with the client. The client may submit requests on behalf of the tenant, such as including the tenant ID.

[0059] In one example, a workload assignment policy includes one or more selection rules for choosing which authentication requirements to satisfy, based on one or more of the following: client type, tenant type, key type of the first encryption key, client workload type, and geographical location of the machine on which the client workload runs.

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

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

[0062] In one example, the one or more attributes of the first encryption key generated for the client workload are: The ID of the cryptographic authentication signature verification key for verifying the signature generated using the first cryptographic authentication signature key; the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signature key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of the first boot of the execution environment of the client workload, where the root partition is used for the first boot; the checksum of the root partition at the time of the build of the execution environment of the client workload, where the root partition is used for the build of the execution environment; the client workload container image containing the client workload; the geographic location of the machine on which the client workload runs; and one or more IDs of the first cryptographic key generated for the client workload.

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

[0064] Figure 3 is a flowchart illustrating an exemplary method of using a first encryption key for cryptographic operations performed by an HSM for a client workload. In block 300, the HSM receives an encryption operation request from the client workload. The encryption operation request is received along with the first encryption key of the client workload and one or more attributes of the first encryption key that are cryptographically protected using the HSM key. The requested encryption operation may include, for example, encryption, decryption, and / or signing using the first encryption key of the client workload.

[0065] In block 302, the HSM receives an authentication document for a cryptographic operation request signed by a first authentication service, using a first cryptographic authentication signing key. A client workload may request an encryption operation to be performed by the HSM, for example, by passing the HSM the first encryption key and, as part of the encryption operation request, a key blob containing attributes assigned to the first encryption key along with the authentication document. If the client workload does not provide an authentication document along with the encryption operation request or an insufficient authentication document, the HSM may, for example, temporarily reject the encryption operation request and request an authentication document from the client workload. The requested authentication document may, for example, be requested to include a nonce. Alternatively, the HSM may, for example, invoke a remote authentication protocol to receive an appropriate authentication document from the client workload requesting the encryption operation.

[0066] In block 304, the HSM uses one or more attributes of the first encryption key of the client workload to validate the encryption operation request and the authentication document for the encryption operation request. The encryption operation request and the authentication document may be validated if the authentication document received for the encryption operation request satisfies the workload requirements defined by the attributes of the first encryption key.

[0067] In block 306, the HSM performs the encryption operation requested by the encryption operation request using the client workload's first encryption key, upon successful verification of the encryption operation request and the authentication document for the encryption operation request. After the requested encryption operation is performed, the received first encryption key and attributes of the client workload may be deleted on the stateless HSM. If verification fails, the encryption operation request may be rejected by the HSM, for example. For example, the encryption operation request may be rejected using an error code. If the encryption operation request is temporarily rejected, the client workload may repeat the encryption operation request, for example, by retrieving further authentication records from the local first authentication service and providing them to the HSM.

[0068] In one example, a first encryption key received by a client workload having one or more attributes of a first encryption key that is cryptographically protected by being encrypted using an HSM key is decrypted by the HSM for use by the HSM. This allows only the HSM to be enabled to use the first encryption key with the HSM key after decryption of the encryption.

[0069] In one example, the authentication document for the encryption operation request is received from the client workload along with the encryption operation request. In another example, the authentication document for the encryption operation request is received from a first authentication service in addition to the encryption operation request.

[0070] In one example, an authentication document for a cryptographic operation request is generated using a nonce. Using a nonce allows, for example, the HSM to ensure that the authentication document for a cryptographic operation request is used only once to request the execution of another cryptographic operation, and not again thereafter. This is necessary to successfully request the execution of another cryptographic operation, which requires the generation of another authentication document containing a different nonce. For example, the nonce incorporated into the authentication document may be defined and provided by the HSM.

[0071] Figure 4 is a flowchart illustrating an exemplary method for preparing a client workload update. In block 400, the HSM receives an update readiness request from the client workload. The update readiness request is received along with the client workload's first encryption key and one or more attributes of the first encryption key, which are cryptographically protected using the HSM key. In block 402, the HSM receives an authentication document for the update readiness request, which is signed by a first authentication service using the first cryptographic authentication signing key. In block 404, the HSM receives an updated authentication document. The updated authentication document may, for example, contain values ​​for workload requirements satisfied by the updated client workload.

[0072] In block 406, the HSM verifies the update readiness request and the authentication document for the update readiness request using one or more attributes of the client workload's primary encryption key. In block 408, the HSM uses the updated authentication document to determine one or more updated workload requirements for the updated client workload. For example, the workload requirement values ​​to be satisfied by the updated client workload, as defined by the updated authentication document, may be used for the updated client workload.

[0073] In block 410, upon successful verification of the update preparation request and the authentication document for the update preparation request, the HSM generates a second encryption key for the updated client workload and encodes one or more updated workload requirements as one or more attributes of the second encryption key generated by the updated client workload in order to assign the availability of the generated second encryption key to the encryption operation request. If verification fails, the update readiness request may be rejected by the HSM, for example.

[0074] The attributes of the second encryption key define the updated workload requirements, namely the workload requirements that are met by the updated client workload authentication document to enable the updated client workload to use the second encryption key.

[0075] In block 412, the HSM returns the second encryption key generated by the updated client workload, which has one or more attributes of the generated second encryption key, to the client workload that is passed to the updated client workload. The second encryption key generated by the client workload, which has one or more updated attributes of the generated second encryption key, is cryptographically protected using the HSM key.

[0076] Alternatively, in block 410, upon successful verification of the update readiness request and the authentication document for the update readiness request, the HSM may complement one or more attributes of the first encryption key of the client workload with one or more additional attributes encoding one or more updated workload requirements. The availability of the first encryption key can then be assigned by the updated client workload to further encryption operation requests. This enables the client workload and the updated client workload to use the first encryption key. In this case, in block 412, the HSM returns the first encryption key, with one or more attributes of the first encryption key and one or more updated attributes of the first encryption key, to the client workload passed to the updated client workload. The first encryption key of the client workload with one or more attributes and one or more updated attributes is cryptographically protected using the HSM key.

[0077] In one example, a first encryption key received by a client workload having one or more attributes of a first encryption key that is cryptographically protected by being encrypted using an HSM key is decrypted by the HSM for use by the HSM. This allows only the HSM to be enabled to use the first encryption key with the HSM key after decryption of the encryption.

[0078] In one example, the updated authentication document is an authentication document for an implemented and updated client workload, signed by a second authentication service using a second cryptographic authentication signing key. The second authentication service may be identified, for example, by the first authentication service. Alternatively, the second authentication service may be different from, for example, the first authentication service.

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

[0080] In one example, the updated authentication document is a prediction of the authentication document for the updated client workload prediction. In one example, the updated authentication document request is generated using a nonce.

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

[0082] In one example, an authentication document for an update readiness request is generated using a nonce. Using a nonce allows, for example, the HSM to enable the authentication document for an update readiness request to be used only once, and not again, to request another update readiness. To successfully request another update readiness, a different authentication document containing a different nonce must be generated. For example, the nonce incorporated into the authentication document may be defined and provided by the HSM.

[0083] In one example, an update readiness request from a client workload includes a shared secret. The shared secret is a secret passed to the updated client workload by the client workload. The shared secret is encoded by the HSM as an attribute of one or more attributes of a second encryption key generated by the updated client workload.

[0084] In one example, the second encryption key generated by an updated client workload, which has one or more attributes of the generated second encryption key, is cryptographically protected using an HSM key, independently of the first encryption key of the client workload, which has one or more attributes of the first encryption key of the client workload.

[0085] In one example, the second encryption key generated by an updated client workload, which has one or more attributes of the generated second encryption key, is cryptographically protected in combination with the first encryption key of the client workload, which has one or more attributes of the first encryption key of the client workload. The combination is configured to be used by both the client workload and the updated client workload.

[0086] Figure 5 is a flowchart illustrating an exemplary method for requesting updated encryption keys 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 along with a combination of the client workload's first encryption key, which has one or more attributes of the client workload's first encryption key, and the updated client workload's second encryption key, which has one or more attributes of the updated client workload's second encryption key. The combination is cryptographically protected using the HSM key. Thus, in the case of client workload update and key transfer use, for example, the first encryption key is scoping to the client workload, and the second encryption key is generated during a previous iteration of this method and scoping to the updated client workload.

[0087] In block 502, the HSM receives an authentication document for a key update request, which is signed by a second authentication service using a second cryptographic authentication signing key. In block 504, the HSM verifies the authentication documents for the key update request and the key update preparation request using one or more attributes of the second cryptographic key of the updated client workload. In block 506, if the verification of the key update request and the authentication document for the key update request is successful, the HSM generates a third cryptographic key for the updated client workload and encodes one or more attributes of the second cryptographic key as one or more attributes of the third cryptographic key generated by the updated client workload to assign the availability of the generated third cryptographic key to cryptographic operation requests. If verification fails, the key update request may be rejected by the HSM, for example.

[0088] In block 508, the HSM returns the generated third encryption key of the updated client workload, which has one or more attributes of the generated third encryption key, to the updated client workload as a substitute for the first encryption key of the client workload, which has one or more attributes of the first encryption key of the client workload, and the second encryption key of the updated client workload, which has one or more attributes of the second encryption key of the updated client workload. The generated third encryption key of the client workload, which has one or more attributes of the third encryption key, is cryptographically protected using the HSM key.

[0089] In one example, the received combination of the first encryption key of the client workload, having one or more attributes of the first encryption key of the client workload, and the second encryption key of the updated client workload, having one or more attributes of the second encryption key of the updated client workload, which is cryptographically protected by encryption using the HSM key, is decrypted by the HSM. Thus, only the HSM can be enabled to use the encryption key after decryption of the encryption with the HSM key.

[0090] In one example, a third encryption key generated for an updated client workload having one or more attributes of the generated third encryption key is cryptographically protected by encryption using the HSM key. This allows only the HSM to be enabled to use the third encryption key after decryption of the encryption using the HSM key.

[0091] In one example, the authentication document for a key update request is received from the client workload along with the key update request. In another example, the authentication document for a key update request is received from the first authentication service in addition to the key update request.

[0092] In one example, an authentication document for a key update request is generated using a nonce. Using a nonce allows, for example, the HSM to ensure that the authentication document for a key update request is used only once, and not again, to request the generation of another updated encryption key. To successfully request the generation of another updated encryption key, a different authentication document containing a different nonce is always generated. For example, the nonce incorporated into the authentication document may be defined and provided by the HSM.

[0093] Figure 6 is a flowchart illustrating an exemplary method for requesting an encryption key for a client workload updated by a security build server. In block 600, the HSM receives an update enablement request from the security build server. In block 602, the HSM receives an authentication document for the enablement request signed by a third authentication service using a third encryption authentication signing key. In block 604, the HSM receives the updated authentication document. In block 606, the HSM verifies the update enablement request and the authentication document for the update enablement request using one or more predefined sets of requirements from the workload assignment policy.

[0094] In block 608, the HSM determines one or more updated workload requirements for the updated client workload using the updated authentication document. In block 610, if the validation of the update enable request and the authentication document for the update enable request is successful, the HSM generates a second encryption key for the updated client workload and encodes one or more updated workload requirements as one or more attributes of the second encryption key generated by the updated client workload in order to assign the usability of the generated second encryption key to encryption operation requests by the updated client workload. If validation fails, the update enable request may be rejected by the HSM, for example.

[0095] In block 612, the HSM returns the second encryption key generated by the updated client workload, which has one or more attributes of the generated second encryption key, to the security build server that passes it to the updated client workload. The second encryption key generated by the client workload, which has one or more updated attributes of the generated second encryption key, is cryptographically protected using the HSM key.

[0096] Figure 7 is a block diagram of an exemplary system 101, which includes a remote stateless HSM 100 that provides stateless remote cryptographic services to a client workload 110. The client workload 110 can communicate with the remote stateless HSM 100 via a network 714. Furthermore, the client workload 110, provided by the client 700 and executed by a trusted execution entity 703 that provides an execution environment for the client workload 110, may be identifiable, for example, by hash 706 "SHA A". The trusted execution entity 703 may be controlled, for example, by a system administrator 702. In step 1, a local authentication service 140, which consists of, for example, the trusted execution entity 703, may verify the client workload 110 and generate an authentication document for the client workload 110 in step 2. The authentication document may include, for example, the following: [Table 1]

[0097] In step 3, the client workload 110 may request an encryption key from, for example, HSM 100. In step 4, the HSM may use component 720 to confirm and verify the request. Furthermore, HSM 100 may use workload assignment policy 726 for confirmation. If an authentication document has not yet been provided to HSM 100, HSM 100 may send an authentication in step 5 and receive an authentication document in response to an authentication query in step 6. In step 7, the received authentication document may be verified by HSM 100 using component 720 and workload assignment policy 726 as well. The workload assignment policy 726 is, for example, [Table 2] You can define workload requirements that are met by the authentication documents for client workload 110, such as the following.

[0098] For verification, component 720 may use, for example, the authentication information provided by the authentication information cache 722. The management service component 724, [Table 3] This allows for the management of stateless remote cryptographic services provided by the HSM100 and the definition of the HSM100's characteristics.

[0099] The remote HSM access API may be used in step 8, along with the HSM attributes provided by component 718, to generate the requested encryption key for the client workload 110 assigned by the attribute, using one or more of the cryptographic hardware components 728, 730. The HSM attributes are, for example, [Table 4] It may include.

[0100] In step 9, the encrypted key blob contains the generated encryption key and the attributes assigned to the generated encryption key. This key blob can be used by the client workload 110 to request an encryption operation to be performed by the HSM 100 when requested by the client workload 110. An example key blob encrypted by the HSM 100 is, for example, [Table 5] It may include.

[0101] Furthermore, client workload 110 may be updated, resulting in an updated client workload 130. The updated client workload 130 may be executed, for example, by a trusted execution entity 703 and may also be identifiable by a hash 712 "SHA A*" that is different from the hash 712 "SHA A" of client workload 110. For the updated client workload 130, client workload 110 may request, for example, an updated cryptographic key with updated attributes. The resulting updated key blob may be provided to the updated client workload 130 via the encrypted persistent key store 706 of the trusted execution entity 703. This may enable the updated client workload 130 to use stateless remote cryptographic services also provided by the HSM 100. For example, client workload 110 and the updated client workload 130 may share common secrets 704, 710. The common secret 704 may be passed from client workload 110 to the updated client workload 130 via the encrypted persistent key store 706. The local authentication service 140 may also be configured to generate authentication documents for the updated client workload 130.

[0102] Using a workload authentication policy, an HSM may maintain a hierarchy of a tiered set of client workload requirements, including, for example, requirements for authentication records relating to the characteristics of the client workload. Requirements may include, for example, expected authentication record values, conditions for authentication signing keys, and / or pointers to pointers to other requirements and / or expected values ​​stored in the key blob of the cryptographically scoping key. Requirements may be stored, for example, in a workload authentication policy on the HSM side. Furthermore, requirements may be stored, for example, in the form of attributes in the key blob of the cryptographically scoping key that is stored when the cryptographically scoping key is returned to the client workload for which it was generated by the HSM.

[0103] Authentication services, for example, enable security services in or from the execution environment, and within that execution environment, client workloads whose features are authenticated by the authentication service are executed. For example, authentication services can be implemented and provided based on a Trusted Platform Module (TPM) or by an Ultravisor. An Ultravisor is trusted firmware that enforces memory protection using memory protection hardware. Authentication services can, for example, implement the spirit of a TPM, i.e., the measurement of client workloads is performed on trusted components, i.e., components trusted by the authentication service. An alternative TPM technology that can implement such an authentication service is an Ultravisor for security guests, e.g., the authentication functionality added to the security execution of z16.

[0104] A workload allocation policy may be established, for example, by the HSM administrator. For example, a workload allocation policy may be stored by the management server component. The management server, including the HSM and the management server component, may establish trust, for example. An exemplary workload allocation policy may be, for example, an implicit workload allocation policy. An implicit workload allocation policy may be, for example, a default workload allocation policy. The attributes configured in a key blob may be defined, for example, so as to precisely match the provable characteristics of the client workload for which the key blob was generated. Thereafter, the key blob for which the key blob was generated may only be used by the client workload.

[0105] An exemplary workload allocation policy could be, for example, an updatable workload allocation policy. An updatable workload allocation policy can enable updates, i.e., modifications to the attributes of a key blob. A client workload authorized to use a key blob may request an update to the workload scoping requirement, for example, by providing an updated client workload authentication record that allows the key blob to be used. The HSM can then update the key blob attributes. The resulting key blob can then be used by the original client workload and the updated client workload.

[0106] An exemplary workload assignment policy could be, for example, a protected updatable workload assignment policy. A protected updatable workload assignment policy could, for example, enable an additional step for authenticating an updated client workload. For example, the original client workload and the updated client workload might need to share a common secret or credentials. The original client workload requests that the common secret or credentials be added to the key blob. The common secret or credentials may be added to the key blob. The updated client workload might request the HSM to update the attributes in the key blob when it provides, for example, workload requirements, i.e., expected common secret or credentials and its current authentication document. The HSM can update the authentication document, for example, if the common secret or credentials provided by the updated client workload match a common secret or credentials previously added to the key blob. Alternatively or additionally, this could be combined with requirements regarding the authentication signing key used to sign the authentication documents of the original and updated client workloads, e.g., having the same authentication signing key, a common root certificate authority (CA), and / or intermediate CAs.

[0107] An exemplary workload allocation policy could be, for example, a security build workload allocation policy. A security build workload allocation policy could enable the security build server to be trusted to provide descriptions of different versions of client workloads, such as a description of versions where container sha1 may be compatible with container sha2, or a description of scoping compatibility between authentication documents. A security build workload allocation policy could define trusted client workloads, for example, including reference authentication documents and / or authentication signing keys for trusted workloads. In this way, for example, a hierarchy of trusted client workloads can be established.

[0108] The following provides an example of an authentication policy used to manage key usage and / or key renewal. For example, policies can be mixed and / or developed, parameters updated, redefined, and / or inserted depending on the system's needs.

[0109] An example of an implicit proof policy is, for instance, [Table 6] It may include.

[0110] An example of a security authentication policy is, for instance, [Table 7] It may include.

[0111] An example of an updatable authentication policy is, for instance, [Table 8] It may include.

[0112] An example of a protected, updatable authentication policy is, for instance, [Table 9] It may include.

[0113] An example of an implicit proof policy is, for instance, [Table 10] It may include.

[0114] An example of a security authentication policy is, for instance, [Table 11] It may include.

[0115] An example of an updatable authentication policy is, for instance, [Table 12] It may include.

[0116] An example of a protected, updatable authentication policy is, for instance, [Table 13] It may include.

[0117] As described herein, authentication-based workload scoping of encryption keys can enable encryption key scoping to identify, for example, client workloads. For example, only individual client workloads for which an encryption key was generated may be authorized to use this encryption key. For authenticated client workloads, workload scoping can be enforced and verified by the HSM based on authentication using authentication documents of the client workload requesting the encryption service and / or operation, provided by the HSM. Client workload scope and related information may be implemented using requirements determined by the HSM during key generation based on provided workload assignment policy and / or attention documents. These requirements are stored, for example, in a key blob. The key blob may be stored, for example, by the client workload independently of the HSM. Furthermore, novel mechanisms for controlled client workload scope updates may be implemented. A client workload may, for example, request the HSM to transfer or extend the workload scope defined by the key blob to the updated workload. For example, a trusted third party, such as a security build server, may request the transfer or extension of the workload scope on behalf of the client workload. Workload scope updates can be controlled, for example, using a shared secret passed between workloads.

[0118] The HSM may be able to control workload rights, for example, by using attention documents provided to client workloads to request the generation and / or use of cryptographic workload-scoped keys. Workload assignment policies may be used to define requirements and control mechanisms for the generation and / or updating of cryptographic workload-scoped keys.

[0119] This subject may include the following items.

[0120] [Item 1] A method for enabling security of cryptographic operations performed by a stateless hardware security module for a client workload, the method comprising: receiving a key generation request from the client workload by the hardware security module; receiving an authentication document for the key generation request signed by a first authentication service using a first cryptographic authentication signing key by the hardware security module; verifying the key generation request and the authentication document by the hardware security module using one or more predefined sets of requirements for a workload assignment policy; determining one or more sets of workload requirements for the client workload by the hardware security module when the verification of the key generation request and the authentication document for the key generation request is successful; and the client workload A method comprising the steps of: the hardware security module generates an encryption key for the client workload used by the hardware security module to provide an encryption operation to the client workload; and encoding the one or more workload requirements as one or more attributes of the generated encryption key for the client workload to assign the availability of the generated encryption key to an encryption operation request by the client workload; and the hardware security module returns the generated first encryption key for the client workload having the one or more attributes of the generated first encryption key to the client workload, and the generated first encryption key for the client workload having the one or more attributes of the generated first encryption key is cryptographically protected using a hardware security module key.

[0121] [Item 2] The method according to item 1, wherein the first encryption key generated for the client workload having the one or more attributes of the first encryption key generated is cryptographically protected by encryption using the hardware security module key.

[0122] [Item 3] The method described in any one of the preceding items, wherein the one or more workload requirements for the client workload are determined using one or more of the authentication documents for the key generation request and the workload assignment policy.

[0123] [Item 4] The method according to any one of the preceding items, wherein the authentication document for the key generation request includes the machine type ID of the machine, the client workload on which the client workload runs; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the time of 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 time of building the execution environment of the client workload, the root partition used to build the execution environment; a checksum of the client workload container image containing the client workload; the geographical location of the machine, the client workload on which the client workload runs; the ID of a cryptographic authentication signature verification key for verifying the signature generated using the first cryptographic authentication signature key; and one or more certificates for verifying the signature generated using the first cryptographic authentication signature key.

[0124] [Item 5] The method described in any one of the preceding items, wherein the workload assignment policy includes the ID of the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; a certificate for verifying the generated signature using the first cryptographic authentication signing key; the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of the first boot of the execution environment of the client workload, where the root partition is used for the first boot; the checksum of the root partition at the time of the build of the execution environment of the client workload, where the root partition is used for the build of the execution environment; the client workload container image containing the client workload; the geographic location of the machine on which the client workload runs; one or more predefined constraints using the first encryption key generated for the client workload; and one or more rules for updating the first encryption key generated for the client workload.

[0125] [Item 6] The method according to any one of the preceding items, wherein the one or more attributes of the first encryption key generated for the client workload include the ID of the encryption authentication signature verification key for verifying the signature generated using the first encryption authentication signing key; the encryption authentication signature verification key for verifying the signature generated using the first encryption authentication signing key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of the first boot of the execution environment of the client workload, where the root partition is used for the first boot; the checksum of the root partition at the time of the build of the execution environment of the client workload, where the root partition is used for the build of the execution environment; the client workload container image containing the client workload; the geographical location of the machine on which the client workload runs; and the ID of the first encryption key generated for the client workload.

[0126] [Item 7] The method according to any one of the preceding items, further comprising the steps of: receiving an encryption operation request from the client workload by the hardware security module, the encryption operation request being cryptographically protected using the hardware security module key and received together with the first encryption key of the client workload and one or more attributes of the first encryption key; receiving an authentication document for the encryption operation request signed by the first authentication service using the first cryptographic authentication signing key by the hardware security module; verifying the encryption operation request and the authentication document for the encryption operation request by the hardware security module using one or more attributes of the first encryption key of the client workload; and, when the verification of the encryption operation request and the authentication document for the encryption operation request is successful, performing the encryption operation requested by the encryption operation request using the first encryption key of the client workload.

[0127] [Item 8] The method described in item 7 above, wherein the received first encryption key of the client workload having one or more attributes of the first encryption key, which is cryptographically protected by encryption using the hardware security module key, is decrypted by the hardware security module for use by the hardware security module.

[0128] [Item 9] The method comprises the steps of: receiving an update readiness request from the client workload by the hardware security module, the update readiness request being received along with the first encryption key of the client workload and one or more attributes of the first encryption key, cryptographically protected using the hardware security module key; receiving an authentication document for the update readiness request signed by the first authentication service using the first cryptographic authentication signing key by the hardware security module; receiving an updated authentication document by the hardware security module; verifying the update readiness request and the authentication document for the update readiness request by the hardware security module using one or more attributes of the first encryption key of the client workload; and determining a set of one or more updated workload requirements for the updated client workload using the updated authentication document by the hardware security module. The method according to any one of the preceding items, further comprising: a step of generating a second encryption key for the updated client workload when the verification of the update preparation request and the authentication document for the update preparation request is successful, and encoding the one or more updated workload requirements of the generated second encryption key for the updated client workload as one or more attributes in order to assign the availability of the generated second encryption key by the updated client workload to an encryption operation request; and the hardware security module returning the generated second encryption key for the updated client workload, having the one or more attributes of the generated second encryption key, to the client workload that is passed to the updated client workload, and the generated second encryption key for the client workload, having the one or more updated attributes of the generated second encryption key, is cryptographically protected using the hardware security module key.

[0129] [Item 10] The method of item 9, wherein the received first encryption key of the client workload having one or more attributes of the first encryption key which is cryptographically protected by encryption using the hardware security module key is decrypted by the hardware security module for use by the hardware security module.

[0130] [Item 11] The method described in any one of the preceding items 9 to 10, wherein the updated authentication document is an authentication document for the implemented updated client workload, signed by the second authentication service using the second cryptographic authentication signing key.

[0131] [Item 12] The method according to any one of items 9 to 10 above, wherein the updated authentication document is a prediction of the authentication document for the updated client workload prediction.

[0132] [Item 13] The method according to any one of items 9 to 12 above, wherein the update preparation request from the client workload includes a shared secret, the shared secret is a secret passed by the client workload to the updated client workload, and the shared secret is encoded by the hardware security module as an attribute of one of the one or more attributes of the second encryption key generated by the updated client workload.

[0133] [Item 14] The method according to any one of items 9 to 13 above, wherein the generated second encryption key of the updated client workload having the one or more attributes of the generated second encryption key is cryptographically protected using independently the hardware security module key of the first encryption key of the client workload having the one or more attributes of the first encryption key of the client workload.

[0134] [Item 15] The method according to any one of items 9 to 13 above, wherein the generated second encryption key of the updated client workload having the one or more attributes of the generated second encryption key is cryptographically protected in combination with the first encryption key of the client workload having the one or more attributes of the first encryption key of the client workload, and the combination is configured to be used by the client workload and the updated client workload.

[0135] [Item 16] The method includes the following steps: the hardware security module receives a key update request from the updated client workload, the first encryption key of the client workload having one or more attributes of the first encryption key of the client workload, and the key update request is received along with a combination of the second encryption key of the updated client workload having one or more attributes of the second encryption key of the updated client workload, and the combination is cryptographically protected using the hardware security module key; and the hardware security module receives an authentication document for the key update request signed by the second authentication service using the second cryptographic authentication signing key. Steps include: receiving by the module; verifying the key update request and the authentication document for the key update preparation request using one or more attributes of the second encryption key of the updated client workload by the hardware security module; generating a third encryption key for the updated client workload and encoding one or more attributes of the second encryption key as one or more attributes of the generated third encryption key of the updated client workload in order to assign the availability of the generated third encryption key by the updated client workload to the encryption operation request;The method of item 15, further comprising the step of: and returning the generated third encryption key of the updated client workload having the one or more attributes of the generated third encryption key to the updated client workload by the hardware security module as a substitute for the combination of the first encryption key of the client workload having the one or more attributes of the first encryption key of the client workload and the second encryption key of the updated client workload having the one or more attributes of the second encryption key of the updated client workload; and the generated third encryption key of the client workload having the one or more attributes of the third encryption key being cryptographically protected using the hardware security module key.

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

[0137] [Item 18] The method includes the steps of: receiving an update activation request from a security build server via the hardware security module; receiving an authentication document for the activation request signed by a third authentication service using a third cryptographic authentication signing key via the hardware security module; receiving an updated authentication document via the hardware security module; verifying the update activation request and the authentication document for the update activation request via the hardware security module using the set of one or more predefined requirements of the workload allocation policy; determining a set of one or more updated workload requirements for the updated client workload using the updated authentication document via the hardware security module; and, upon successful verification of the update activation request and the authentication document for the update activation request, the updated The method according to any one of the preceding items, further comprising: a step of generating the second encryption key for a client workload, encoding the one or more updated workload requirements as one or more attributes of the generated second encryption key for the updated client workload in order to assign the availability of the generated second encryption key by the updated client workload to encryption operation requests; and a step of returning the generated second encryption key for the updated client workload, having the one or more attributes of the generated second encryption key, to the security build server which is passed to the updated client workload, by the hardware security module, and the generated second encryption key for the client workload, having the one or more updated attributes of the generated second encryption key, is cryptographically protected using the hardware security module key.

[0138] [Item 19] A computer program product for enabling security of cryptographic operations performed by a stateless hardware security module for a client workload, the computer program product comprising a computer-readable storage medium in which computer-readable program code is embodied, the computer-readable program code comprising: a step of receiving a key generation request from the client workload by the hardware security module; a step of receiving an authentication document for the key generation request signed by a first authentication service using a first cryptographic authentication signing key by the hardware security module; A computer program product configured to implement a method comprising the steps of: verifying the key generation request and authentication document by the hardware security module using one or more predefined sets of requirements of a workload assignment policy; determining one or more sets of workload requirements for the client workload by the hardware security module when the verification of the key generation request and the authentication document for the key generation request is successful; generating the encryption key for the client workload by the hardware security module to be used by the hardware security module to provide the client workload with an encryption operation, and encoding the one or more workload requirements as one or more attributes of the generated encryption key for the client workload to assign the availability of the generated encryption key to an encryption operation request by the client workload; and returning the generated encryption key for the client workload having the one or more attributes of the generated encryption key to the client workload by the hardware security module, wherein the generated encryption key for the client workload having the one or more attributes of the generated encryption key is cryptographically protected using a hardware security module key.

[0139] [Item 20] A stateless hardware security module that enables security for cryptographic operations performed by the hardware security module for a client workload, wherein the hardware security module includes: a procedure for receiving a key generation request from the client workload; a procedure for receiving an authentication document for the key generation request signed by a first authentication service using a first cryptographic authentication signing key; a procedure for verifying the key generation request and the authentication document using one or more predefined sets of requirements of a workload assignment policy; a procedure for determining one or more sets of workload requirements for the client workload when the verification of the key generation request and the authentication document for the key generation request is successful; and a procedure used to provide cryptographic operations to the client workload. A procedure comprising: generating an encryption key for the client workload by the hardware security module; and encoding one or more workload requirements as one or more attributes of the generated encryption key for the client workload in order to assign the availability of the generated encryption key to encryption operation requests by the client workload; and a stateless hardware security module configured for the procedure, wherein the generated encryption key for the client workload having the one or more attributes of the generated encryption key is returned to the client workload, and the generated encryption key for the client workload having the one or more attributes of the generated encryption key is cryptographically protected using a hardware security module key.

[0140] Referring now to Figure 8, an exemplary cloud computing environment 800 is illustrated. The computing environment 800 includes an example of an environment for executing at least a portion of the computer code involved in performing the method of the present invention, such as the table storage code 900. In addition to block 900, the computing environment 800 includes, for example, a computer 801, a wide area network (WAN) 802, an end-user device (EUD) 803, a remote server 804, a public cloud 805, and a secret cloud 806. In this embodiment, the computer 801 includes a processor set 810 (including processing circuits 820 and a cache 821), a communication fabric 811, volatile memory 812, persistent storage 813 (including an operating system 822 and the block 900 shown above), a peripheral device set 814 (including a user interface (UI) device set 823, storage 824, and an Internet of Things (IoT) sensor set 825), and a network module 815. The remote server 804 includes a remote database 830. Public Cloud 805 includes Gateway 840, Cloud Orchestration Module 841, Host Physical Machine Set 842, Virtual Machine Set 843, and Container Set 844.

[0141] Computer 801 may 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 currently known or to be developed in the future that is capable of running programs, accessing networks, or querying databases such as the remote database 830. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation may be distributed among multiple computers and / or multiple locations. On the other hand, in this description of the computing environment 800, in order to make the explanation as concise as possible, the detailed discussion will focus on a single computer, specifically computer 801. Although computer 801 is not shown in the cloud in Figure 8, it may be located in the cloud. On the other hand, computer 801 does not need to be located in the cloud, except in any extent definitively shown.

[0142] The processor set 810 includes one or more computer processors of any kind currently known or to be developed in the future. The processing circuitry 820 may be distributed across multiple packages, for example, multiple interconnected integrated circuit chips. The processing circuitry 820 may implement multiple processor threads and / or multiple processor cores. The cache 821 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 810. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 810 may operate using qubits and be designed to perform quantum computing.

[0143] Computer-readable program instructions are typically loaded onto computer 801, and the computer implementation method is realized by causing the processor set 810 of computer 801 to execute a series of operational steps. As a result, the instructions thus executed instantiate the methods specified in the flowcharts and / or descriptions of the computer implementation methods contained herein (collectively referred to as the "Methods 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 the processor set 810 to control and direct the execution of the Methods of the Invention. In the computing environment 800, at least some of the instructions for executing the Methods of the Invention may be stored in block 900 within persistent storage 813.

[0144] The communication fabric 811 is a signal conduction path that enables various components of the computer 801 to communicate with each other. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, and physical input / output ports. Other types of signal communication paths, such as optical fiber communication paths and / or wireless communication paths, may be used.

[0145] Volatile memory 812 is any type of volatile memory currently known or to be 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 required unless explicitly stated. In computer 801, volatile memory 812 is located in a single package and resides inside computer 801, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 801.

[0146] Persistent storage 813 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to computer 801 and / or directly to persistent storage 813. Persistent storage 813 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 822 may take several forms, such as various known proprietary operating systems employing a kernel or open-source portable operating system interface type operating systems. The code contained in block 900 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0147] The peripheral device set 814 includes a set of peripheral devices for computer 801. Data communication connections between computer 801's peripheral devices and other components may be implemented in various ways, such as Bluetooth® connections, near-field communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), insert-type 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, the UI device set 823 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 824 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 824 may be persistent and / or volatile. In some embodiments, storage 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 (for example, when computer 801 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 825 consists of sensors used in an Internet of Things application. For example, one sensor may be a thermometer and another may be a motion detector.

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

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

[0150] The end-user device (EUD) 803 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 801), and may take any of the forms described above in relation to computer 801. EUD 803 typically receives useful and valuable data from the operation of computer 801. For example, in a hypothetical case where computer 801 is designed to provide recommendations to an end-user, these recommendations would typically be transmitted from computer 801's network module 815 to EUD 803 via WAN 802. Thus, EUD 803 can display or otherwise present recommendations to the end-user. In some embodiments, EUD 803 may be a client device such as a thin client, heavy client, mainframe computer, or desktop computer.

[0151] The remote server 804 is any computer system that provides at least some data and / or functionality to computer 801. The remote server 804 may be controlled and used by the same entity that operates computer 801. The remote server 804 represents a machine that collects and stores useful and beneficial data for use by other computers, such as computer 801. For example, in a hypothetical case where computer 801 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 801 from the remote database 830 of the remote server 804.

[0152] Public Cloud 805 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computer functions, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of Public Cloud 805 is performed by the computer hardware and / or software of the Cloud Orchestration Module 841. The computing resources provided by Public Cloud 805 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 842, which is a universe of physical computers located within and / or available to Public Cloud 805. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 843 and / or containers from the container set 844. These VCEs are understood to be stored as images and transferred either as images or after VCE instantiation, among and between hosts on various physical machines. The cloud orchestration module 841 manages the transfer and storage of images, deploys new VCE instantiations, and manages active instantiations of VCE deployments. The gateway 840 is a collection of computer software, hardware, and firmware that enables the public cloud 805 to communicate over the WAN 802.

[0153] Here, we offer some further explanation of virtual computing environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known 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 in which the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running within them. Computer programs running on a normal operating system can utilize all of that computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0154] The secret cloud 806 is similar to the public cloud 805, except that its computing resources are available only for use by a single enterprise. While the secret cloud 806 is shown as being in communication with the WAN 802, in other embodiments, the secret cloud may be completely isolated from the internet and accessible only via a local / secret network. A hybrid cloud is a combination of multiple clouds of different types (e.g., secret cloud, community cloud, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate discrete entity, but the larger hybrid cloud architecture is coupled by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configured clouds. In this embodiment, both the public cloud 805 and the secret cloud 806 are 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, memory, storage, applications, virtual machines, and services) that are rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five characteristics, 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 provision computing power, such as server time and network storage, automatically as needed, without requiring human interaction with service providers.

[0158] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin-client 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, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the resources provided, although they may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center), thus exhibiting a degree of location independence.

[0160] Rapid resilience: Capabilities are provisioned quickly and flexibly, sometimes automatically, allowing for rapid scaling out or rapid release and rapid scaling in. Often, to consumers, the available capacity for provisioning 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 measurement capabilities appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts) at a certain level of abstraction. Resource utilization is monitored, controlled, and reported, thereby providing transparency to both service providers and consumers.

[0162] The service model is as follows:

[0163] Software as a Service (SaaS): The capability offered to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible 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 networks, servers, operating systems, storage, or even individual application capabilities, with the exception of limited user-specific application configuration settings.

[0164] Platform as a Service (PaaS): The capability offered to consumers is the ability to deploy applications they have created or acquired, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do control the configuration of the deployed applications and, in some cases, the application hosting environment.

[0165] Infrastructure as a Service (IaaS): The ability provided to consumers is to provision processing, storage, networking, and other basic computing resources, allowing consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating system, storage, and deployed applications, and, in some cases, have limited control over selected networking components (e.g., host firewalls).

[0166] The deployment model is as follows:

[0167] Secret Cloud: The cloud infrastructure is operated solely for the organization. It may be managed by the organization or a third party, and may reside on-premises or off-premises.

[0168] Community Cloud: A cloud infrastructure is shared by multiple organizations to support a specific community that shares common interests (e.g., mission, security requirements, policies, and compliance considerations). The community cloud may be managed by those organizations or third parties and may reside on-premises or off-premises.

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

[0170] Hybrid Cloud: This cloud infrastructure is a complex of two or more clouds (private, community, or public) that remain unique entities but are joined together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing across clouds).

[0171] Cloud computing environments are service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing lies an infrastructure that includes a network of interconnected nodes.

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

[0173] Referring now to Figure 10, we see a set of functional abstraction layers provided by the cloud computing environment 1050 (Figure 9). It should be understood in advance that the components, layers, and functions shown in Figure 10 are for illustrative purposes only and that embodiments of the present invention are not limited thereto. As illustrated, 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 mainframe 1061, a RISC (Least Instruction Set Computer) architecture-based server 1062, a server 1063, a blade server 1064, a storage device 1065, and a network and network components 1066. In some embodiments, the software components include network application server software 1067 and database software 1068. Furthermore, the hardware components may consist of cryptographic hardware 1069, as described with reference to Figure 1 or Figure 7, and configured to perform methods according to this subject, such as those described with reference to Figures 2 to 6. The cryptographic hardware 1069 may implement, for example, a remote stateless HSM.

[0175] The virtualization layer 1070 provides an abstraction layer from which the following example virtual entities may be provided: a virtual server 1071, virtual storage 1072, a virtual network 1073 including a virtual secret network, a virtual application and operating system 1074, and a virtual client 1075.

[0176] In one example, the management layer 1080 may provide the functions described below. Resource provisioning 1081 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 1082 provides cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 1083 provides consumers and system administrators with access to the cloud computing environment. Service level management 1084 provides cloud computing resource allocation and management to ensure that required service levels are met. Service level agreement (SLA) planning and execution 1085 provides pre-arrangements and procurement for cloud computing resources where future requirements are anticipated in accordance with SLAs.

[0177] The workload layer 1090 provides examples of functionality that utilizes the cloud computing environment. Examples of workloads and functions provided from this layer include mapping and navigation 1091, software development and lifecycle management 1092, virtual classroom education delivery 1093, data analysis processing 1094, transaction processing 1095, and stateless remote cryptographic services 1096 that use cryptographic hardware 1069 in accordance with this subject (as described, for example, with reference to Figures 1 to 7).

[0178] While this disclosure includes a detailed description of cloud computing, it should be understood that the implementations of the teachings cited herein are not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment currently known or to be developed in the future.

[0179] Various aspects of this disclosure are illustrated by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of mechanical logic included in embodiments of computer program products (CPPs). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, again depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated step, simultaneously, or with at least partial time overlap.

[0180] Computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media ("mediums") that collectively comprise a set of one or more storage devices that collectively contain 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 for use by a computer processor. Computer-readable storage media may be, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination of those described above. Some known types of storage devices, including these media, include diskettes, 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 disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any preferred combination of the foregoing. Computer-readable storage media, as used in this disclosure, shall not be construed as storage in the form of transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media. As will be understood by those skilled in the art, data is normally moved at several intermittent points during the normal operation of a storage device, for example, during access, defragmentation, or garbage collection; however, since data is not transient while it is stored, the above does not mean that the storage device is transient.

Claims

1. A method for enabling security for cryptographic operations performed by a stateless hardware security module for client workloads, wherein the method is: The step of receiving a key generation request from the client workload via the hardware security module; The hardware security module receives an authentication document for the key generation request, which has been signed by the first authentication service using a first cryptographic authentication signing key; The hardware security module verifies the key generation request and authentication document using one or more predefined sets of requirements of the workload allocation policy; The hardware security module determines one or more sets of workload requirements for the client workload when the key generation request and the authentication document for the key generation request have been successfully verified; The steps include: generating a first encryption key for the client workload used by the hardware security module for providing encryption operations to the client workload, and encoding the one or more workload requirements as one or more attributes of the generated first encryption key for the client workload in order to assign the availability of the generated first encryption key to encryption operation requests by the client workload; and The hardware security module returns the generated first encryption key to the client workload having one or more attributes of the generated first encryption key, and the generated first encryption key to the client workload having one or more attributes of the generated first encryption key is cryptographically protected using the hardware security module key. A method for providing this.

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

3. The method according to any one of the preceding claims, wherein the one or more workload requirements for the client workload are determined using one or more of the authentication document for the key generation request and the workload assignment policy.

4. The method according to any one of the preceding claims, wherein the authentication document for the key generation request comprises: the machine type ID of the machine, the client workload on which the machine runs; a checksum of the base image of the execution environment of the client workload; a checksum of the root partition at the time of 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 time of building the execution environment of the client workload, the root partition used to build the execution environment; a checksum of the client workload container image containing the client workload; the geographical location of the machine, the client workload on which the machine runs; the ID of a cryptographic authentication signature verification key for verifying the signature generated using the first cryptographic authentication signature key; and one or more certificates for verifying the signature generated using the first cryptographic authentication signature key.

5. The method according to any one of the preceding claims, wherein the workload assignment policy includes the ID of the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; a certificate for verifying the generated signature using the first cryptographic authentication signing key; the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signing key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of 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 at the time of the build of the execution environment of the client workload, the root partition used for the build of the execution environment; the client workload container image containing the client workload; the geographic location of the machine on which the client workload runs; one or more predefined constraints using the first encryption key generated for the client workload; and one or more rules for updating the first encryption key generated for the client workload.

6. The one or more attributes of the first encryption key generated for the client workload are: The method of any one of the above claims, comprising: the ID of the cryptographic authentication signature verification key for verifying the signature generated using the first cryptographic authentication signature key; the cryptographic authentication signature verification key for verifying the generated signature using the first cryptographic authentication signature key; the machine type ID of the machine on which the client workload runs; the checksum of the base image of the execution environment of the client workload; the checksum of the root partition at the time of 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 at the time of the build of the execution environment of the client workload, the root partition used for the build of the execution environment; the client workload container image containing the client workload; the geographic location of the machine on which the client workload runs; and one or more IDs of the first cryptographic key generated for the client workload.

7. The aforementioned method, Steps include: receiving an encryption operation request from the client workload via the hardware security module, the encryption operation request being received along with the first encryption key of the client workload and one or more attributes of the first encryption key, which are cryptographically protected using the hardware security module key; The hardware security module receives an authentication document for the encryption operation request, which is signed by the first authentication service using the first cryptographic authentication signing key; A step in which the hardware security module verifies the encryption operation request and the authentication document for the encryption operation request using one or more attributes of the first encryption key of the client workload; When the verification of the encryption operation request and the authentication document for the encryption operation request is successful, the client workload performs the encryption operation requested by the encryption operation request using the first encryption key. The method according to any one of the preceding claims, further comprising:

8. The method of the preceding claim, wherein the received first encryption key of the client workload having one or more attributes of the first encryption key which is cryptographically protected by encryption using the hardware security module key is decrypted by the hardware security module for use by the hardware security module.

9. The aforementioned method, Steps include: receiving an update readiness request from the client workload via the hardware security module, the update readiness request being received along with the first encryption key of the client workload and one or more attributes of the first encryption key, which are cryptographically protected using the hardware security module key; The hardware security module receives an authentication document for the update preparation request, which has been signed by the first authentication service using the first cryptographic authentication signing key; The step of receiving the updated authentication document by the hardware security module; A step in which the hardware security module verifies the update preparation request and the authentication document for the update preparation request using one or more attributes of the first encryption key of the client workload; The hardware security module determines one or more updated sets of workload requirements for the updated client workload using the updated authentication document; Steps include: generating a second encryption key for the updated client workload when the verification of the update preparation request and the authentication document for the update preparation request is successful, and encoding the one or more updated workload requirements as one or more attributes of the generated second encryption key for the updated client workload in order to assign the availability of the generated second encryption key by the updated client workload to an encryption operation request; and The hardware security module returns the generated second encryption key of the updated client workload, which has one or more of the attributes of the generated second encryption key, to the client workload that is passed to the updated client workload, and the generated second encryption key of the client workload, which has one or more of the updated attributes of the generated second encryption key, is cryptographically protected using the hardware security module key. The method according to any one of the preceding claims, further comprising:

10. The method of the preceding claim, wherein the received first encryption key of the client workload having one or more attributes of the first encryption key which is cryptographically protected by encryption using the hardware security module key is decrypted by the hardware security module for use by the hardware security module.

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

12. The method according to any one of the three preceding claims, wherein the updated authentication document is a prediction of the authentication document for predicting the updated client workload.

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

14. The method according to any one of the five preceding claims, wherein the generated second encryption key of the updated client workload having the one or more attributes of the generated second encryption key is cryptographically protected using a hardware security module key, independently of the first encryption key of the client workload having the one or more attributes of the first encryption key of the client workload.

15. The method according to any one of the six preceding claims, wherein the generated second encryption key of the updated client workload having the one or more attributes of the generated second encryption key is cryptographically protected in combination with the first encryption key of the client workload having the one or more attributes of the first encryption key of the client workload, and the combination is configured to be used by the client workload and the updated client workload.

16. The aforementioned method, Step 1: The hardware security module receives a key update request from the updated client workload, the key update request is received along with a combination of the first encryption key of the client workload having one or more attributes of the first encryption key of the client workload, and the second encryption key of the updated client workload having one or more attributes of the second encryption key of the updated client workload, the combination being cryptographically protected using the hardware security module key; The hardware security module receives an authentication document for the key update request, which has been signed by the second authentication service using the second encryption authentication signing key; The hardware security module verifies the key update request and the authentication document for the key update preparation request using one or more attributes of the second encryption key of the updated client workload; Steps include: generating a third encryption key for the updated client workload and encoding the encryption operation request as one or more attributes of the second encryption key as attributes of the generated third encryption key for the updated client workload in order to assign usability of the generated third encryption key by the updated client workload when the key update request and the authentication document for the key update request are successful; and The hardware security module returns the generated third encryption key of the updated client workload, which has one or more attributes of the generated third encryption key, to the updated client workload as a substitute for the combination of the first encryption key of the client workload, which has one or more attributes of the first encryption key of the client workload, and the second encryption key of the updated client workload, which has one or more attributes of the second encryption key of the updated client workload, and the generated third encryption key of the client workload, which has one or more attributes of the third encryption key, is cryptographically protected using the hardware security module key, step The method according to the above claim, further comprising:

17. The method of the above claim, wherein a received combination of the first encryption key of the client workload having one or more attributes of the first encryption key of the client workload, and the second encryption key of the updated client workload having one or more attributes of the second encryption key of the updated client workload, which is cryptographically protected by encryption using the hardware security module key, is decrypted by the hardware security module.

18. The aforementioned method, The hardware security module receives an update activation request from the security configuration server; The hardware security module receives an authentication document for the activation request, signed by the third authentication service using a third cryptographic authentication signing key; The step of receiving the updated authentication document by the hardware security module; A step in which the hardware security module verifies the update enablement request and the authentication document for the update enablement request using the set of one or more predefined requirements of the workload allocation policy; The hardware security module determines one or more updated sets of workload requirements for the updated client workload using the updated authentication document; Steps include: generating the second encryption key for the updated client workload when the update activation request and the verification of the authentication document for the update activation request are successful, and encoding the one or more updated workload requirements as one or more attributes of the generated second encryption key for the updated client workload in order to assign the availability of the generated second encryption key by the updated client workload to an encryption operation request; and The hardware security module returns the generated second encryption key of the updated client workload to the security build server, which is passed to the updated client workload, having one or more attributes of the generated second encryption key, and the generated second encryption key of the client workload, having one or more updated attributes of the generated second encryption key, is cryptographically protected using the hardware security module key. The method according to any one of the preceding claims, further comprising:

19. A computer program product for enabling the security of cryptographic operations performed by a stateless hardware security module for client workloads, wherein the computer program product comprises a computer-readable storage medium in which computer-readable program code is embodied, The step of receiving a key generation request from the client workload via the hardware security module; The hardware security module receives an authentication document for the key generation request, which has been signed by the first authentication service using a first cryptographic authentication signing key; The hardware security module verifies the key generation request and authentication document using one or more predefined sets of requirements of the workload allocation policy; The hardware security module determines one or more sets of workload requirements for the client workload when the key generation request and the authentication document for the key generation request have been successfully verified; The steps include: generating the encryption key for the client workload used by the hardware security module to provide the client workload with encryption operations; and encoding the one or more workload requirements as one or more attributes of the generated encryption key for the client workload in order to assign the availability of the generated encryption key to encryption operation requests by the client workload; and The hardware security module returns the generated encryption key of the client workload having one or more of the aforementioned attributes of the generated encryption key to the client workload, and the generated encryption key of the client workload having one or more of the aforementioned attributes of the generated encryption key is cryptographically protected using the hardware security module key. A computer program product configured to implement a method that includes [a specific method].

20. A stateless hardware security module that enables security for cryptographic operations performed by the hardware security module for client workloads, wherein the hardware security module is Procedure for receiving a key generation request from the aforementioned client workload; A procedure for receiving an authentication document for the key generation request, signed by a first authentication service using a first cryptographic authentication signing key; A procedure for verifying the key generation request and authentication document using one or more predefined sets of requirements of a workload allocation policy; A procedure for determining one or more sets of workload requirements for the client workload when the verification of the key generation request and the authentication document of the key generation request is successful; A procedure for generating the encryption key for the client workload used to provide encryption operations to the client workload using the hardware security module, and encoding the one or more workload requirements as one or more attributes of the generated encryption key for the client workload in order to assign the availability of the generated encryption key to encryption operation requests by the client workload; and A procedure for returning the generated encryption key to the client workload having one or more attributes of the generated encryption key, the generated encryption key to the client workload having one or more attributes of the generated encryption key is cryptographically protected using a hardware security module key. A stateless hardware security module configured for this purpose.

Images