Computer-implemented method, upgrade system and computer program for securely transferring secrets

Abstract

To provide a computer-implemented method and an upgrade system for securely transferring a secret.SOLUTION: A source computing component and a target computing component are part of a secure computing environment. The method comprises: upon the source computing component receiving from the target computing component a signed attestation document, verifying, by the source computing component, authenticity and content of the attestation document; and, upon a successful verification of the authenticity and the content, transferring, by the source computing component, the secret to the target computing component. Thereby, the attestation document attests that the target computing component is compliant to an update governance rule.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to trusted system upgrades and secret transfer in a secure computing environment. The present invention relates generally to a computer-implemented method for securely transferring secrets between computing components, and more particularly to a computer-implemented method for securely transferring secrets from a source computing component to a target computing component, where the source computing component and the target computing component are part of a secure computing environment. The present invention further relates to an upgrade system and a computer program product and computer program for securely transferring a secret key from a source computing component to a target computing component. [Background technology]

[0002] Given the significant increase in hacker attacks against computing systems of all kinds and in all enterprises, secure computing environments are becoming an important tool for ensuring process support and data protection for enterprises. This is relevant for all types of computing, mainframe computers, systems supporting open source operating systems, personal devices, mobile devices, and IoT (Internet of Things) infrastructure. In this context, trusted execution environments play a leading role in ensuring that application programs or services function properly as building blocks of application programs. Currently, a secure execution environment may have two main tasks: (i) protecting memory accesses outside of the application workload, and (ii) protecting application code from manipulation (and possibly associated data as well).

[0003] Some of the known problems and challenges of prior art trusted execution environments and secure execution techniques present weaknesses in the following situations: Secure life migration, especially between updates of applications and their respective workloads. This update aspect is particularly important when legacy applications or services use encryption / decryption keys for data access.

[0004] In addition, transferring trust control from infrastructure providers and workload providers to data controllers or owners, or a combination thereof, can also be problematic. In a container computing environment, it is often unclear which software containers can be trusted. Furthermore, in a classic trusted execution environment, confidential computing-protected workloads cannot be managed and orchestrated by a given infrastructure without compromising the trust level and data confidentiality. Furthermore, existing trusted execution environments may also be vulnerable to system updates, in some cases, including, for example, malicious or vulnerable software versions that do not comply with update or upgrade policies, or a combination thereof. Furthermore, infrastructure providers may have access to data by manipulating software infrastructure systems. However, this aspect may also need to be addressed by a highly trusted execution environment.

[0005] In this context, several documents have already been published: for example, document US2020 / 0021615A1 describes a container development system for publishing a container image and enforcing approval of each unique container instance by the business organization that requested the container instance. The controller may be programmed or configured to apply one or more approval policies to determine whether the container instance should be run or not. Additionally, document US2017 / 0244787A1 describes a method for hot swapping and hot scaling containers between multiple cloud services. The method includes storing, with the cloud exchange, data indicating an association between a first container of a first private network and a second container of a second private network connected to the cloud exchange for transmitting and receiving data packets via the cloud exchange.

[0006] However, none of these documents address the issues mentioned above, particularly the update scenario of secure access to data that is part of a container instance. Therefore, there may be a need to address such scenarios in a secure and reliable manner. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] U.S. Patent Application Publication No. US2020 / 0021615A1 [Patent Document 2] U.S. Patent Application Publication No. US2017 / 0244787A1 Summary of the Invention [Problem to be solved by the invention]

[0008] The present invention aims to provide a method, an upgrade system and a computer program for upgrading a trusted system and transferring secrets in a secure computing environment. [Means for solving the problem]

[0009] According to one aspect of the invention, there is provided a computer-implemented method for securely transferring a secret from a source computing component to a target computing component, wherein the source computing component and the target computing component are part of a secure computing environment. In response to the source computing component receiving a signed attestation document from the target computing component, the source computing component may verify the authenticity and content of the attestation document, and in response to successful verification of the authenticity and content, the source computing component may transfer the secret to the target computing component. The attestation document may thereby attest to the target computing component's compliance with update governance rules.

[0010] According to another aspect of the present invention, an upgrade system for securely transferring a private key from a source computing component to a target computing component is provided. The system includes a processor and a memory communicatively coupled to the processor, the memory storing program code portions that, when executed, enable the processor to, in response to the source computing component controlled by the processor receiving a signed attestation document from the target computing component, verify the authenticity and content of the attestation document, and, in response to successful verification of the authenticity and content, transfer the secret to the target computing component. The attestation document may thereby attest to the target computing component's compliance with update governance rules.

[0011] The proposed computer-implemented method for securely transferring secrets from a source computing component to a target computing component, where the source computing component and the target computing component are part of a secure computing environment, may provide one or more of the following advantages, technical effects, contributions, or improvements, or a combination thereof:

[0012] In contrast to known technologies, one of the problems solved may be the fact that secure life migration is becoming a reality, especially during updates of applications and respective workloads. This is especially important when the data can be accessed using encryption keys / secrets for workload data. The concept proposed herein may ensure secure transfer of encryption / decryption keys or any other secrets to the new workload after migration or update.

[0013] This may enable a secured transfer of trust from infrastructure providers (e.g., cloud computing providers) and workload providers (e.g., providers of specific services) to data owners (i.e., data controllers). It may be ensured that workloads dynamically determine which other containers can be trusted. Launching a workload (e.g., in the form of a container instance) may be possible only after successful verification of trust. Thus, confidential computing-protected workloads may be managed and orchestrated by the infrastructure without compromising the trust level and data confidentiality. Therefore, the solution proposed herein may support a trusted ecosystem for “scale-out” and trusted ripple update scenarios. Furthermore, certain types of security attacks may be avoided, such as attempts to update a system with malicious or outdated or vulnerable software versions. This type of attack may be addressed by the concepts proposed herein by validating update policies. Furthermore, adverse effects caused by infrastructure providers attempting to manipulate underlying infrastructure software systems may be avoided.

[0014] The update governance rules proposed herein may define requirements and policies for updating an application (e.g., in the form of a container instance), which may be executed in a trusted execution environment. These update governance rules may be enforced whenever an existing application is to be updated. If the update governance rules cannot be satisfied, the new component (i.e., the new application, e.g., in the form of a container instance) will not be updated. However, if the update governance rules can be satisfied, the new application / component is deployed to a new version, and an advantageous "secure handover" may be performed between the old and new versions of the application.

[0015] The update governance component can thereby be implemented as part of the application workload itself and run in the same trusted execution scope, preventing any external manipulation, so that multiple, generally definable requirements and policies can be verified.

[0016] This protects investments, as new versions of computing components can be blocked by update governance rules unless the data owner inspects and verifies their safety, and mitigates the risk of supply chain attacks in scenarios where the workload provider itself could be attacked, or where the workload provider is the attacker.

[0017] Below, additional embodiments of the inventive concepts (ie, the inventive concepts applicable for methods as well as systems) are described.

[0018] According to an advantageous embodiment of the method, the update governance rules may state that the target computing component is part of a secure execution environment, that the target computing component conforms to at least one predefined characteristic (particularly a set of characteristics), or that the target computing component can be generated by the secure computing environment, or a combination thereof. It will be understood that these mentioned update governance rules may represent only a subset of potential update governance rules, which may span a broader set of conditions. Some such conditions are described below in the context of FIG. 4.

[0019] According to another advantageous embodiment of the method, the predefined characteristics may define (i) a set of previous source computing components from which the target computing component can be upgraded, or (ii) a set of build process characteristics to which the target computing component must conform, or a combination thereof. In this way, only predefined update paths may be permitted, while other (and permitted) update paths are not supported by the proposed method. Furthermore, a controlled set of conditions may be established under which the target computing component (again, an application or software container instance or virtual machine) may be built, thereby ensuring that the build process may also have been executed in a trusted computing environment.

[0020] According to a preferred embodiment of the method, the target computing component may be an updated version of the source computing component. Thus, the target computing component may be newer than the source computing component. The target computing component may include some bug fixes or additional functionality.

[0021] According to an interesting embodiment of the method, the target computing component and the source computing component may each be an executable software container or a virtual machine. The executable software container may be a component in a Docker computing environment. A container may thereby be a standard unit of software that packages code with all dependencies, so that the application can be quickly and reliably executed from one computing environment to another. Thus, a Docker container image is a lightweight, standalone, executable software package that includes everything needed to run an application, such as application logic code, runtime, system tools, system libraries, and configuration.

[0022] According to a useful embodiment of the method, the target computing component and the source computing component may each comprise an update governance component for ensuring compliance with update governance rules. In the accompanying drawings, the update governance components are shown as policy APIs on the source computing component side and the target computing component side. They may be responsible for establishing trust (in a computational sense) and transferring secrets from the source computing component to the target computing component.

[0023] According to another preferred embodiment, the method may also include, in response to successful verification and transferring the secret to the target computing component, having the target computing component take over operations and shutting down the source computing component. At this point, the source computing component is retired and all operations are performed by the target computing component. Data from the source computing component may also have been transferred to storage at the target computing component, and optionally, the source computing component may have been disconnected from its storage.

[0024] According to another very useful embodiment, the method may further comprise that, upon initialization of the first computing component or any other initialized computing component, a new encryption key, or generally a new secret, may be created by the first computing component, whereby a new data store associated with the first computing component may be generated. In this way, a standard procedure for initializing new computing components, i.e., each computing component, may be ensured.

[0025] According to a further developed embodiment of the method, an update governance component for ensuring compliance with update governance rules may be located in, and in particular executed by, a third system, which may be implemented externally to the source computing component and the target computing component. Optionally, the update governance component may also be executed in its own secure computing environment, which may comply with its own secure execution rules and regulations.

[0026] According to another advanced embodiment of the method, the update governance rule or rules may describe a list of one or more entities that approve updates through a secure mechanism. In this way, it may be possible to control that a validation quorum may be required to initiate and execute the update process from the source computing component to the target computing component. For example, a certain number of operators may be required to verify the upgrade from the source computing component to the target computing component. This may be based on a technical mechanism using software signatures.

[0027] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer usable or computer readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer usable or computer readable medium may be any apparatus that may include means for storing, communicating, transmitting, or transferring a program for use by or in connection with an instruction execution system, apparatus, or device.

[0028] It should be noted that embodiments of the present invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, those skilled in the art will understand from the above and following description that, unless otherwise indicated, in addition to any combination of features belonging to one type of subject matter, any combination between features relating to different subject matters, in particular any combination between features of a method-type claim and a feature of an apparatus-type claim, is also considered to be disclosed within this specification.

[0029] The above-mentioned and further aspects of the present invention will be apparent from and will be explained with reference to the examples of embodiments to which the present invention is not limited, as will be described hereinafter.

[0030] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings, in which: [Brief explanation of the drawings]

[0031] [Figure 1] FIG. 1 shows a block diagram of an embodiment of a computer-implemented method for securely transferring secrets from a source computing component to a target computing component, where the source computing component and the target computing component are part of a secure computing environment. [Figure 2] FIG. 2 shows a block diagram of an exemplary configuration illustrating the dependencies and connections between components that support the novel concept. [Figure 3] FIG. 3 shows a communication diagram of the process for the initial startup of an example container instance. [Figure 4] FIG. 4 shows another, more expanded communication diagram of the method already outlined in the context of FIG. [Figure 5] FIG. 5 illustrates a block diagram of one embodiment of an upgrade system for securely transferring a private key from a source computing component to a target computing component. [Figure 6] FIG. 6 shows an embodiment of a computing system comprising a system according to FIG. DETAILED DESCRIPTION OF THE INVENTION

[0032] In the context of this description, the following conventions, terms or expressions, or combinations thereof, may be used:

[0033] The term "securely transferring secrets" may mean that secrets, especially access codes or encryption / decryption keys, can be sent from a source system to a target system without the possibility of compromising the transfer. This may be enabled by a trusted component, such as a trusted sender, a trusted receiver, a trusted transmission path, or a trusted computing environment, or a combination thereof.

[0034] The term "source computing component" may refer to a version of an application, which may also be implemented as part of a virtual machine or a Docker container instance.

[0035] The term "target computing component" may refer to a different application, a similar application, or the same application when compared to a source computing component. However, the target computing component may have a higher version number or release, i.e., it may be newer. Consequently, the target computing component may also be a software application, a virtual machine, or a Docker container.

[0036] The term "secure computing environment" may refer to computing components that interact with each other in an uncompromising manner. This may also apply to data stored in secure storage systems as well as other data security measures. The data may be encrypted with secure keys, and computing components may only be activated using secure keys or signatures.

[0037] The term "signed certification document" may essentially mean a binary string that the certification may be encoded in. Furthermore, the string may be signed, which means an encapsulated software envelope so that the origin of the document / binary string can be proven.

[0038] The term "update governance rules" may refer to one or more conditions that must be met to allow or enable a version upgrade of an application, virtual machine, or software container instance.

[0039] The term "updated version" may refer to a new implementation of an existing software artifact, such as an application, a virtual machine, or a Docker container instance.

[0040] The term "executable software container" may refer to a directly executable software artifact, for example in the form of a Docker container instance. Docker is thereby a known set of platform as a service (PaaS) products that use operating system virtualization to deliver software in packages called containers. Containers are isolated from each other and bundle their own software, libraries, and configuration files. Containers can communicate with each other through well-defined channels.

[0041] Below, a detailed description of the drawings is provided. All designations in the figures are schematic. First, a block diagram of an embodiment of a computer-implemented method of the present invention for securely transferring secrets from a source computing component to a target computing component is provided, where the source computing component and the target computing component are part of a secure computing environment. Thereafter, further embodiments are described, as well as an embodiment of an upgrade system for securely transferring secrets from a source computing component to a target computing component.

[0042] 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for securely transferring secrets from a source computing component (e.g., an old container or an old application version) to a target computing component (e.g., another container or an updated new application), where the source computing component and the target computing component are part of a secure computing environment. In response to the source computing component receiving a signed attestation document from the target computing component, the source computing component verifies the authenticity and content of the attestation document (102), and, in response to successful verification of the authenticity and content, the source computing component transfers the secret (e.g., an encryption / decryption key or another secret code) to the target computing component (104). The attestation document thereby attests to the target computing component's compliance with update governance rules, particularly a plurality of rules, i.e., update governance rules.

[0043] Figure 2 shows a block diagram of an example architecture 200 illustrating the dependencies and connections between components to support the novel concept. When a new application container 208 deployment is requested, a deployment driver 214 initiates the deployment process. The deployment driver 214 triggers the deployment of the application by providing information (216), such as the application version to run, or the application configuration, or a combination thereof. For this purpose, an external trust provider can exist, and the required tokens or signatures can be provided (220) from the trust provider 218 to the deployment driver 214.

[0044] An existing application container 204 whose general functionality needs to be migrated to a new / updated application container 208 can maintain runtime secrets 206, for example, to access the existing application container 200 for data (not shown). A deployment interface 210 can create (212) the new application container 208 and can also help generate a new protected, i.e., encrypted, data store. Thus, the deployment interface 210 can also help generate new runtime secrets (not shown). In either case, however, the existing application container as well as the new application container 208 can have an included update governance component (shown in FIG. 1 as policy APIs 224 and 226) as an integral part, which can negotiate trust and, optionally, hand over any necessary secret keys. It should also be noted that the existing application container 204 will perform its operations until a takeover is triggered via the policy APIs 224 and 226. This is because the security-relevant elements, i.e., deployment interface 210, existing application / application container 204, new application container 208, and policy APIs 224 and 226, all run in the same secure execution environment 202. The probability of interfering with, manipulating, or attacking the migration process from the existing application container 204 to the new application container 208 can be reduced to near zero. That is, handing over secret runtime keys is no longer an issue because everything potentially vulnerable can run in the same secure execution environment 202. However, it is not required that the source computing component (e.g., source computing component 204) and the target computing component (e.g., new application container 208) run in the same secure execution environment 202.

[0045] 3 shows a communication diagram 300 of the process for initializing a software artifact using the concepts proposed herein. The following active components are shown in the top region of the diagram: deployment driver 302 (compare deployment driver 214 in FIG. 2), deployment interface 304 (compare deployment interface 210 in FIG. 2), application instance 306 (compare new application container 208 in FIG. 2), and encrypted data 308.

[0046] The following steps are performed: 1. When a deployment is requested, the deployment driver 302 begins the initialization process. 2. The deployment driver 302 triggers the initialization of the application by providing information such as a bearer token, the current application instance to run, the application version, the application configuration, etc. (310). 3. A new application instance 306 is launched (initiated by the deployment interface 304 and represented by reference numeral 312). 4. The new application 306 generates one or more secrets according to the function. 5. The new application instance 306 now begins its operation.

[0047] The new application (or application container or container instance) also generates a new data encryption key (314) and creates encrypted data using the newly generated encryption key (316). It then becomes operational and waits for a complete takeover (318).

[0048] Figure 4 shows a communication diagram 400 of the update process. In addition to the active elements described in the context of Figure 3, new elements are an (external) trusted provider 402 and a current application interface 404 (i.e., the policy API of the current application).

[0049] An optional deployment approval request 406 can optionally be made on-site by returning 408 a token from the trust provider 402 to the deployment driver 302. Additionally, in Figure 4, a takeover request 410 is sent from the new application instance 306 (via its API) to the current application interface 404. The new application instance 306 must provide 412 evidence regarding the takeover policy (update governance policy, see above), and a data encryption key must be passed from the current application to the new application instance 306 (via its Policy API) via the current application interface 404 (i.e., Policy API).

[0050] 4 illustrates the disconnection (416) of the current application interface 404 to the encrypted data 308, its shutdown (418), and the subsequent connection (420) of the new application instance 306 to the encrypted data 308. Finally, reference numeral 422 illustrates the takeover operation of the new application instance 306.

[0051] As mentioned previously, a wide variety of policies can be implemented via the application's policy API, i.e., the Update Governance component. Some examples are shown below:

[0052] An example sensitive application update requires sign-off by a quorum of two-thirds of signatories. The reason for this may be: the update may introduce changes in the application's behavior that need to be reviewed and signed off. For this reason, for example, the following update governance rules are defined to apply: A set of qualified "update approvers" and their signing keys. Ownership of bearer tokens from a central authority is required for a quorum to approve updates: 2 / 3

[0053] Additional requirements may also be required: An update requires a set of certificates (certified assertions) for the new application version. An update requires a certain version of prerequisite components (e.g., other applications that the example application interacts with), which can potentially require transitive updates. Updates also require certain state of the execution environment, which also needs to be asserted.

[0054] The update governance rules may be securely stored, for example, in a repository of a secure computing environment.

[0055] In any case, update governance policies or rules, i.e., denial of trust, can be implemented (i) as part of the application (e.g., in secure code), (ii) created during the build process (e.g., based on policies captured during the build), or (iii) created by an authorized user (during deployment or during runtime), or a combination of (i), (ii), and (iii) above.

[0056] Further examples of update policies, update governance rules, or general policies are useful for the newly proposed concepts: Authentication via an SSO (single sign-on) provider (e.g., oauth, saml, jwt): This policy can verify whether approval from an external trust provider is present, allowing application updates to only be performed if approved by the required stakeholders or automated systems. ●Version Compatibility: The policy can ensure compatibility for application updates. For example, each application policy includes an application version and a list of previous application versions that can be updated. ●Policy: This ensures that the build process for the new application instance was executed successfully, and that all build artifacts required by the application policy are present for the new instance. Operator (signature) quorum for updates: The policy can verify whether a quorum of signatures or approvals has been provided by stakeholders, so for example, at least two administrators may be required to sign off on a rollout. ●Only update to a new version: This policy can ensure that handovers do not occur on older versions. The actual allowed ages or versions are defined by the application policy. Policies that validate "external" requirements for updates: The policy may, for example, allow updates only when keys in an external key store are rotated, data is backed up, ACL lists are audited, automated (scripted) tasks are executed successfully, etc. Policies may reference and invoke interfaces of external components to verify requirements. ●What is the policy in the (runtime) environment? This policy can verify that the execution environment of a new application instance meets certain rules, which might include secure enclaves running in a certain availability zone, data center, or region.

[0057] 5 illustrates a block diagram of one embodiment of an upgrade system 500 for securely transferring secrets from a source computing component 506 to a target computing component 508. The system includes a processor 502 and a memory 504 communicatively coupled to the processor 502, wherein the memory 504 stores program code portions that, when executed, enable the source computing component 506 to, among other things, receive a signed attestation document from the target computing component 508, and, in response, a verification module 510, which may also be, among other things, a policy API, to verify the authenticity and content of the attestation document.

[0058] Moreover, processor 502 may enable a source computing component 506 controlled by the processor to transfer a secret to a target computing component 508 in response to successful verification of the authenticity and the content, thereby allowing the attestation document to attest that the target computing component complies with update governance rules.

[0059] All functional units, modules, and blocks, particularly the processor 502, memory 504, source computing component 506, target computing component 508, and verification module 510, may be communicatively coupled to one another for the exchange of signals or messages in a selected 1:1 manner, or alternatively, may be linked to a system internal bus system 512 for the exchange of selective signals or messages.

[0060] Embodiments of the present invention can be implemented with virtually any type of computer, regardless of the platform on which the program code is stored, executed, or suitable for both storage and execution. Figure 6 shows, by way of example, a computing system 600 suitable for executing program code associated with the proposed method.

[0061] Computing system 600 is merely one example of a suitable computer system, and whether computer system 600 is implemented or capable of performing the functions described herein above, or any combination thereof, is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. There are components in computer system 600 that operate in numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 600 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments comprising any of the above systems or devices. Computer system / server 600 may be described in the general context of computer system-executable instructions, e.g., program modules, executed by computer system 600. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 600 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including, for example, memory storage devices.

[0062] As depicted in the figure, computer system / server 600 is illustrated in the form of a general-purpose computing device. Components of computer system / server 600 may include, but are not limited to, one or more processors or processing units 602, a system memory 604, and a bus 606 connecting various system components, including the system memory 604, to the processor 602. Bus 606 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor bus or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. Computer system / server 600 typically includes a variety of computer system-readable media, which can be any available media that can be accessed by computer system / server 600, and includes both volatile and nonvolatile media, removable and non-removable media.

[0063] The system memory 604 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 608, or cache memory 610, or a combination thereof. The computer system / server 600 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 612 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In such an example, each may be connected to the bus 606 by one or more data media interfaces. As further illustrated and described below, memory 604 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of an embodiment of the present invention.

[0064] A set of program modules 616 (at least one) including programs / utilities, an operating system, one or more application programs, other program modules, and program data may be stored in memory 604, by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may comprise an implementation of a networking environment. The program modules 616 generally perform the functions or methodologies, or combinations thereof, of embodiments of the present invention, as described herein.

[0065] The computer system / server 600 may also communicate with one or more external devices 618, such as a keyboard, pointing device, display 620, one or more devices that allow a user to interact with the computer system / server 600, or any device (e.g., a network card, modem, etc.) that allows the computer system / server 600, or a combination thereof, to communicate with one or more other computing devices. Such communication may occur via an input / output (I / O) interface 614. Additionally, the computer system / server 600 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 622. As shown, the network adapter 622 may communicate with other components of the computer system / server 600 via a bus 606. It should be understood that, although not shown, other hardware or software components or combinations thereof may be used with the computer system / server 600. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disks, drive arrays, RAID systems, tape drives, and data archive storage systems.

[0066] Additionally, the upgrade system 500 for securely transferring secrets from a source computing component to a target computing component may be connected to a bus system 606 .

[0067] The description of various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or to be limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to explain the principles of the embodiments, practical applications or technical improvements to commercially available technology, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0068] The present invention may be a system, method, computer program product, or a combination thereof, which may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0069] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for a propagation medium. Examples of a computer-readable medium may include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD R / W), DVD, and Blu-ray disk.

[0070] The computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge structure in a groove in which instructions are recorded, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0071] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to an individual computing device / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, fiber optic transmission cables, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to the individual computing device / processing device for storage in a computer-readable storage medium.

[0072] Computer-readable program instructions for carrying out operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages ​​(e.g., Smalltalk, C++, etc.), conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0073] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer programs or computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions.

[0074] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, executing on the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or combinations thereof, to function in a particular manner, such that the computer-readable storage medium having stored thereon instructions includes an article of manufacture containing instructions that implement aspects of the functions / acts identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof.

[0075] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, implement the functions / operations identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, causing the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0076] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer programs or computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should also be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

[0077] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. As used herein, the words "comprises" or "comprising" specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0078] In addition to corresponding structure, material, acts, and all means or steps in the appended claims, equivalents of functional elements are intended to encompass any structure, material, or act for performing a function in combination with other claimed elements, as specifically claimed. The detailed description of the present invention has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the invention to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described in order to best explain the principles and practical applications of the invention and to enable those skilled in the art to understand the invention in various embodiments with various modifications suited to the particular applications contemplated.

[0079] Some implementations of the inventive concepts of the present disclosure can be illustrated by the following clauses.

[0080] 1. A computer-implemented method for securely transferring a secret from a source computing component to a target computing component, wherein the source computing component and the target computing component are part of a secure computing environment, the method comprising: In response to the source computing component receiving a signed attestation document from the target computing component, The source computing component verifies the authenticity and content of the attestation document; and Upon successful verification of the authenticity and the content, The source computing component transmits the secret to the target computing component. Including, wherein the attestation document attests that the target computing component complies with update governance rules; The method

[0081] 2. The updated governance rules are: that the target computing component is part of a secure execution environment; that the target computing component conforms to at least one predefined characteristic; or the target computing component is generated by the secure computing environment; or a combination thereof The method of claim 1,

[0082] 3. The predefined characteristic is: one set of previous source computing components from which the target computing components can be upgraded; and A set of build process characteristics to which the target computing component conforms; The method according to item 1 or 2, wherein

[0083] 4. The method of any one of paragraphs 1 to 3, wherein the target computing component is an updated version of the source computing component.

[0084] 5. The method of any one of paragraphs 1 to 4, wherein the target computing component and the source computing component are each an executable software container or a virtual machine.

[0085] 6. The method of any one of paragraphs 1 to 5, wherein the target computing component and the source computing component each include an update governance component for ensuring compliance with the update governance rules.

[0086] 7. responsive to successful verification and forwarding the secret to the target computing component; taking over the operation by the target computing component; and Shutting down the source computing component The method according to any one of items 1 to 6, further comprising:

[0087] 8. Upon initializing the first computing component, generating a new encryption key by the first computing component; and generating a new data store associated with said first computing component; The method according to any one of claims 1 to 7, further comprising:

[0088] 9. The method of any one of paragraphs 1 to 8, wherein an update governance component for ensuring compliance with the update governance rules is located in a third system.

[0089] 10. The method of any one of clauses 1 to 9, wherein the update governance rules describe a list of one or more entities that approve updates through a secure mechanism.

[0090] 11. An upgrade system for securely transferring a private key from a source computing component to a target computing component, the source computing component and the target computing component being part of a secure computing environment, the upgrade system comprising: a processor and a memory communicatively coupled to the processor, wherein the memory, when executed, In response to the source computing component controlled by the processor receiving a signed certification document from the target computing component, the source computing component controlled by the processor verifying the authenticity and content of the certification document; and In response to successful verification of the authenticity and the content, the source computing component controlled by the processor transfers the secret to the target computing component. wherein the attestation document attests that the target computing component complies with update governance rules. The upgrade system.

[0091] 12. The updated governance rules shall: that the target computing component is part of a secure execution environment; that the target computing component conforms to at least one predefined characteristic; or the target computing component is generated by the secure computing environment; or a combination thereof Item 12. The upgrade system of item 11,

[0092] 13. The predefined characteristic is: one set of previous source computing components from which the target computing components can be upgraded; and A set of build process characteristics to which the target computing component conforms Item 13. The upgrade system according to item 11 or 12, wherein the upgrade system defines:

[0093] 14. An upgrade system according to any one of paragraphs 11 to 13, wherein the target computing component is an updated version of the source computing component.

[0094] 15. An upgrade system according to any one of paragraphs 11 to 14, wherein the target computing component and the source computing component are each an executable software container or a virtual machine.

[0095] 16. An upgrade system as described in any one of paragraphs 11 to 15, wherein the target computing component and the source computing component each include an update governance component for ensuring compliance with the update governance rules.

[0096] 17. The processor: responsive to successful verification and forwarding the secret to the target computing component; taking over operation by the target computing component controlled by the processor; and Shutting down the source computing component controlled by the processor. 17. The upgrade system according to any one of items 11 to 16, further enabling the above.

[0097] 18. In response to the initialization of the first computing component, generating a new encryption key by the first computing component; and generating a new data store associated with said first computing component; Item 18. The upgrade system according to any one of items 11 to 17, further comprising:

[0098] 19. An upgrade system according to any one of clauses 11 to 18, wherein the update governance rules describe a list of one or more entities that approve updates through a secure mechanism.

[0099] 20. A computer program for securely transferring a private key from a source computing component to a target computing component, the source computing component and the target computing component being part of a secure computing environment, the computer program comprising: In response to the source computing component controlled by the processor receiving a signed certification document from the target computing component, the source computing component controlled by the processor verifying the authenticity and content of the certification document; and In response to successful verification of the authenticity and the content, the source computing component controlled by the processor transfers the secret to the target computing component. executable by the one or more computing systems or controllers to cause wherein the attestation document attests that the target computing component complies with update governance rules; The computer program. 21. A computer program product for securely transferring a private key from a source computing component to a target computing component, the source computing component and the target computing component being part of a secure computing environment, the computer program product comprising a computer-readable storage medium having embedded program instructions, the program instructions configured to transmit to one or more computing systems: In response to the source computing component controlled by the processor receiving a signed certification document from the target computing component, the source computing component controlled by the processor verifying the authenticity and content of the certification document; and In response to successful verification of the authenticity and the content, the source computing component controlled by the processor forwards the secret to the target computing component, wherein the attestation document certifies that the target computing component complies with update governance rules. the computer program product executable by the one or more computing systems or controllers to cause

Claims

1. 1. A computer-implemented method for securely transferring a secret from a source computing component to a target computing component, wherein the source computing component and the target computing component are part of a secure computing environment, the method comprising: In response to the source computing component receiving a signed certification document from the target computing component, the source computing component verifies the authenticity and content of the certification document; and In response to successful verification of the authenticity and the content, the source computing component transfers the secret to the target computing component. Including, wherein the attestation document attests that the target computing component complies with update governance rules.

2. 2. The method of claim 1, wherein the update governance rules describe that the target computing component is part of a secure execution environment, that the target computing component conforms to at least one predefined characteristic, or that the target computing component is generated by the secure computing environment, or a combination thereof.

3. 3. The method of claim 2, wherein the predefined characteristics define a set of previous source computing components from which the target computing component can be upgraded and a set of build process characteristics to which the target computing component complies.

4. The method of claim 1 , wherein the target computing component is an updated version of the source computing component.

5. The method of claim 1 , wherein the target computing component and the source computing component are each an executable software container or a virtual machine.

6. The method of claim 1 , wherein the target computing component and the source computing component each comprise an update governance component for ensuring compliance with the update governance rules.

7. responsive to successful verification and transferring the secret to the target computing component, taking over operation by the target computing component and shutting down the source computing component. The method of claim 1 , also comprising:

8. The method of claim 7, wherein a new encryption key is generated by the target computing component in response to initialization of the target computing component, and a new data store is generated associated with the target computing component. The method of claim 1 , also comprising:

9. The method of claim 1 , wherein an update governance component for ensuring compliance with the update governance rules is located in a third system.

10. The method of claim 1 , wherein the update governance rules describe a list of one or more entities that approve updates through a secure mechanism.

11. 1. An upgrade system for securely transferring secrets from a source computing component to a target computing component, the source computing component and the target computing component being part of a secure computing environment, the upgrade system comprising a processor and a memory communicatively coupled to the processor, the memory, when executed, performing: In response to the source computing component controlled by the processor receiving a signed certification document from the target computing component, the source computing component controlled by the processor verifying the authenticity and content of the certification document; and and in response to successful verification of the authenticity and the content, the source computing component controlled by the processor forwarding the secret to the target computing component. wherein the attestation document attests that the target computing component complies with update governance rules. The upgrade system.

12. 12. The upgrade system of claim 11, wherein the update governance rules describe that the target computing component is part of a secure execution environment, that the target computing component conforms to at least one predefined characteristic, or that the target computing component is generated by the secure computing environment, or a combination thereof.

13. 13. The upgrade system of claim 12, wherein the predefined characteristics define a set of previous source computing components from which the target computing component can be upgraded and a set of build process characteristics to which the target computing component conforms.

14. The upgrade system of claim 11 , wherein the target computing component is an updated version of the source computing component.

15. The upgrade system of claim 11 , wherein the target computing component and the source computing component are each an executable software container or a virtual machine.

16. 12. The upgrade system of claim 11, wherein the target computing component and the source computing component each include an update governance component for ensuring compliance with the update governance rules.

17. the processor: taking over operation by the target computing component controlled by the processor in response to successful verification and transferring the secret to the target computing component, and shutting down the source computing component controlled by the processor.

12. The upgrade system of claim 11, further comprising:

18. The method of claim 17, wherein a new encryption key is generated by the target computing component in response to initialization of the target computing component, and a new data store associated with the target computing component is generated. The upgrade system of claim 11 , also comprising:

19. The upgrade system of claim 11 , wherein the update governance rules describe a list of one or more entities that approve updates through a secure mechanism.

20. 1. A computer program for securely transferring secrets from a source computing component to a target computing component, the source computing component and the target computing component being part of a secure computing environment, the computer program comprising: In response to the source computing component controlled by a processor receiving a signed certification document from the target computing component, the source computing component controlled by the processor verifying the authenticity and content of the certification document; and and in response to successful verification of the authenticity and the content, the source computing component controlled by the processor forwarding the secret to the target computing component. executable by the one or more computing systems or controllers to cause wherein the attestation document attests that the target computing component complies with update governance rules. The computer program.

Images