Updating the secure guest metadata for a specific guest instance

Abstract

A computer-implemented method is disclosed for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance, the method comprising: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying the request structure by the trusted firmware and, if successful, modifying the metadata as specified by the request structure; retrieving, by the secure guest instance, a secret object derived from the retrieveable secret from the trusted firmware; and personalizing, by the secure guest instance, using the retrieved secret object.

Description

[Technical Field]

[0001] The present invention relates generally to a method for personalizing a secure guest instance from a generic boot image, and more particularly to a computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance. The present invention further relates to an associated security system and computer program product for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance. [Background technology]

[0002] Data and communication channel security remains one of the highest priorities for managing corporate IT (information technology). This is necessary not only due to government regulations (e.g., GDPR, EU General Data Protection Regulation) but also due to the loss of credibility for companies that cannot always reliably protect customer data (and avoid lost revenue and profits) if customer data records are compromised. In addition, fines may have to be paid depending on the country of the data breach. It turns out that data protection and the provisioning of secure computing platforms are not simply a software issue but also involve hardware modules. This may not yet be the natural environment for mass-market CPU chips used in microcontrollers, personal computers, mobile phones, or home automation devices. However, for highly trusted enterprise-class computing environments, such as those used in the financial, insurance, or government industries, it is essential to be able to demonstrate, from a technical perspective, that there is a very high probability that a data breach will be prevented. This may require several additional high-tech components and support processes. However, the associated success in terms of data security is worth the additional effort.

[0003] These ideas are also applicable to trusted and / or confidential computing environments where cryptographic keys used by virtual machines (also denoted as guests) or software containers running on / within a hypervisor cannot practically be accessed by the hypervisor or associated software management and configuration programs. Nevertheless, even in such computing environments, violations of fundamental security rules, such as disclosure of private keys or use of private keys for secure guest images via the hypervisor, remain possible. This may be possible even in environments where hardware security modules (HSMs) have been in use for a significant amount of time.

[0004] Several disclosures already exist that fit the context of a computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance. Document US2020 / 0076607A1 describes how secrets are securely maintained on a virtual computer system by configuring a dedicated virtual machine to manage and maintain sequents on behalf of an application. When an application requests access to a secret, the control domain, in cooperation with the dedicated virtual machine, validates that the application is authorized to make the request and that the application has not been compromised prior to the request.

[0005] A problem in such an environment can be identified in the context of an image on a secure guest that is to be executed on a hypervisor. For example, a user belonging to a generic secure guest wants to modify the metadata of the secure guest, where the metadata is accessible only by trusted firmware and is associated with a specific secure guest instance owned by the user. In such a situation, it should not be possible to steal data containing secrets, use the stolen data, and add secrets to the attacker's secure guest instance; the attacker should not be able to compile data containing secrets known to the attacker that can be added to the metadata of a vulnerable secure guest. Technologies such as openCryptoki or CCA (Common Cryptographic Architecture) cannot yet succinctly meet this requirement.

[0006] Therefore, there may be a need to provide a secure method between the virtual machine and the firmware so that the virtual machine and its metadata cannot be compromised by an attacker in the manner just described. Summary of the Invention

[0007] According to one aspect of the present invention, a computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance may be provided. The method may include passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance, and verifying the request structure by the trusted firmware and, if successful, modifying the metadata as specified by the request structure. The method may further include further retrieving, by the secure guest instance, a secret object derived from the retrieveable secret from the trusted firmware, and personalizing, by the secure guest instance, using the retrieved secret object.

[0008] According to another aspect of the present invention, a security system for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance may be provided. The system may include one or more processors and a memory operatively coupled to the one or more processors, the memory storing program code portions that, when executed by the one or more processors, enable the one or more processors to pass a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, establish at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance, and verify, by the trusted firmware, the request structure and, if successful, modify the metadata as specified by the request structure.

[0009] Additionally, the one or more processors retrieve, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and The secure guest instance may enable the secure guest instance to be personalized using the retrieved secret object.

[0010] The proposed computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance may provide multiple advantages, technical effects, contributions, and / or improvements.

[0011] The proposed concept, and in particular the subject matter of the first claim, may have the potential to increase the security level in computer systems: in particular, the execution of secure guest systems may be made even more secure.

[0012] For example, the proposed concept may define a technical barrier to the use or misuse of metadata for a particular secure guest instance by another secure guest instance or any other process on the computer system.

[0013] Additionally, the proposed concept may also prohibit a secure guest from using another secure guest's request structure (e.g., to modify metadata in firmware) to modify metadata maintained by the computer system's firmware in an unauthorized manner. Thus, any interoperability between secure guest instances running on a hypervisor above trusted firmware may be prohibited by design. The secure guest personalization proposed here may aid in this level of security.

[0014] It may also improve the security level of the underlying confidential computing environment in that similarly stolen keys or secrets cannot be used by unauthorized secure guest instances.

[0015] The proposed concept may also enable secure personalization of a secure generic guest image provided by a software or appliance vendor, such that the secure guest image does not need to contain any vendor secrets.

[0016] Furthermore, the proposed concept has the advantage that the secrets used for personalization do not ever need to be stored as plaintext values ​​in the memory of the secure guest.

[0017] Another advantage may be that the guest tenant may change the behavior of the trusted firmware when controlling the secure guest by changing controls in the secure guest's metadata, for example, being able to switch off the possibility to dump a secure guest that started out as dumpable.

[0018] It is possible to submit multiple requests that change metadata (including adding secrets) and force all the constructed requests to form the same subject.

[0019] In the following, additional embodiments of the inventive concepts (applicable to methods and systems) will be described.

[0020] According to a preferred embodiment of the method, each request structure may be integrity protected such that the integrity of the request structure may be verified by (and in particular only by) trusted firmware. Therefore, an integrity check may be applied to the integrity of the request structure itself and its applicability to a particular secure guest image. Calculation of a cryptographic hash, a message authentication code, or a digital signature may serve to verify the integrity.

[0021] According to an advantageous embodiment of the method, a request structure may include image measurements of the secure guest passing said request structure, and the trusted firmware may reject the passed or submitted request structure (in particular passed or sent from the secure guest to the trusted firmware) if the measurements of the boot image of the secure guest do not match the image measurements. As an example, a measurement may be the size of a generic boot image in bytes. Other measurements may also be possible, in particular cryptographically secure measurements (hashes, MACs, digital signatures).

[0022] According to an acceptable embodiment of the method, the request structure may include a universally unique identifier (UUID) of the secure guest, and the trusted firmware may reject the request structure if the UUID of the secure guest passing the request structure does not match the UUID in the request structure. Due to the nature of UUIDs, security mechanisms may offer good protection against unauthorized access.

[0023] According to a useful embodiment of the method, the request structure may include encrypted data that is only decryptable by trusted firmware. Such data may include encryption keys or other vulnerable data that is to be protected against unauthorized access.

[0024] According to an interesting embodiment of the method, the encrypted data of the request structure may include an extended secret, and the trusted firmware may reject any request structure received after the first received request structure whose extended secret does not match the extended secret of the first received request structure. The protection method may add a timestamp or sequence number as an additional security factor to ensure integrity across different requests over time.

[0025] According to an acceptable embodiment of the method, the data of the request structure may be encrypted, and the secure guest's modification of the metadata may comprise adding a portion of the encrypted data to the metadata as the secret. In this way, the secure guest may add an encrypted data value to metadata maintained by trusted firmware, for example for later use.

[0026] According to an advanced embodiment of the method, the trusted firmware may provide at least one cryptographic function that operates on protected keys, and the secret object may be a protected key that may only be valid for use by the secure guest as an argument to one of the cryptographic functions. An example of a protected key may be a Control Program Assist for Cryptographic Functions (CPACF) protected key of the IBM Z platform.

[0027] According to a further embodiment of the method, the secret included in the request structure to be added to the metadata of a secure guest instance may be marked as retrieveable, such that the trusted firmware may return a secret object in response to a retrieveable secret request issued by a secure guest only if the secret is marked as retrieveable. This may be considered a second level of metadata whereby certain metadata (e.g., secrets) of a secure guest instance may be tagged so that their method of use may be predefined.

[0028] According to a further advantageous embodiment of the method, in the request structure, each retrievable secret may be associated with a secret reference, and retrieving the secret object associated with the secret reference from the trusted firmware may be fetched using a retrieval interface of the trusted firmware that takes the secret reference as input. This may represent one way of accessing specific data maintained by trusted firmware from the perspective of a secure guest instance. Other access methods may also be acceptable.

[0029] According to another improved embodiment of the method, the request structure may include a description of how to modify the metadata of the secure guest. Such kind of data may be considered as second level metadata. However, this technique may allow controlling the behavior of the secure guest instance over time, for example by limiting the use of additional metadata.

[0030] According to one interesting embodiment of the method, the metadata may include controls that determine the actions that can be performed by the secure guest. Some examples of such actions may include allowing a core dump once the secure guest image execution may crash or defining access to certain devices or excluding access to certain other devices. In this way, fine-grained control over behavioral options for the secure guest image may be defined.

[0031] According to another interesting embodiment of the method, instead of the secure guest submitting the request structure, the request structure may be submitted to the firmware to modify the metadata of a created but not yet started secure guest instance. Thus, certain master metadata for multiple instances of the secure guest may be predefined, which may allow for a reduction in the time and effort of the operating personnel.

[0032] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium providing 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, propagating or transporting a program for use by or in connection with an instruction execution system, apparatus, or device. [Brief explanation of the drawings]

[0033] 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, a person skilled in the art will infer from the above and following description that, unless otherwise specified, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, in particular between features of method-type claims and features of apparatus-type claims, is considered to be disclosed within this document.

[0034] The above-defined aspects and further aspects of the invention will be apparent from and will be explained with reference to the example embodiments described hereinafter, to which the invention is not limited.

[0035] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings:

[0036] [Figure 1] 1 is a flowchart of one embodiment of a computer-implemented method of the present invention for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance.

[0037] [Figure 2] FIG. 1 is a block diagram of components of a potential security attack scenario.

[0038] [Figure 3] FIG. 1 is a block diagram of one embodiment including components useful for the concepts proposed herein.

[0039] [Figure 4] 1 is a flowchart of a more implementation-like sequence of activities for the concepts proposed herein.

[0040] [Figure 5] FIG. 10 illustrates an embodiment of a get-secret-request structure according to one embodiment.

[0041] [Figure 6] FIG. 1 is a block diagram of one embodiment of a security system of the present invention for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance.

[0042] [Figure 7] FIG. 7 illustrates an embodiment of a computing system including the system according to FIG. 6. DETAILED DESCRIPTION OF THE INVENTION

[0043] In the context of this description, the following technical conventions, terms and / or expressions may be used.

[0044] The term "secure guest" may refer to a virtual machine or software container containing executable program code in a secure computing environment protected by a trusted execution environment so that untrusted components of the computer system cannot observe any state (memory or registers) of the running secure guest. It may be, for example, a generic guest image that may also be provided by a third party, e.g., a software house. Typical untrusted components are software hypervisors, hardware management consoles, and other guests.

[0045] The term "generic boot image" may refer to an image of a virtual machine or executable software container (e.g., in the sense of a Docker container) that may be provided by a party that does not use the boot image itself. For example, a development team at a company or software house may provide a boot image for general use, e.g., after download from a software repository. That is, each user may download the same generic boot image, which may be personalized during or after instantiation of the generic boot image.

[0046] The term "metadata" (in the traditional sense, referring to information about data) may here particularly refer to data required to start a virtual machine. In confidential computing environments, such information may be used by trusted firmware to start a secure virtual machine and may store, for example, an integrity measure of the secure guest image or a key needed to decrypt the secure guest image. These metadata may include, for example, required resources, required interfaces, required performance, and (in some cases) also which security measures are appropriate. The denomination of metadata (e.g., in terms of required constraint information, but more specifically, in terms of secret and secret name pairs) to be used by trusted firmware represents one of the foundations of the proposed concept.

[0047] The term "personalization" here may indicate that a generic boot image may be modified in such a way that it may lose its status as generic, i.e., it may become a specialized or even unique executable image, for example, by adding (TLS / ssh) signing keys and / or (volume) encryption / decryption keys, restricting its functionality by restricting it to special users or specific hardware (e.g., by setting a password), or the like.

[0048] The term "trusted firmware" (trusted FW or TFW) may refer to a component deeply embedded in the hardware of a computing (mainframe) system that cannot be accessed by any other user-controlled software. Trusted firmware (in the broadest sense) may have a predefined and highly secured application programming interface to protect the functionality of the trusted firmware. Trusted FW should also be considered a deeply integrated component of the computer system instead of a service component. Communication channels to and from trusted firmware are typically cryptographically protected.

[0049] The term "request structure" may refer to a data structure that includes data elements (particularly encrypted data elements) to be sent by a secure guest instance to trusted firmware of a computer system. The request structure may include, for example, new data elements to be added to metadata maintained by the trusted firmware for a particular secure guest.

[0050] The term "modify metadata" may indicate that new metadata may be added to existing metadata for a particular secure guest image, or that existing metadata may be modified. Each request may include instructions on how to modify the metadata.

[0051] The term "retrievable secret" may refer to a data item that may be stored in metadata belonging to a secure guest image. Often, this data item may be associated with some kind of reference (index or name). This data item may be added to the metadata by a request structure submitted (or passed) by the guest to the trusted firmware. A retrievable secret may be retrieved (i.e., loaded into the secure guest) as a result of the secure guest issuing a function call to the trusted firmware to retrieve a secret that may be referenced by a reference to the secret. The retrieved secret may be in a format that does not disclose the plaintext value of the secret (e.g., as an IBM Z CPACF protected key).

[0052] The term "private object" may refer to any data item in the sense that it may only be made available to predetermined entities.

[0053] The term "integrity protected" may indicate that it is possible to verify the validity of a data structure of a predefined format, whereby data contained in the data structure itself can be used to verify the validity of the complete data structure. For this purpose, measurements (e.g., total byte count, cryptographic hash, message authentication code, or signature of the data structure (e.g., a virtual machine boot image)) or the UUID of the data structure may be used.

[0054] The term "image measurements" may refer to the measurements mentioned in the immediately preceding paragraph.

[0055] The term "universal unique identifier" (UUID) may refer to a well-known 128-bit label that uniquely identifies a resource in a computer system.

[0056] The term "encrypted data" may refer to data that is not available in plain text and that has been altered using a predefined key. Encrypted data can be made readable in plain text again after a decryption process.

[0057] The term "extended secret" herein may refer to a data item selected (e.g., randomly) by a user or software process. The extended secret may be part of each request structure passed from a secure guest instance to the firmware of a computer system (in other words, submitted by the secure guest instance).

[0058] The term "integrity check" may refer to ensuring that a component (especially the request structure) is consistent within itself. For this purpose, a hash comparison, a digital signature, or a message authentication code (MAC) may typically be used.

[0059] In the following, a detailed description of the figures is provided. All instructions in the figures are schematic. First, a block diagram of one embodiment of the inventive computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance is provided. Afterwards, further embodiments and embodiments of a security system for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance are described.

[0060] 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for personalizing a secure guest instance from a generic boot image (e.g., provided by a third party such as a software house) using trusted firmware that maintains metadata for the secure guest instance. The method 100 comprises passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance and establishing 102 at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance, and verifying 104, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure. The verification thereby includes an integrity check of the request structure.

[0061] Additionally, the method 100 includes retrieving 106, by the secure guest instance, upon request, a secret object derived from the retrievable secret from the trusted firmware. The requested secret may be extracted or derived from metadata of the secure guest instance. Furthermore, the method 100 includes 108, by the secure guest instance, personalizing the secure guest instance using the retrieved secret object.

[0062] 2 shows a block diagram 200 of components of a potential security attack scenario. A computer system 202 includes trusted firmware 204 on which a hypervisor 210 may operate to run one or more virtual machines, e.g., secure virtual guest-1 212 and secure virtual guest-2 218. Secure virtual guest-1 212 can access its metadata (MD) 206 (e.g., via request structure 214, with or without the support of hypervisor 210). This represents authorized access 216. However, the same request structure 214, potentially with the same key, should not allow secure virtual guest-2 218 to access other metadata, e.g., secure guest-2's metadata 208. This represents an access threat 220, which must be firmly prohibited.

[0063] Additionally, accessing Secure Guest-1's metadata 206 using another request structure with another key 226 should also be prohibited (not allowed (224)) because this would also constitute unauthorized access 224.

[0064] 3 shows a block diagram of one embodiment 300 including components useful for the concepts proposed herein. This diagram shows the same computer system 202, trusted firmware 204, secure guest metadata 206, hypervisor 210, and secure guest 212 as FIG. 2. Note that the secure guest is thereby a running secure guest 212, which may have been created from a boot image 314 by instantiation 316 to establish a running secure guest 212 controlled by hypervisor 210.

[0065] Additionally, note that request structures 304 and 310 represent request structures at different times. The first request structure 304 can include an extended key 306 and another protected key 308 that is to be integrated into the metadata 206 of secure guest-1.

[0066] In the case where another request structure 310 at a later point in time is passed over by the executing secure guest 312 to the metadata 206 of the executing secure guest 212, the request will only be accepted by the trusted firmware 204 if the extended key 306 is identical when compared to the extended key 306 of the first request structure 304. This general approach may be extended to each request structure that is passed or sent to the secure guest metadata 206.

[0067] 4 shows a flowchart 400 of a more implementation-like sequence of activities for the concepts proposed herein. In one of the initial steps 402, a user of a secure guest learns the UUID of the secure guest instance, selects an extended secret, and constructs a request structure using the UUID and extended secret. The request structure is then passed, sent, or transmitted 404 to the running / executing secure guest. From there, a trusted firmware interface for the running secure guest instance comes into play and receives the request structure. This interface may also be useful for the next step.

[0068] The trusted firmware then unpacks the received add-secret-request structure (which is a special form of request structure) and checks its integrity (406). If successful, the trusted firmware or its subcomponent decrypts the extended secret and data for the metadata update. If not, the request is denied.

[0069] One option for checking the integrity of the request structure is for the trusted firmware to check 408 whether the UUID value of the secure guest matches the UUID value in the request structure. If there is no match, the request is rejected.

[0070] In the next security refinement step, the trusted firmware checks whether the extended secret in the request structure is cryptographically linked to the extended secrets of all previously accepted request structures from the same secure guest instance (410). The request is rejected if this condition is not met. On the other hand, if the check is successful, the trusted firmware modifies the metadata as instructed by the request structure (412).

[0071] This can be seen as a prerequisite for the secure guest to be able to retrieve new metadata (414) at a later point in time from the trusted firmware (e.g., in the form of additional secrets) in order to personalize itself.

[0072] FIG. 5 illustrates one embodiment of a data structure 500 in the form of a secret add request structure according to one embodiment. To support integrity checking of the request structure 500, the request structure may include one or more measurements 302 of the generic image of the running secure guest instance. Additionally or alternatively, the request structure 500 may also include the UUID 502 of the running secure guest instance for which the request structure is intended. The request structure may store an ephemeral public key 506 (e.g., a DH or ECDH key). Additionally, a request structure protection key (RPK) 508 may protect the request structure itself or portions thereof. Before accessing the key 508, trusted firmware must decrypt the encryption 510 of the key 508.

[0073] Using a private key and possibly a public key 506 that is exclusively accessible by the trusted firmware (using a DH, ECDH scheme with 506, or an RSA scheme without 506), a key is calculated that can be used to decrypt the encryption 510 of key 508. Key 508 can then be used to both (i) verify the integrity of request structure 500 and (ii) decrypt the encrypted portion 512 of request structure 500. The combined operation of verification and encryption can be an authenticated encryption with additional data (AEAD) cipher (e.g., AES-GCM). If the verification algorithm calculates the same value that is stored in the tail portion 504 of request structure 500, then verification is successful.

[0074] Note also that the substructure 312 of the request structure that can be protected by the request protection key RPK corresponds to the integrity tag field of the request structure, which can be the result of a digital signature or an HMAC (Hash-Based Message Authentication Code) calculation, or an integrity tag calculated by an AEAD (Authenticated Encryption with Associated Data) operation such as AES-GCM (Advanced Encryption Standard - Galois / Counter Mode).

[0075] Furthermore, the request structure 500 includes a portion 512 in which a key should be kept in encrypted form, encrypted by an RPK that is specifically accessible only by the trusted firmware. This may be, for example, the extended secret 306 and data 308 representing the metadata modification (e.g., a new secret stored under firmware control). Note also that the RPK may be used to communicate to the trusted firmware within the request via a "key slot" that is only accessible by the trusted firmware and that can only be interpreted with the aid of a private host key that is also accessible only by the trusted firmware.

[0076] Additionally, structure 510 represents one of multiple key slots (specifically one per target host) containing a hash value of the public host key and an RPK encrypted using the public host and private customer keys, whereby the public host key is not explicitly shown.

[0077] 6 illustrates a block diagram of one embodiment of a security system 600 for personalizing a secure guest instance from a generic boot image using trusted firmware 204 that maintains metadata of the secure guest instance. The system 600 includes one or more processors 602 and memory 600 operatively coupled to the one or more processors 602 for stored program code portions (not shown) that, when executed by the one or more processors 602, enable the one or more processors 602 to pass (particularly via a send or pass module 606) a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance and establish at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance.

[0078] The system 600, and similarly the verification unit 608, is adapted by or in combination with trusted firmware to verify the request structure and, if successful, to modify the metadata as specified by the request structure.

[0079] In addition, the one or more processors 602 are also unable to retrieve secret objects derived from retrievable secrets from trusted firmware (particularly by the retrieval module 610, possibly in cooperation with the secure guest instance).

[0080] Last but not least, the system 600 may include a personalization module 612 such that one or more processors 602 (potentially in cooperation with the secure guest instance) use the retrieved secret objects to personalize the secure guest instance.

[0081] It is also noted that all functional units, modules, and functional blocks (particularly, one or more processors 602, memory 604, and pass module 606, trusted firmware 204, verification unit 608, retrieval module 610, and personalization module 612) may be communicatively coupled to each other for signal or message exchange in a selected 1:1 manner. Alternatively, the functional units, modules, and functional blocks may be linked to a system internal bus system 614 for selective signal or message exchange.

[0082] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0083] A computer program product embodiment (CPP embodiment or CPP) is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively included in a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A storage device is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as pits / lands formed on the major surface of a punch card or disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data typically moves at some infrequent time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but the above does not qualify a storage device as transitory because the data is not transitory while it is stored.

[0084] FIG. 7 illustrates a computing environment 700 that includes an example of an environment for the execution of at least some of the computer code involved in performing the methods of the present invention, such as a computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance 750.

[0085] In addition to block 750, computing environment 700 includes, for example, a computer 701, a wide area network (WAN) 702, an end user device (EUD) 703, a remote server 704, a public cloud 705, and a private cloud 706. In this embodiment, computer 701 includes a processor set 710 (including processing circuitry 720 and cache 721), a communications fabric 711, volatile memory 712, persistent storage 713 (including an operating system 722 and block 750 as identified above), a peripheral device set 714 (including a user interface (UI) device set 723, storage 724, and an Internet of Things (IoT) sensor set 725), and a network module 715. Remote server 704 includes a remote database 730. The public cloud 705 includes a gateway 740, a cloud orchestration module 741, a set of host physical machines 742, a set of virtual machines 743, and a set of containers 744.

[0086] Computer 701 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of running programs, accessing a network, or querying a database, such as remote database 730. As is well understood in the art of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. While in this presentation of computing environment 700, to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 701. Although computer 701 is not depicted in the cloud of FIG. 7, it may be located in a cloud. However, computer 701 is not required to reside within a cloud except to any extent that may be expressly indicated.

[0087] The processor set 710 includes one or more computer processors of any type now known or later developed. The processing circuitry 720 may be distributed across multiple packages, e.g., multiple coordinated integrated circuit chips. The processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. The cache 721 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores running on the processor set 710. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, the processor set 710 may be designed to operate with qubits and perform quantum computing.

[0088] Computer-readable program instructions are typically loaded onto computer 701 to cause a series of operational steps to be performed by processor set 710 of computer 701, thereby implementing a computer-implemented method, whereby the instructions so executed instantiate the method specified in the flowcharts and / or descriptions of the computer-implemented method contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 721 and other storage media discussed below. The program instructions and associated data are accessed by processor set 710 to control and direct the execution of the methods of the present invention. In computing environment 700, at least some of the instructions for implementing the methods of the present invention may be stored in block 750 within persistent storage 713.

[0089] Communications fabric 711 is the signal-conducting pathway that allows the various components of computer 701 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0090] Volatile memory 712 may be any type of volatile memory now known or later developed. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly stated. In computer 701, volatile memory 712 is located in a single package and is internal to computer 701, although alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 701.

[0091] Persistent storage 713 is any form of non-volatile storage for a computer, now known or developed in the future. The non-volatility of this storage means that stored data remains whether or not power is supplied to computer 701 and / or to persistent storage 713 directly. Persistent storage 713 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be erased, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 722 can take several forms, such as various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that employ a kernel. The code contained in block 750 typically includes at least a portion of the computer code involved in performing the methods of the present invention.

[0092] Peripheral device set 714 includes a set of peripheral devices of computer 701. Data communication connections between peripheral devices and other components of computer 701 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a Universal Serial Bus (USB) type cable), insertion-type connections (e.g., a Secure Digital (SD) card), connections made over a local area communication network, and even connections made over a wide area network such as the Internet. In various embodiments, UI device set 723 may include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 724 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 724 may be persistent and / or volatile. In some embodiments, storage 724 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 701 is required to have a large amount of storage (e.g., computer 701 stores and manages large databases locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 725 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0093] Network module 715 is a collection of computer software, hardware, and firmware that enables computer 701 to communicate with other computers over WAN 702. Network module 715 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 715 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of network module 715 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention can be downloaded to computer 701 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 715.

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

[0095] The end-user device (EUD) 703 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 701) and may take any of the forms discussed above in connection with the computer 701. The EUD 703 typically receives useful and useful data from the operation of the computer 701. For example, in the hypothetical case where the computer 701 is designed to provide recommendations to the end user, the recommendations would typically be communicated from the network module 715 of the computer 701 over the WAN 702 to the EUD 703. In this manner, the EUD 703 can display or otherwise present the recommendations to the end user. In some embodiments, the EUD 703 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

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

[0097] A public cloud 705 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 705 is performed by the computer hardware and / or software of a cloud orchestration module 741. The computing resources provided by the public cloud 705 are typically implemented by virtual computing environments running on various computers that comprise a host physical machine set 742, which is the universe of physical computers in and / or available to the public cloud 705. A virtual computing environment (VCE) typically takes the form of virtual machines from a virtual machine set 743 and / or containers from a container set 744. It is understood that these VCEs may be stored as images and may be transferred among and between various physical machine hosts either as images or after instantiation of the VCE. Cloud orchestration module 741 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 740 is a collection of computer software, hardware, and firmware that enables public cloud 705 to communicate over WAN 702.

[0098] Some further description of a virtualized computing environment (VCE) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCE are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running in them. A computer program running on a normal operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0099] Private cloud 706 is similar to public cloud 705, except that the computing resources are available only for use by a single enterprise. While private cloud 706 is shown as communicating with WAN 702, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both public cloud 705 and private cloud 706 are part of a larger hybrid cloud.

[0100] It should also be mentioned that a security system 600 (compare FIG. 6) for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance can be an operational subsystem of the computer 701 and may be attached to the computer's internal bus system.

[0101] The terminology used herein is for the purpose of describing particular embodiments only and is 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. It will be further understood that the terms "comprises" and / or "comprising," when used herein, specify the presence of 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 groups thereof.

[0102] Corresponding structure, materials, acts, and equivalents of all means or step-plus-function elements in the following claims are intended to include any structure, material, or act that performs the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. 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 to best explain the principles and practical application of the invention, and to enable others skilled in the art to understand the invention in various embodiments with various modifications as may be adapted to the particular use contemplated.

[0103] Briefly, the concept of the present invention can be explained by the following items: 1. A computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance, comprising: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; A method comprising: 2. The method according to item 1, wherein each request structure is integrity protected such that the integrity of the request structure is verified by the trusted firmware. 3. A request structure includes image measurements of the secure guest passing the request structure; 3. The method according to item 1 or 2, wherein the trusted firmware rejects the passed request structure if the measurements of the boot image of the secure guest do not match the image measurements. 4. The request structure includes a universally unique identifier (UUID) of the secure guest; 10. The method of claim 1, wherein the trusted firmware rejects the request structure if the UUID of the secure guest passing the request structure does not match the UUID in the request structure. 5. The method according to any one of the preceding items, wherein the request structure includes encrypted data that is decryptable only by the trusted firmware. 6. The encrypted data of the request structure includes an extended secret; 6. The method according to claim 5, wherein the trusted firmware rejects any request structure received after the first request structure whose extended secret does not match the extended secret of the first request structure received. 7. The method according to item 5, wherein the data of the request structure is encrypted, and the modification of the metadata of the secure guest comprises adding a portion of the encrypted data to the metadata as the secret. 8. A method according to any one of the preceding items, wherein the trusted firmware provides cryptographic functions that operate on protected keys, and the secret object is a protected key that is valid only for use by the secure guest as an argument to one of the cryptographic functions. 9. A method according to any one of the preceding items, wherein the secret included in the request structure to be added to the metadata of the secure guest can be marked as searchable, whereby the trusted firmware returns a secret object in response to a searchable secret retrieval request issued by the secure guest only if the secret is marked as searchable. 10. In the request structure, each retrievable secret is associated with a secret reference; 7. The method according to claim 6, wherein the step of retrieving the secret object associated with a secret reference from the trusted firmware is enabled by a retrieval interface of the trusted firmware that takes the secret reference as input. 11. The method according to any one of the preceding items, wherein the request structure includes an indication on how to modify the metadata of the secure guest. 12. The method according to any one of the preceding items, wherein the metadata includes controls that determine actions that can be performed by the secure guest. 13. Creating the request structure to modify the metadata of the secured guest instance that has been created but not yet started. 10. The method according to any one of the preceding items, further comprising: 14. A security system for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance, comprising: one or more processors and memory operatively coupled to said one or more processors; the memory, when executed by the one or more processors, causing the one or more processors to: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; The system stores program code portions that enable the 15. The system of claim 14, wherein each request structure is integrity protected such that the integrity of the request structure is verified by the trusted firmware. 16. A request structure includes image measurements of the secure guest passing the request structure; Item 15. The system of item 14, wherein the one or more processors are enabled by the trusted firmware to reject the passed request structure if the measurements of the secure guest's boot image do not match the image measurements. 17. The request structure includes a universally unique identifier (UUID) of the secure guest; 16. The system according to item 14 or 15, wherein the one or more processors are enabled by the trusted firmware to reject the request structure if the UUID of the secure guest passing the request structure does not match the UUID in the request structure. 18. The system according to any one of items 14 to 17, wherein the request structure includes encrypted data that is decryptable only by the trusted firmware. 19. The encrypted data of the request structure includes an extended secret; 19. The system of any one of items 14 to 18, wherein the one or more processors are enabled by the trusted firmware to reject any request structure received after a first request structure whose extended secret does not match the extended secret of the first request structure received. 20. The system according to item 18, wherein the data of the request structure is encrypted, and the modification of the metadata of the secure guest comprises adding a portion of the encrypted data to the metadata as the secret. 21. A system according to any one of items 14 to 20, wherein the trusted firmware provides cryptographic functions that operate on protected keys, and the secret object is a protected key that is valid only for use by the secure guest as an argument to one of the cryptographic functions. 22. A system according to any one of items 14 to 21, wherein the secret included in the request structure to be added to the metadata of the secure guest can be marked as searchable, whereby the trusted firmware returns a secret object in response to a searchable secret retrieval request issued by the secure guest only if the secret is marked as searchable. 23. In the request structure, each retrievable secret is associated with a secret reference; 23. The system according to claim 22, wherein retrieving the secret object associated with a secret reference from the trusted firmware is enabled by a retrieval interface of the trusted firmware that takes the secret reference as input. 24. The method according to any one of items 14 to 23, wherein the metadata includes controls that determine actions that can be performed by the secure guest. 25. A computer program product for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance, the computer program product comprising: a computer-readable storage medium having program instructions embodied thereon, the program instructions being configured to transmit, by one or more computing systems or controllers, to the one or more computing systems: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; A computer program product executable to cause a

Claims

1. 1. A computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance, the method comprising: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; A method comprising:

2. The method of claim 1 , wherein each request structure is integrity protected such that the integrity of the request structure is verified by the trusted firmware.

3. a request structure including image measurements of the secure guest passing the request structure; The method of claim 1 or 2, wherein the trusted firmware rejects the passed request structure if the measurements of the secure guest's boot image do not match the image measurements.

4. the request structure includes a universally unique identifier (UUID) of the secure guest; The method of any one of claims 1 to 3, wherein the trusted firmware rejects the request structure if the UUID of the secure guest passing the request structure does not match the UUID in the request structure.

5. The method of any one of claims 1 to 4, wherein the request structure includes encrypted data that is only decryptable by the trusted firmware.

6. the encrypted data in the request structure includes an extended secret; 6. The method of claim 5, wherein the trusted firmware rejects any request structure received after a first received request structure whose extended secret does not match the extended secret of the first received request structure.

7. The method of claim 5 , wherein the request structure data is encrypted, and the modification of the metadata of the secure guest comprises adding a portion of the encrypted data to the metadata as the secret.

8. 8. The method of claim 1, wherein the trusted firmware provides cryptographic functions that operate on protected keys, and the secret object is a protected key that is only valid for use by the secure guest as an argument to one of the cryptographic functions.

9. 9. A method according to any one of claims 1 to 8, wherein the secret included in the request structure to be added to the metadata of a secure guest can be marked as searchable, whereby the trusted firmware returns a secret object in response to a retrieve secret request issued by a secure guest only if the secret is marked as searchable.

10. In the request structure, each retrievable secret is associated with a secret reference; 7. The method of claim 6, wherein retrieving the secret object associated with a secret reference from the trusted firmware is enabled by a retrieval interface of the trusted firmware that takes the secret reference as input.

11. The method of any one of claims 1 to 10, wherein the request structure includes an indication on how to modify the metadata of the secure guest.

12. The method of any one of claims 1 to 11, wherein the metadata includes controls that determine actions that can be performed by the secure guest.

13. creating the request structure to modify the metadata of the created but not yet started secure guest instance; The method of any one of claims 1 to 12, further comprising:

14. 1. A security system for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance, the system comprising: one or more processors and memory operatively coupled to said one or more processors the memory, when executed by the one or more processors, causing the one or more processors to: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; The system stores program code portions that enable the

15. 15. The system of claim 14, wherein each request structure is integrity protected such that the integrity of the request structure is verified by the trusted firmware.

16. a request structure including image measurements of the secure guest passing the request structure; 15. The system of claim 14, wherein the one or more processors are enabled by the trusted firmware to reject the passed request structure if the measurements of the secure guest's boot image do not match the image measurements.

17. the request structure includes a universally unique identifier (UUID) of the secure guest; 16. The system of claim 14 or 15, wherein the one or more processors are enabled by the trusted firmware to reject the request structure if the UUID of the secure guest passing the request structure does not match the UUID in the request structure.

18. The system of any one of claims 14 to 17, wherein the request structure includes encrypted data that is only decryptable by the trusted firmware.

19. the encrypted data in the request structure includes an extended secret; 19. The system of claim 14, wherein the one or more processors are enabled by the trusted firmware to reject any request structure received after a first received request structure whose extended secret does not match the extended secret of the first received request structure.

20. 20. The system of claim 18, wherein the request structure data is encrypted, and the modification of the metadata of the secure guest comprises adding a portion of the encrypted data to the metadata as the secret.

21. 21. The system of claim 14, wherein the trusted firmware provides cryptographic functions that operate on protected keys, and the secret object is a protected key that is only valid for use by the secure guest as an argument to one of the cryptographic functions.

22. 22. The system of claim 14, wherein the secret included in the request structure to be added to the metadata of a secure guest can be marked as searchable, whereby the trusted firmware returns a secret object in response to a searchable secret get request issued by a secure guest only if the secret is marked as searchable.

23. In the request structure, each retrievable secret is associated with a secret reference; 23. The system of claim 22, wherein retrieving the secret object associated with a secret reference from the trusted firmware is enabled by a retrieval interface of the trusted firmware that takes the secret reference as input.

24. The method of any one of claims 14 to 23, wherein the metadata includes controls that determine actions that can be performed by the secure guest.

25. 1. A computer program product for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata of the secure guest instance, the computer program product comprising: a computer-readable storage medium having program instructions embodied thereon, the program instructions being configured to transmit to the one or more computing systems or controllers: passing a request structure from the secure guest instance to the trusted firmware to modify the metadata of the secure guest instance, and establishing at least one retrieveable secret in the metadata of the secure guest instance that is unique to the secure guest instance; verifying, by the trusted firmware, the request structure and, if successful, modifying the metadata as specified by the request structure; and retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing the secure guest instance using the retrieved secret object by the secure guest instance; A computer program product executable to cause a

Images