Method and system for secure transfer of secrets between computing components

Abstract

The invention relates to trusted system upgrade and secret transfer in a secure computing environment. A computer-implemented method for securely transferring a secret from a source computing component to a target computing component is disclosed, wherein the source computing component and the target computing component are part of a secure computing environment. The method comprises, upon the source computing component receiving a signed attestation document from the target computing component, the source computing component verifying authenticity and content of the attestation document, and upon successful verification of authenticity and content, the source computing component transferring the secret to the target computing component. Thereby, the attestation document attests that the target computing component complies with an update control rule.

Description

Technical Field

[0001] This invention generally relates 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, wherein the source computing component and the target computing component are part of a secure computing environment. The invention also relates to an upgrade system for securely transferring secret keys from a source computing component to a target computing component, and a computer program product. Background Technology

[0002] Given the significant increase in hacker attacks on all types of computing systems and every enterprise, secure computing environments are becoming a critical tool for ensuring process support and data protection within companies. This involves any kind of computing, whether on mainframes, systems supporting open-source operating systems, personal devices, mobile devices, or IoT (Internet of Things) infrastructure. In this context, trusted execution environments play a key role in ensuring the proper functioning of applications or services as building blocks. Today, secure execution environments can have two main tasks: (i) protecting memory access outside of the application workload, and (ii) protecting application code from manipulation (and in some cases, also protecting associated data).

[0003] Existing trusted execution environments and secure execution technologies exhibit weaknesses, particularly during secure lifecycle migrations of applications and corresponding workloads. This aspect is especially critical if outdated applications or services are using encryption / decryption keys for data access.

[0004] Furthermore, moving trust controls from infrastructure providers and workload providers to data controllers and / or owners can also be problematic. In the case of container computing environments, it is often unclear which software containers can be trusted. Additionally, in classic trusted execution environments, workloads protected by confidential computing cannot be managed and orchestrated by a given infrastructure without compromising trust levels and data confidentiality. Moreover, in some cases, existing trusted execution environments may be vulnerable to system updates, including malicious or vulnerable software versions that do not conform to update and / or upgrade policies. Furthermore, infrastructure providers can access data by manipulating the software infrastructure system. However, this aspect may also need to be addressed by advanced trusted execution environments.

[0005] In this context, several documents have been published: for example, document US 2020 / 0021615A1 describes a container development system for an enterprise organization that publishes container images and requests container instances to perform authorization on each unique container instance. The controller can be programmed or configured to apply one or more authorization policies to determine whether a container instance should be authorized. Additionally, document US2017 / 0244787A1 describes a technique for hot-swapping and hot-scaling containers between cloud services. This method includes utilizing a cloud switch to store data indicating the association between a first container in a first private network and a second container in a second private network, the first container in the first private network and the second container in the second private network being coupled to the cloud switch to send and receive data packets via the cloud switch.

[0006] However, none of these documents address the aforementioned issues, specifically the scenario of secure access to updated data being part of a container instance. Therefore, a secure and trusted approach may be needed to address this scenario. Summary of the Invention

[0007] According to one aspect of the invention, a computer-implemented method is provided for securely transmitting 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 may include: after the source computing component receives a signed proof document from the target computing component, the source computing component may verify the authenticity and content of the proof document; and after successfully verifying the authenticity and content, the source computing component may transmit the secret to the target computing component. Thus, the proof document can prove that the target computing component complies with update control rules.

[0008] According to another aspect of the present invention, an upgrade system for securely transferring a secret key from a source computing component to a target computing component can be provided. The system includes: a processor and a memory communicatively coupled to the processor, wherein the memory stores program code portions that, when executed by the processor, enable the processor to: verify the authenticity and content of a signed proof document after the source computing component, controlled by the processor, receives it from the target computing component; and, upon successful verification of the authenticity and content, transfer the secret key to the target computing component. Thus, the proof document proves that the target computing component conforms to update control rules.

[0009] The proposed method for securely transferring secrets from a source computing component to a target computing component offers several advantages, technical effects, contributions, and / or improvements, where the source and target computing components are part of a secure computing environment:

[0010] Compared to known technologies, one of the problems addressed lies in the fact that secure life-cycle migration becomes a reality, particularly during application updates and corresponding workloads. This is of particular interest when data access can be made using encryption keys / secrets used for workload data. The concept proposed here ensures the secure transfer of encryption / decryption keys or any other secrets to the new workload after migration or update.

[0011] This also allows for the secure movement of trust from infrastructure providers (e.g., cloud providers) and workload providers (e.g., service-specific providers) to the data owner (i.e., the data controller). This ensures that workloads dynamically determine which other containers can be trusted. Workload startup (e.g., in the form of container instances) may only be possible after successful trust confirmation. Therefore, workloads protected by confidential computing can be managed and orchestrated by the infrastructure without compromising trust levels and data confidentiality. Thus, the solution proposed here can support trusted ecosystems for “scaling out” and trusted ripple update scenarios. Furthermore, it can prevent certain types of security attacks, such as malicious or outdated or vulnerable software version system update attempts. Such attacks can be addressed by verifying update policies using the concepts proposed here. Additionally, it can avoid negative impacts caused by infrastructure providers attempting to manipulate the underlying infrastructure software system.

[0012] The update control rules presented herein define the requirements and policies for updating applications (e.g., in the form of container instances), which can be executed in a trusted execution environment. These update control rules can be implemented whenever an existing application needs to be updated. If the update control rules cannot be met, the new component (i.e., a new application in the form of a container instance) will not be updated. However, if the update control rules can be met, the novel application / component will be deployed in the new version, and the novel application / component will be able to perform a favorable "secure switchover" between the old and new versions of the application.

[0013] Therefore, the update control component can be implemented as part of the application workload itself and executed within the same trusted execution scope to prevent any external manipulation. This allows for the verification of multiple requirements and policies that are typically freely definable.

[0014] This also protects investments and reduces the risk of supply chain attacks in cases where the workload provider itself may be compromised or the workload provider is the attacker, as updating management rules may block newer versions of computing components unless the data owner has checked and verified its security.

[0015] Additional embodiments of the inventive concept will now be described, which are applicable to the methods and systems described above.

[0016] According to an advantageous embodiment of the method, the update control rules can describe that the target computing component is part of a secure execution environment, the target computing component conforms to at least one predefined characteristic (in particular a set of characteristics), and / or the target computing component can be generated by the secure computing environment. It is understood that these mentioned update control rules may only represent a subset of potential update control rules that may span a broader set of conditions. The following... Figure 4 We will discuss this condition further in the context of [the relevant context].

[0017] According to another advantageous embodiment of the method, the predefined characteristics can define (i) a set of early source computing components from which they can be upgraded to the target computing component, and / or (ii) a set of build process characteristics that the target computing component should conform to. Thus, only the predefined upgrade paths can be allowed, while the proposed method does not support other (and is allowed) update paths. Furthermore, a set of controlled conditions can be established under which the target computing component (again, the application or software container instance or virtual machine) may have been built. This also ensures that the build process can be performed in a trusted computing environment.

[0018] According to a preferred embodiment of the method, the target computing component may be an updated version of the source computing component. Therefore, the target computing component can be newer than the source computing component. The target computing component may include some vulnerability fixes or additional functionalities.

[0019] According to an embodiment of interest in the method, both the target computing component and the source computing component can be executable software containers or virtual machines. Executable software containers can be components within a Docker computing environment. Thus, a container can be a standard software unit that packages code with all its dependencies, enabling applications to run quickly and reliably from one computing environment to another. A Docker container image is therefore a lightweight, standalone executable package that includes everything needed to run an application: application logic code, runtime, system tools, system libraries, and settings.

[0020] According to a useful embodiment of the method, both the target computing component and the source computing component may include an update control component for ensuring compliance with the update control rules. In the following figures, the update control component is shown as a policy API on the source and target computing component sides. These components may be responsible for establishing trust (in a computational sense) and transferring secrets from the source computing component to the target computing component.

[0021] According to another preferred embodiment, the method may further include: after successful verification and transmission of the secret to the target computing component, the target computing component takes over the operation and shuts down the source computing component. At this point, the source computing component is history, and all operations are performed by the target computing component. Data from the source computing component may also have been transmitted to the target computing component's storage device, and optionally, the source computing component may have been disconnected from its storage device.

[0022] According to another very useful embodiment, the method may further include: after the initialization of a 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, and new data storage associated with the first computing component may be generated. This ensures the standard process for initializing new computing components (i.e., each computing component).

[0023] According to other developed embodiments of the method, the update control component for ensuring compliance with the update control rules can reside in a third system, and specifically execute within that third system. This can be implemented outside of the source and target computing components. Alternatively, the update control component can also execute in its own secure computing environment, which can comply with its own security execution rules and regulations.

[0024] According to another advanced embodiment of the method, the update control rules (or multiple update control rules) can describe a list of one or more entities authorized to update via a security mechanism. This allows control over whether a quorum verification may be required to initiate and execute the update process from the source computing component to the target computing component. For example, a qualified number of operators may be required to confirm the upgrade from the source computing component to the target computing component. This can be based on a technical mechanism using software signing.

[0025] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable medium or a computer-readable medium, which provides program code used by or in conjunction with a computer or any instruction execution system. For the purposes of this specification, the computer-usable medium or computer-readable medium may be any apparatus that may contain components for storing, transmitting, propagating, or distributing a program used by or in conjunction with an instruction execution system, apparatus, or device. Attached Figure Description

[0026] It should be noted that embodiments of the present invention are described with reference to different subject matter. In particular, some embodiments are described with reference to method claims, while others are described with reference to apparatus claims. However, those skilled in the art will understand from the above and below description that, unless otherwise indicated, any combination of features related to different subject matter, in particular any combination of features of method claims and features of apparatus claims, is also considered to be disclosed in this document, except for any combination of features belonging to one type of subject matter.

[0027] The above and other aspects of the invention will be apparent from the examples of the embodiments described below, and the invention is not limited to these examples of embodiments, but is explained with reference to the examples of embodiments.

[0028] Preferred embodiments of the invention will be described by way of example only and with reference to the following figures:

[0029] Figure 1 A block diagram illustrating an embodiment of a computer implementation of a method for securely transferring secrets from a source computing component to a target computing component is shown, wherein the source computing component and the target computing component are part of a secure computing environment;

[0030] Figure 2 A block diagram illustrating an exemplary configuration of dependencies and connections between components that support the new concept is shown;

[0031] Figure 3 A communication diagram is shown for the steps involved in the initial startup of, for example, a container instance;

[0032] Figure 4 It shows in Figure 3 Another, more extended communication diagram of the process that has already been briefly outlined in the context;

[0033] Figure 5 A block diagram illustrating an embodiment of an upgrade system for securely transferring secret keys from a source computing component to a target computing component is shown; and

[0034] Figure 6 It shows including according to Figure 5 An example of a computing system. Detailed Implementation

[0035] In the context of this specification, the following conventions, terms and / or expressions may be used:

[0036] The term "securely transmitting secrets" can mean that secrets (specifically access codes or encryption / decryption keys) can be sent from a source to a target system without compromising the security of the transmission. This can be achieved by trusted components such as a trusted sender, a trusted receiver, a trusted transmission path, and / or a trusted computing environment.

[0037] The term "source compute component" can refer to a specific version of an application. Applications can also be implemented as part of a virtual machine or a Docker container instance.

[0038] The term "target compute component" can refer to another, similar, or identical application compared to the source compute component; however, the target compute component can have a higher version number or version, meaning it can be newer. Therefore, the target compute component can also be a software application, a virtual machine, or a Docker container.

[0039] The term "secure computing environment" can refer to computing components that interact with each other in a way that does not compromise security. This also applies to data stored in secure storage systems and other data security measures. Data can be encrypted with secure keys, and computing components can be activated only using secure keys or signatures.

[0040] The term "signed proof document" can essentially mean a binary string in which proof can be encoded. Furthermore, the string can be signed, implying encapsulation and software envelope, making it possible to prove the origin of the document / binary string.

[0041] The term "update control rule" can refer to one or more conditions that must be met in order to allow or enable version upgrades of an application, virtual machine, or software container instance.

[0042] The term "updated version" can refer to a newer implementation of an existing software artifact (such as an application, virtual machine, or Docker container instance).

[0043] The term "executable software container" can refer to a directly executable software artifact, such as a Docker container instance. Docker is thus 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; they can communicate with each other through well-defined channels.

[0044] The accompanying drawings are described below in detail. All illustrations in the drawings are illustrative. First, a block diagram of an embodiment of the method of the present invention for securely transferring secrets from a source computing component to a target computing component is given, wherein the source computing component and the target computing component are part of a secure computing environment. Then, other embodiments and embodiments of an upgrade system for securely transferring secrets from a source computing component to a target computing component will be described.

[0045] Figure 1 A block diagram of a preferred embodiment of a computer-implemented method 100 for securely transferring a secret from a source computing component (e.g., an older container or application version) to a target computing component (e.g., another container or a new, updated application) is shown, wherein the source computing component and the target computing component are part of a secure computing environment. The method includes: after the source computing component receives a signed proof document from the target computing component, the source computing component verifies 102 the authenticity and content of the proof document; and after successful verification of authenticity and content, the source computing component transmits 104 a secret (e.g., an encryption / decryption key or another cipher) to the target computing component. Thus, the proof document proves that the target computing component complies with update control rules, particularly multiple rules (i.e., multiple update control rules).

[0046] Figure 2 A block diagram illustrating an exemplary configuration 200 that demonstrates the dependencies and connections between components supporting the new concept is shown. Upon requesting the deployment of a new application container 208, deployment driver 214 initiates the deployment process. Deployment driver 214 triggers the deployment of the application 216 by providing information such as the application version to be run and / or the application configuration. For this purpose, an external trust provider may be present, and the required tokens or signatures 220 are provided to deployment driver 214 from trust provider 218.

[0047] General functionality will be migrated to the new / updated application container 208. The existing application container 204 can maintain a runtime secret 206, for example, to access the existing application container 200 to obtain data (not shown). The deployment interface 210 can create 212 a new application container 208 and can also facilitate the generation of new protected data storage, i.e., encrypted data storage. Therefore, the deployment interface 210 can also facilitate the generation of new runtime secrets (not shown). However, in any case, the existing application container 204 and the new application container 208 can have an update control component as part of it (in... Figure 1 Represented as Policy APIs 224 and 226, the update control component negotiates trust and may optionally transfer the required keys. It should also be noted that the existing application container 204 will perform its operations until a takeover is triggered via Policy APIs 224 and 226. Because the security-related units (i.e., deployment interface 210, the existing application / application container 204, the new application container 208, and Policy APIs 224 and 226) all execute within 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, because anything potentially vulnerable can execute within the same secure execution environment 202, the transfer of secret runtime keys will no longer be an issue. However, it is not required that the source computation component (e.g., source computation component 204) and the target computation component (e.g., the new application container 208) execute within the same secure execution environment 202.

[0048] Figure 3 A communication diagram 300 illustrates the steps for initializing a software artifact using the concepts presented herein. The active components are shown in the upper region of the diagram: deployment driver 302 (compare to deployment driver 214). Figure 2 ), Deployment interface 304 (compare with deployment interface 210, Figure 2 Application instance 306 (compared to the newer application container 208) Figure 2 ) and encrypted data 308.

[0049] The following steps will be performed:

[0050] 1. In the event of a deployment request, deployment driver 302 will begin the initialization process.

[0051] 2. Deployment driver 302 will trigger the initialization of application 310 by providing the following information: bearer token, application version of the current application instance to be run, application configuration, etc.

[0052] 3. The new application instance 306 will be launched (launched by deployment interface 304 and indicated by reference numeral 312 in the attached diagram).

[0053] 4. The new application 306 generates a secret (S) based on a function.

[0054] 5. The new application instance 306 is now starting its operation.

[0055] Specifically, the new application (or application container or container instance) will also generate a new data encryption key (314) and use the newly generated encryption key to create encrypted data (316). The new application will then be operational and await full takeover (318).

[0056] Figure 4 The communication diagram 400 illustrates the update process. (Except in...) Figure 3 In addition to the activity units described in the context, the new units are the (external) trusted provider 402 and the current application interface 404 (i.e., the policy API of the current application).

[0057] Optional deployment authorization request 406 can optionally be made on-site by returning a 408 token from the trust provider 402 to the deployment driver 302. Furthermore, in Figure 4 In this process, 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 needs to provide evidence 412 regarding the takeover policy (updating the control policy, see above), and the data encryption key must be passed 14 from the current application to the new application instance 306 (via its policy API) via the current application interface 404 (i.e., the policy API).

[0058] in addition, Figure 4 The diagram illustrates the disconnection 416 from the current application interface 404 to the encrypted data 308, the closure 418 of the current application interface 404, and the subsequent connection 420 from the new application instance 306 to the encrypted data 308. Finally, reference numeral 422 indicates the takeover operation of the new application instance 306.

[0059] As already mentioned, a wide variety of policies can be implemented via the application's policy API (i.e., updating the control component). Some examples are listed below:

[0060] Updates to sensitive sample applications require sign-off by two of the three quorum signers. This is because updates may introduce behavioral changes to the application that require review and sign-off. For example, an application might define the following update control rules:

[0061] • The set of authorized “update approvers” and their signing keys.

[0062] • Obtaining a bearer token from a central authority requires approval from a quorum of 2 out of 3.

[0063] Other requirements may also be:

[0064] The update requires a set of certificates (proven assertions) for the new application version.

[0065] • Updates require specific versions of prerequisite components (e.g., other applications that the sample application interacts with). This may potentially require a transitive update.

[0066] Updates may also require a specific execution environment. This also needs to be asserted.

[0067] Update control rules can be securely stored, for example, in a repository within a secure computing environment.

[0068] In any case, an update control policy or rule (i.e., trust negation) may be implemented as part of the application (e.g., with secure code), created during the build process (e.g., based on a policy captured during the build), and / or (iii) created by an authorized user (during deployment or runtime).

[0069] Other examples that typically help update strategies, update control rules, or strategies for newly proposed concepts:

[0070] • Authentication via an SSO (Single Sign-On) provider (e.g., OAuth, SAML, JWT):

[0071] This strategy verifies the existence of authorization from an external trust provider. Using this strategy, application updates can be performed only if authorized by the required stakeholders or automated systems.

[0072] Version compatibility:

[0073] This strategy ensures compatibility with application updates. For example, each application strategy includes the application version and a list of previous application versions that can be updated.

[0074] ·Strategy:

[0075] This ensures that the build steps for the new application instance have been successfully executed. It also ensures that all build artifacts required by the application policy exist for the new instance.

[0076] • A quorum of operators (signatures) required for the update:

[0077] This strategy verifies whether a quorum of signatures or authorizations has been provided by stakeholders. Therefore, for example, at least two administrators might need to be rolled out.

[0078] • Update only to newer versions: This policy ensures that switching to older versions is not required. The actual allowed age or version can be defined by the application policy.

[0079] • Validate strategies for updated "external" requirements:

[0080] The policy can only be updated when, for example, keys in an external keystore are rotated, data is backed up, ACL lists are audited, or automated (scripted) tasks are successfully executed.

[0081] • Strategies can reference and call the interfaces of external components to validate requirements.

[0082] • What are the policies regarding the (runtime) environment?

[0083] This strategy can verify whether the execution environment of a new application instance meets specific rules. This can include secure enclaves operating in specific availability zones, data centers, or regions. enc lav e ).

[0084] Figure 5 A block diagram is shown of an 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 a portion of program code that, when executed, enables the processor 502 (specifically, the source computing component 506) to receive a signed proof document from the target computing component 508, and, upon receipt, for verification of the authenticity and content of the proof document, specifically by a verification module 510, which may also be a policy API.

[0085] Furthermore, this allows the processor 602 to transmit the secret to the target computing component 508 via the source computing component 506 after successfully verifying the authenticity and content. Thus, the proof document can demonstrate that the target computing component conforms to the update control rules.

[0086] It should also be mentioned that all functional units, modules, and function blocks (in particular processor 502, memory 504, source computing component 506, target computing component 508, and verification module 510) can be communicatively coupled to each other in a selected 1:1 manner for signal or message exchange. Alternatively, functional units, modules, and function blocks can be linked to the system's internal bus system 512 for selective signal or message exchange.

[0087] Embodiments of the present invention can be implemented with virtually any type of computer, regardless of whether the platform is suitable for storing and / or executing program code. Figure 6 As an example, a computing system 600 suitable for executing program code related to the proposed method is shown.

[0088] Computer system 600 is merely one example of a suitable computer system and is not intended to impose any limitation on the scope or functionality of the embodiments of the invention described herein, regardless of whether computer system 600 can be implemented and / or perform any of the functions set forth above. In computer system 600, there are components that can operate with a wide variety of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 600 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the aforementioned systems or devices. Computer system / server 600 can be described in the general context of computer system executable instructions (such as program modules executed by computer system 600). Typically, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system / server 600 can be implemented in a distributed cloud computing environment, where tasks are executed by remote processing devices linked via a communication network. In this environment, program modules can reside on local and remote computer system storage media (including memory storage devices).

[0089] As shown in the figure, the computer system / server 600 is illustrated as a general-purpose computing device. Components of the computer system / server 600 may include, but are not limited to, one or more processors or processing units 602, system memory 604, and a bus 606 that couples various system components, including system memory 604, to processor 602. Bus 606 represents one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of various bus architectures. By way of example and not limitation, these architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses. The computer system / server 600 typically includes various computer system readable media. Such media can be any available media accessible by the computer system / server 600, and it includes both volatile and non-volatile media, removable and non-removable media.

[0090] System memory 604 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 608 and / or cache memory 610. Computer system / server 600 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 612 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and generally referred to as "hard disk drives"). Although not shown, disk drives for reading from and writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media may be provided. In this case, each may be connected to bus 606 via one or more data media interfaces. As will be further 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 embodiments of the present invention.

[0091] A program / utility having a set (at least one) of program modules 616, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 604 as an example and not as a limitation. Each or some combination of the operating system, one or more applications, other program modules, and program data may include an implementation of a networking environment. Program modules 616 typically perform the functions and / or methods as described in the embodiments of the invention herein.

[0092] The computer system / server 600 can also communicate with one or more external devices 618, such as a keyboard, pointing device, display 620, etc.; one or more devices that enable a user to interact with the computer system / server 600; and / or any device that enables the computer system / server 600 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). This communication can occur via input / output (I / O) interface 614. Furthermore, the computer system / server 600 can communicate with one or more networks via network adapter 622, such as local area networks (LANs), general area networks (WANs), and / or public networks (e.g., the Internet). As depicted, network adapter 622 can communicate with other components of the computer system / server 600 via bus 606. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 600. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0093] Additionally, an upgrade system 500 for securely transmitting secrets from a source computing component to a target computing component can be attached to a bus system 606.

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

[0095] This invention can be embodied as a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0096] The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system used for propagation. Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disks, random access memory (RAM), read-only memory (ROM), hard disks, and optical discs. Current examples of optical discs include optical disc read-only memory (CD-ROM), optical disc read / write (CD R / W), DVDs, and Blu-ray discs.

[0097] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0098] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0099] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as C or similar programming languages). The computer-readable program instructions may be executed entirely 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 case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions to personalize the electronic circuits by utilizing state information from the computer-readable program instructions.

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

[0101] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0102] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0103] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a non-consecutive order. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block illustrated in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0104] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that the terms “comprising” and / or “including” as used in this specification specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0105] The equivalent substitutions for the corresponding structures, materials, operations, and all functionally defined means or steps in the following claims are intended to include any structure, material, or operation used to perform the function in combination with other elements specifically pointed out in the claims. The description of the invention given is for illustrative and descriptive purposes only and is not exhaustive, nor is it intended to limit the invention to the forms set forth. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The examples were chosen and described in order to best explain the principles and practical application of the invention, enabling those skilled in the art to understand that the invention can be implemented with various modifications to suit a particular purpose.

[0106] Some embodiments of the inventive concept disclosed herein may be described by the following terms:

[0107] 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:

[0108] -After the source computing component receives the signed proof document from the target computing component,

[0109] - The source computing component verifies the authenticity and content of the documentation, and

[0110] -After successfully verifying the authenticity and content

[0111] - The source computing component will secretly transmit data to the target computing component.

[0112] The documentation demonstrates that the target computing component conforms to the update control rules.

[0113] 2. The method described in Clause 1, wherein the update control rule is described as follows:

[0114] -The target computing component is part of the secure execution environment.

[0115] - The target computing component conforms to at least one predefined characteristic, and / or

[0116] - The target computing component is generated by a secure computing environment.

[0117] 3. The method described according to Clause 1 or 2, wherein the predefined characteristic is defined as follows:

[0118] -A set of early source computing components that can be upgraded to the target computing component, and

[0119] - A set of build process characteristics that the target computing component conforms to.

[0120] 4. The method according to any one of the foregoing clauses, wherein the target computing component is an updated version of the source computing component.

[0121] 5. The method according to any one of the preceding clauses, wherein both the target computing component and the source computing component are executable software containers or virtual machines.

[0122] 6. The method according to any one of the foregoing clauses, wherein both the target computing component and the source computing component include an update control component for ensuring compliance with update control rules.

[0123] 7. The method according to any one of the foregoing clauses further includes:

[0124] -After successful verification and transmission of the secret to the target computing component

[0125] - The operation is taken over by the target computing component, and

[0126] -Disable the source computing component.

[0127] 8. The method according to any one of the foregoing clauses further includes:

[0128] -After the initialization of the first computing component,

[0129] -A new encryption key is created by the first computing component, and

[0130] - Generate new data storage associated with the first computing component.

[0131] 9. The method according to any one of the foregoing clauses, wherein the update control component for ensuring compliance with update control rules is located in a third system.

[0132] 10. The method according to any one of the preceding clauses, wherein the update control rule describes a list of one or more entities authorized to be updated through a security mechanism.

[0133] 11. An upgrade system for securely transferring a secret key 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 upgrade system comprising:

[0134] - The processor is communicatively coupled to the processor's memory, where the memory stores program code that, when executed by the processor, enables the processor to:

[0135] -After the source computing component, controlled by the processor, receives the signed proof document from the target computing component,

[0136] - The source computing component, controlled by the processor, verifies the authenticity and content of the proof documents; and

[0137] -After successfully verifying the authenticity and content

[0138] - The source computing component, controlled by the processor, secretly transmits data to the target computing component, where a certificate document proves that the target computing component conforms to the update control rules.

[0139] 12. The upgrade system according to Clause 11, wherein the update control rules are described as follows:

[0140] -The target computing component is part of the secure execution environment.

[0141] - The target computing component conforms to at least one predefined characteristic, and / or

[0142] - The target computing component is generated by a secure computing environment.

[0143] 13. The upgrade system as described in Clause 11 or 12, wherein the predefined characteristics are defined as follows:

[0144] -A set of early source computing components that can be upgraded to the target computing component, and

[0145] - A set of build process characteristics that the target computing component conforms to.

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

[0147] 15. An upgrade system pursuant to any of Clauses 11 to 14, wherein both the target computing component and the source computing component are executable software containers or virtual machines.

[0148] 16. An upgrade system pursuant to any of Clauses 11 to 15, wherein both the target computing component and the source computing component include an update control component for ensuring compliance with update control rules.

[0149] 17. An upgrade system pursuant to any one of clauses 11 to 16, wherein the processor is further enabled to:

[0150] -After successful verification and transmission of the secret to the target computing component

[0151] - The target computing component controlled by the processor takes over the operation, and

[0152] - Shut down the source computing components controlled by the processor.

[0153] 18. The upgrade system according to any one of clauses 11 to 17 further includes:

[0154] -After the initialization of the first computing component,

[0155] -A new encryption key is created by the first computing component, and

[0156] - Generate new data storage associated with the first computing component.

[0157] 19. An upgrade system pursuant to any of Clauses 11 to 18, wherein the update control rules describe a list of one or more entities authorized to be updated through a security mechanism.

[0158] 20. A computer program product for securely transferring a secret key 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 computer program product including a computer-readable storage medium storing program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to:

[0159] -After the source computing component, controlled by the processor, receives the signed proof document from the target computing component,

[0160] - The source computing components controlled by the processor verify the authenticity and content of the proof documents, and

[0161] -After successfully verifying the authenticity and content

[0162] - The source computing component, controlled by the processor, secretly transmits data to the target computing component, where a certificate document proves that the target computing component conforms to the update control rules.

Claims

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, and the method includes: After the source computing component receives the signed proof document from the target computing component, the source computing component verifies the authenticity and content of the proof document; and After successfully verifying the authenticity and content, the source computing component transmits the secret to the target computing component, wherein the proof document proves that the target computing component conforms to the update control rules. The update control rules described therein state that the target computing component is part of a secure execution environment, the target computing component conforms to at least one predefined characteristic, and the target computing component is generated by the secure computing environment. The predefined characteristics are defined as: a set of early source computing components from which they can be upgraded to the target computing component, and a set of build process characteristics that the target computing component conforms to.

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

3. The method according to claim 1, wherein, Both the target computing component and the source computing component are executable software containers or virtual machines.

4. The method according to claim 1, wherein, Both the target computing component and the source computing component include an update control component to ensure compliance with the update control rules.

5. The method according to claim 1, further comprising: After successful verification and transmission of the secret to the target computing component, the target computing component takes over the operation and shuts down the source computing component.

6. The method according to claim 1, further comprising: After the first computing component is initialized, a new encryption key is created by the first computing component, and new data storage associated with the first computing component is generated.

7. The method according to claim 1, wherein, The update control component used to ensure compliance with the update control rules is located in a third system.

8. The method according to claim 1, wherein, The update control rules describe a list of one or more entities that are authorized to be updated through a security mechanism.

9. An upgrade system for securely transferring a secret key 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, and the upgrade system includes: The processor is communicatively coupled to a memory, wherein the memory stores a portion of program code that, when executed by the processor, enables the processor to: After the source computing component, controlled by the processor, receives the signed proof document from the target computing component, the source computing component, controlled by the processor, verifies the authenticity and content of the proof document; and After successfully verifying the authenticity and content, the source computing component controlled by the processor transmits the secret to the target computing component, wherein the proof document proves that the target computing component conforms to the update control rules. The update control rules described therein state that the target computing component is part of a secure execution environment, the target computing component conforms to at least one predefined characteristic, and the target computing component is generated by the secure computing environment. The predefined characteristics are defined as: a set of early source computing components from which they can be upgraded to the target computing component, and a set of build process characteristics that the target computing component conforms to.

10. The upgrade system according to claim 9, wherein, The target computing component is an updated version of the source computing component.

11. The upgrade system according to claim 9, wherein, Both the target computing component and the source computing component are executable software containers or virtual machines.

12. The upgrade system according to claim 9, wherein, Both the target computing component and the source computing component include an update control component to ensure compliance with the update control rules.

13. The upgrade system according to claim 9, wherein, The processor can also: After successful verification and transmission of the secret to the target computing component, the target computing component controlled by the processor takes over the operation and shuts down the source computing component controlled by the processor.

14. The upgrade system according to claim 9, further comprising: After the first computing component is initialized, a new encryption key is created by the first computing component, and new data storage associated with the first computing component is generated.

15. The upgrade system according to claim 9, wherein, The update control rules describe a list of one or more entities that are authorized to be updated through a security mechanism.

16. A computer program product for securely transmitting a secret key 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, and the computer program product includes a computer-readable storage medium storing program instructions that can be executed by one or more computing systems or controllers to cause the one or more computing systems to perform the steps of the method according to any one of claims 1-8.

Images