Updating secure guest metadata for specific guest instances

Abstract

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 is disclosed. The method includes passing a request structure from the secure guest instance to trusted firmware for modifying metadata of the secure guest instance and establishing at least one searchable secret specific to the secure guest instance in the metadata of the secure guest instance; verifying the request structure by the trusted firmware, and modifying the metadata according to the specified request structure after the verification succeeds; retrieving, by the secure guest instance, a secret object derived from the searchable secret from the trusted firmware; and personalizing, by the secure guest instance, the secure guest instance using the retrieved secret object.

Description

Technical Field

[0001] The present invention generally relates to a method for personalizing a secure guest instance from a general boot image, and more particularly, to a computer-implemented method for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance. The present invention also relates to a related security system for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance, and a computer program product. Background Art

[0002] The security of data and communication channels continues to be one of the top priorities for managing corporate IT (Information Technology). This is necessary not only due to government regulations (such as GDPR, i.e., the EU General Data Protection Regulation), but also due to the loss of corporate reputation caused by the inability to always reliably protect customer data, and the inability to avoid loss of revenue and profit in the event of damage to customer data records. Additionally, depending on the country where the data breach occurs, fines may have to be paid. As a result, the supply of data protection and secure computing platforms is not just a software issue; it also involves hardware modules. This may not 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-level computing environments, such as those used in the financial, insurance, or government industries, it must be possible to demonstrate at the technical level that data breaches can be almost completely prevented. This may require some additional high-tech components and support processes. However, the relevant success in data security will pay off for these additional efforts.

[0003] These ideas can also be applied to trusted and / or confidential computing environments, in which the keys used by virtual machines (also referred to as guests) or software containers running on / within a hypervisor cannot actually be accessed by the hypervisor or related software management and configuration programs. However, in such computing environments, it is still possible to violate basic security rules, such as by the hypervisor exposing the keys or key usage of the secure guest image. This situation can also occur in environments that have used hardware security modules (HSMs) for a long time.

[0004] There has already been some disclosure suitable for the context of a computer-implemented method for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance. Document US2020 / 0 076 607A1 describes how to securely maintain a secret on a virtual computer system by configuring a dedicated virtual machine to manage and maintain the secret on behalf of an application. When the application requests access to the secret, the control domain and the dedicated virtual machine jointly verify that the application is authorized to make the request and that the application has not been tampered with prior to the request.

[0005] The problems in such an environment can be identified in the context of an image to be executed on a hypervisor on a secure guest. For example, a user belonging to a general secure guest and wishing to modify the metadata of the secure guest, where the metadata can only be accessed by trusted firmware and the metadata belongs to a specific secure guest instance owned by the user. In such a case, it must not be possible to use the stolen data to steal data including secrets and add the secrets to the attacker's secure guest instance; and the attacker must not be able to compile data including 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) do not yet well meet this requirement.

[0006] Therefore, there is a need to provide a secure method between a virtual machine and firmware so that the virtual machine and its metadata cannot be compromised by an attacker in the above manner. 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 general boot image using trusted firmware that maintains metadata of the secure guest instance can be provided. The method may include: passing a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance; and verifying, by the trusted firmware, the request structure and, upon success, modifying the metadata as specified by the request structure. The method may further include: retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalizing, by the secure guest instance, the secure guest instance using the retrieved secret object.

[0008] According to another aspect of the present invention, a secure system for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance can be provided. The system may include one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions that, when executed by the one or more processors, cause the one or more processors to be able to: pass a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance; and verify, by the trusted firmware, the request structure and, upon success, modify the metadata as specified by the request structure.

[0009] In addition, the one or more processors can be enabled to: retrieve, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware; and personalize the secure guest instance by the secure guest instance using the retrieved secret object.

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

[0011] The proposed concept, particularly the subject matter of the first claim, can have the potential to increase the security level in a computer system. In particular, the execution of the secure guest system can be made even more secure.

[0012] For example, the proposed concept can define technical barriers to prevent the metadata of a specific secure guest instance from being used or misused by another secure guest instance or any other process in the computer system under discussion.

[0013] Additionally, the proposed concept can also prohibit a secure guest from using the request structure of another secure guest (e.g., to modify metadata in the firmware) in order to modify the metadata maintained by the firmware of the computer system in a non-permitted manner. Thus, any cross-usage between secure guest instances running on a hypervisor above the trusted firmware can be prohibited by the design. The personalization of the secure guest proposed herein can contribute to this security level.

[0014] It can also enhance the security level of the underlying confidential computing environment because stolen keys or secrets cannot be used by unauthorized secure guest instances either.

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

[0016] In addition, the proposed concept also has the advantage that the secret for personalization does not need to be stored as a plaintext value in the memory of the secure guest all the time.

[0017] Another advantage can lie in the fact that a tenant of the client can change the behavior of the trusted firmware when controlling the secure guest by changing the controls in the metadata of the secure guest. For example, the possibility of dumping a secure guest that has been started as dumpable can be prohibited.

[0018] Multiple requests can be submitted to change the metadata (including adding secrets), thereby forcing all the requests constructed to form the same theme.

[0019] In the following, additional embodiments of the concepts of the present invention applicable to the method as well as to the system will be described.

[0020] According to a preferred embodiment of the method, each request structure can be integrity-protected such that the integrity of the request structure can be verified specifically only by the trusted firmware. Integrity checks can thus be applied to the integrity of the request structure itself and its applicability to a specific secure guest image. The calculation of a cryptographic hash, a message authentication code, or a digital signature can contribute to verifying the integrity.

[0021] According to an advantageous embodiment of the method, the request structure can include the measured value of the image of the secure guest transmitting the request structure, and if the measured value of the boot image of the secure guest does not match the measured value of the image, the trusted firmware can reject the transmitted or submitted request structure, in particular a request structure transmitted or sent from the secure guest to the trusted firmware. As an example, the measured value can be the size of the general boot image in bytes. Other measured values (in particular cryptographic security measurements (hash, MAC, digital signature)) are also possible.

[0022] According to a permissive embodiment of the method, the request structure can include the universally unique identifier UUID of the secure guest, and if the UUID of the secure guest transmitting the request structure does not match the UUID in the request structure, the trusted firmware can reject the request structure. Due to the nature of the UUID, this security mechanism can represent good protection against unauthorized access.

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

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

[0025] According to a permissive embodiment of the method, the data of the request structure can be encrypted, and the modification of the metadata of the secure guest can include adding some of the encrypted data in the encrypted data as the secret to the metadata. In this way, the secure guest can add encrypted data values to the metadata maintained by the 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 a protected key, where the secret object may be the protected key, and the protected key may be valid only for use as a parameter in one of the cryptographic functions by the secure guest. An example of a protected key may be the CPACF (Control Program Assist for Cryptographic Functions) protected key of the IBM Z platform.

[0027] According to another embodiment of the method, the secret of the metadata to be added to the secure guest instance included in the request structure can be marked as retrievable, such that the trusted firmware can return the secret object in response to a get-retrievable-secret request issued by the secure guest only when the secret is marked as retrievable. This can be regarded as a second level of metadata, through which specific metadata (such as secrets) of the secure guest instance can be marked so that the usage method can be predefined.

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

[0029] According to another enhanced embodiment of the method, the request structure may include a description of how to modify the metadata of the secure guest. This data can also be regarded as a second level of metadata. However, this technique can allow, for example, controlling the behavior of the secure guest instance in the long run by restricting the use of additional metadata.

[0030] According to an interesting embodiment of the method, the metadata may include controls for determining the operations that can be performed by the secure guest. Some examples of these operations may include allowing a core dump in case the execution of the secure guest image may crash or defining access to specific devices or excluding access to other specific devices. In this way, fine-grained control of the behavior options of the secure guest image can be defined.

[0031] In another interesting embodiment of the method, instead of the secure guest submitting the request structure, the request structure can be submitted to the firmware to modify the metadata of a secure guest instance that has been created but not yet started. Thus, a class of master metadata for multiple instances of secure guests can be predefined, which can allow for a reduction in the time and effort of the operator.

[0032] In addition, an embodiment may take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code used by or in conjunction with a computer or any instruction execution system. For the purposes of this specification, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] It should be noted that the embodiments of the present invention are described with reference to different subjects. In particular, some embodiments are described with reference to method claims, while other embodiments are described with reference to apparatus claims. However, those skilled in the art will appreciate from the above and following descriptions that, unless otherwise indicated, any combination of features related to different subjects, in particular any combination of features of method claims and features of apparatus claims, is also considered to be disclosed within this document.

[0034] The above and other aspects of the present invention will be apparent from and will be elucidated with reference to the examples of the embodiments described hereinafter. The present invention is not limited to the examples of these embodiments.

[0035] The preferred embodiments of the present invention will be described only by way of example and with reference to the following drawings:

[0036] Figure 1 A flowchart of an embodiment of a computer-implemented method of the present invention for personalizing a secure guest instance using a trusted firmware that maintains metadata of the secure guest instance is shown.

[0037] Figure 2 A block diagram showing the components of a scenario of a potential security attack is shown.

[0038] Figure 3 A block diagram of an embodiment including components that contribute to the concepts presented herein is shown.

[0039] Figure 4A flowchart showing an activity sequence closer to the implementation of the concepts presented herein.

[0040] Figure 5 An embodiment of a get - secret - request structure according to an embodiment is shown.

[0041] Figure 6 A block diagram of an embodiment of a security system of the present invention for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance is shown.

[0042] Figure 7 An embodiment of a computing system including a system according to Figure 6 is shown. Detailed Description

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

[0044] The term "secure guest" may represent a virtual machine or software container including executable program code in a secure computing environment, which is protected by a trusted execution environment such that untrusted components of the computer system cannot observe any state (memory or registers) of the running secure guest. It can be, for example, a general guest image that can also be provided by a third party (such as a software company). Typical untrusted components are software hypervisors, hardware management consoles, and other guests.

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

[0046] The term "metadata" may represent information about data in the classical sense, and here in particular represents data required to start a virtual machine. In a confidential computing environment, such information can be used by trusted firmware to start a secure virtual machine, for example, it may include integrity measures of the image of the secure guest or keys required to decrypt the image of the secure guest. These metadata may include, for example, required resources, required interfaces, required performance, and in some cases also which security measures are appropriate. The extension of the metadata to be used by trusted firmware (e.g., in terms of required binding information, but more specifically in terms of secret and secret - name pairs) represents one of the bases of the concepts presented.

[0047] The term "personalization" can mean here that a general boot image can be changed in such a way that it may lose its general state, i.e., it can become a dedicated or even unique executable image, e.g., by adding (TLS / ssh) signature keys and / or (volume) encryption / decryption keys, by restricting its capabilities by binding it to a special user (e.g., by setting a password) or to specific hardware, etc.

[0048] The term "trusted firmware" (trusted FW or TFW) can mean a component that is deeply embedded in the hardware of a computing (host) system and is not accessible by software that can be controlled by any other user. The trusted firmware can have predefined and highly secure application programming interfaces in order to protect the operation of the trusted firmware in a broad sense. Trusted FW should be regarded more as a deeply integrated component of a computer system rather than a service component. The communication channels to / from the trusted firmware are typically password-protected.

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

[0050] The term "modify metadata" can mean that new metadata can be added to the existing metadata for a specific secure guest image, or the existing metadata can be modified. The corresponding request can include instructions on how to modify the metadata.

[0051] The term "retrievable secret" can mean a data item that can be stored in the metadata belonging to a secure guest image. Typically, this data item can be associated with some kind of reference (index or name). This data item can be added to the metadata by a request structure submitted (or passed) by the guest to the trusted FW. As a result of the secure guest making a function call to the trusted firmware to retrieve the secret that can be referenced by a reference to the secret, the retrievable secret can be retrieved (i.e., loaded into the secure guest). The retrieved secret can take the form of a plaintext value that does not disclose the secret (e.g., as a key protected by IBM ZCPACF).

[0052] The term "secret object" can mean any data item whose meaning is only available to a predefined constituency.

[0053] The term "integrity protection" can mean that the validity of a data structure in a predefined form can be verified. Thus, the data included in the data structure itself can be used to confirm the validity of the complete data structure. For this purpose, measurement values can be used, such as the total number of bytes, cryptographic hashes, message authentication codes, or signatures of data structures (e.g., the boot image of a virtual machine), or the UUID of the data structure.

[0054] The term "image measurement value" may represent the measurement value mentioned in the previous paragraph.

[0055] The term "Universally Unique Identifier" (UUID) may represent a known 128-bit tag that uniquely identifies a resource in a computer system.

[0056] The term "encrypted data" may represent data for which the plaintext is not available but which has been modified using a predefined key. After the decryption process, the encrypted data can be read again in plaintext.

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

[0058] The term "integrity check" may represent ensuring that a component (especially a request structure) itself can be consistent. For this purpose, hash value comparison, digital signatures, or message authentication codes (MACs) can typically be used.

[0059] Below, a detailed description of the accompanying drawings will be given. All descriptions in the figures are schematic. First, a block diagram of an embodiment of a computer-implemented method of the present invention for personalizing a secure guest instance from a general boot image using a trusted firmware that maintains metadata of the secure guest instance is given. Then, further embodiments and embodiments of a security system for personalizing a secure guest instance from a general boot image using a trusted firmware that maintains metadata of the secure guest instance will be described.

[0060] Figure 1 A block diagram of a preferred embodiment of a computer-implemented method 100 for personalizing a secure guest instance from a general boot image (e.g., provided by a third party such as a software company) using a trusted firmware that maintains metadata of the secure guest instance is shown. Method 100 includes passing 102 a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance, and verifying 104 the request structure by the trusted firmware and, upon success, modifying the metadata as specified by the request structure. Thereby, the verification includes an integrity check of the request structure.

[0061] Furthermore, method 100 includes retrieving 106 by the secure guest instance, for example, upon request, a secret object derived from the retrievable secret from the trusted firmware. The requested secret can be extracted or derived from the metadata of the secure guest instance. Additionally, method 100 includes using 108 the retrieved secret object by the secure guest instance to personalize the secure guest instance, i.e., to personalize itself.

[0062] Figure 2 Block diagram 200 showing components of a scenario of a potential security attack. The computer system 202 includes a trusted firmware 204 on which a hypervisor 210 can operate to execute one or more virtual machines, such as secure virtual guest-1 212 and secure virtual guest-2 218. The secure virtual guest-1 212 can access its metadata (MD) 206, for example, via a request structure 214 with or without the support of the hypervisor 210. This represents an allowed access 216. However, the same request structure 214 (possibly with the same key) should not allow the secure virtual guest-2 218 to access other metadata, such as the metadata of secure guest-2 208. This must be reliably prohibited because it would represent an access threat 220.

[0063] In addition, the use of another request structure with another key 226 to access the metadata of the secure guest 206 should also be prohibited (not allowed 224) because this would also constitute unauthorized access 224.

[0064] Figure 3 Block diagram 300 showing an embodiment including components facilitating the concepts presented herein. The figure shows the same computer system 202, trusted firmware 204, metadata of the secure guest 206, hypervisor 210, and secure guest 212, whereby it should be noted that the secure guest is the secure guest 212 in execution. It may have been created from a boot image 314 by instantiation 316 to establish the secure guest 212 in execution controlled by the hypervisor 210. Figure 2

[0065] Also, note the request structures 304 and 310 as they represent request structures at different time points. The first request structure 304 can include an extended key 306 and another protected key 308 that should be integrated into the metadata of secure guest-1 206.

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

[0067] Figure 4Figure 400 shows a flow chart of an activity sequence that is a closer implementation of the concepts presented herein. In one of the initial steps 402, a user of a secure guest, knowing the UUID of the secure guest instance, selects an extended secret and uses the UUID and the extended secret to construct a request structure. Next, the request structure is passed, sent, or transmitted 404 to the running / existing secure guest. From there, the trusted firmware interface for the running secure guest instance becomes operative and receives the request structure. The interface may also assist in the next steps.

[0068] Then, the trusted firmware unpacks 406, for example, the received add-secret-request structure (which is a special form of the request structure) and checks its integrity. Upon success, the trusted firmware or a sub-component of the trusted firmware decrypts the extended secret and the data for metadata update. Otherwise, the request is rejected.

[0069] One option for checking the integrity of the request structure would be for the trusted firmware to check 408 whether the UUID value of the secure guest matches the UUID value in the request structure. If this is not the case, the request is rejected.

[0070] In the next security enhancement step, the trusted firmware checks 410 whether the extended secret in the request structure is cryptographically related to the extended secrets of all previously accepted request structures from the same secure guest instance. If this condition is not met, the request is rejected. However, if the check is successful, the trusted firmware modifies 412 the metadata as indicated by the request structure.

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

[0072] Figure 5 An embodiment of a data structure 500 in the form of an add-secret-request structure according to an embodiment is shown. To support the integrity check of the request structure 500, the request structure may include one or more measurements 302 of a general image or the running secure guest instance. Additionally or alternatively, the request structure 500 may also include the UUID 502 of the running secure guest instance that the request structure is targeted at. The request structure may contain an ephemeral public key 506 (e.g., a DH or ECDH key). Furthermore, a request structure protection key (RPK) 508 may also protect the request structure itself or parts of the request structure. Before accessing the key 508, the trusted firmware will have to decrypt the encryption 510 of the key 508.

[0073] Using a private key that can be accessed exclusively by the trusted firmware and possibly using a public key 506 (using DH, ECDH schemes with 506, using RSA scheme without 506), a key for encrypting 510 that can be used to decrypt the key 508 is calculated simultaneously. The key 508 can then be used for both (i) verifying the integrity of the request structure 500 and (ii) decrypting the encrypted part 512 of the request structure 500. The combined verification and encryption operations can be an authenticated encryption (AEAD) cipher with additional data (e.g., AES-GCM). Verification is successful if the verification algorithm calculates the same value stored in the last part 504 of the request structure 500.

[0074] It can also be noted that a sub-structure 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. This tag can be the result of a digital signature or 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] In addition, the request structure 500 includes a part 512 in which the key should be saved in encrypted form, particularly encrypted by the RPK that can only be accessed by the trusted firmware. This can be, for example, the extended secret 306 and data 308 representing metadata modification (e.g., a new secret to be stored under the control of the firmware). It should also be noted that the RPK can only be accessed by the trusted firmware and can be used to communicate with the trusted firmware within the request via "key slots" that can only be interpreted with the help of a private host key that is also only accessible by the trusted firmware.

[0076] Additionally, the structure 510 represents one of the key slots in a plurality of key slots (specifically, one key slot for each target host), which includes a hash value of the public host key and the RPK encrypted using the public host key and the private client key. Thus, the (one or more) public host keys are not explicitly shown.

[0077] Figure 6FIG. 0 shows a block diagram of an embodiment of a security system 600 for personalizing a secure guest instance from a general boot image using a trusted firmware 204 that maintains metadata of the secure guest instance. The system 600 includes one or more processors 602 and a memory 604 operatively coupled to the one or more processors 602, where the memory 604 stores program code portions (not shown) that, when executed by the one or more processors 602, cause the one or more processors 602 to pass a request structure from the secure guest instance (specifically, by sending or passing through module 606) to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance.

[0078] The system 600 and the verification unit 608 are adapted to verify the request structure via the trusted firmware or in combination with the trusted firmware and, upon success, modify the metadata as specified by the request structure.

[0079] In addition, the one or more processors 602 are further capable of retrieving (specifically, through retrieval module 610, possibly in cooperation with the secure guest instance) a secret object derived from the retrievable secret from the trusted firmware.

[0080] Last but not least, the system 600 may include a personalization module 612 to cause the one or more processors 602, potentially in cooperation with the secure guest instance, to personalize the secure guest instance using the retrieved secret object.

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

[0082] Aspects of the present invention are described by illustrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). For any flowchart, depending on the technology involved, operations may be performed in an order different from the order shown in a given flowchart. For example, also depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0083] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in the present invention to describe any collection of one or more storage media (also referred to as "media") that together are included in a collection of one or more storage devices that together include 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 retain and store instructions for use by a computer processor. A computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media are: floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices (such as punched cards or pits / islands formed in the main surface of a disc), or any suitable combination of the foregoing. As a term used in the present invention, a computer-readable storage medium is not construed to be 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, optical pulses through an optical fiber, electrical signals transmitted through a wire, and / or other transmission media. As understood by those skilled in the art, data is typically moved at certain occasional points in time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transitory because the data is not transitory when stored.

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

[0085] In addition to block 750, the computing environment 700 also 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, the computer 701 includes a processor group 710 (including processing circuitry 720 and a cache 721), a communication fabric 711, volatile memory 712, persistent storage 713 (including an operating system 722 and block 750, as described above), a peripheral group 714 (including a user interface (UI) device group 723, a storage device 724, and an Internet of Things (IoT) sensor group 725), and a network module 715. The remote server 704 includes a remote database 730. The public cloud 705 includes a gateway 740, a cloud orchestration module 741, a host physical machine group 742, a virtual machine group 743, and a container group 744.

[0086] The computer 701 may take the form of a desktop computer, a laptop computer, a tablet computer, a smart phone, a smart watch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device that is now known or will be developed in the future and is capable of running programs, accessing a network, or querying a database, such as the remote database 730. As understood in the computer art, according to this technology, the execution of computer-implemented methods can be distributed among multiple computers and / or multiple locations. On the other hand, in the presentation of this computing environment 700, the discussion focuses in detail on a single computer, specifically the computer 701, to keep the presentation as simple as possible. The computer 701 may be located in the cloud, although Figure 7 it is not shown in the cloud in the figure. On the other hand, the computer 701 does not need to be in the cloud unless it can be definitely stated to any extent.

[0087]

[0088] The processor group 710 includes one or more computer processors of any type that are now known or will be developed in the future. The processing circuitry 720 may be distributed across multiple packages, such as 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 the threads or cores running on the processor group 710 should be able to access quickly. Depending on the relative proximity to the processing circuitry, the cache memory is typically organized into multiple levels. Alternatively, some or all of the cache of the processor group may be located "off-chip". In some computing environments, the processor group 710 may be designed to use qubits and perform quantum computing.Computer-readable program instructions are typically loaded onto a computer 701 so that a processor group 710 of the computer 701 executes a series of operational steps to implement a computer-implemented method such that the instructions so executed will instantiate the flowcharts and / or the method specified in the descriptive description of the computer-implemented method contained in this document (collectively referred to as "the method 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 the processor group 710 to control and directly execute the method of the present invention. In the computing environment 700, at least some of the instructions for executing the method of the present invention may be stored in block 750 in the persistent storage device 713.

[0089] The communication structure 711 is a signal conduction path that allows various components of the computer 701 to communicate with each other. Typically, this structure consists of switches and conductive paths, such as the switches and conductive paths that make up a bus, a bridge, a physical input / output port, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0090] The volatile memory 712 is any type of volatile memory known currently or developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, but this is not required unless explicitly indicated. In the computer 701, the volatile memory 712 is located in a single package and inside the computer 701. However, optionally or additionally, the volatile memory can be distributed across multiple packages and / or be located external to the computer 701.

[0091] The persistent storage device 713 is any form of non-volatile storage device of a computer known currently or to be developed in the future. The non-volatility of this storage device means that the stored data will be retained regardless of whether power is supplied to the computer 701 and / or whether power is directly supplied to the persistent storage device 713. The persistent storage device 713 can be a read-only memory (ROM), but typically at least a portion of the persistent storage device allows writing, deleting, and rewriting of data. Some common forms of persistent storage devices include magnetic disks and solid-state storage devices. The operating system 722 can take various forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems that employ a kernel. The code included in block 750 typically includes at least some of the computer code involved in executing the method of the present invention.

[0092] The peripheral device group 714 includes the peripheral device group of the computer 701. The data communication connection between the peripheral devices and other components of the computer 701 can be implemented in various ways, such as Bluetooth connection, near field communication (NFC) connection, cable connection (such as a universal serial bus (USB) type cable), plug-in connection (such as a secure digital (SD) card), connection via a local communication network, or even connection via a wide area network such as the Internet. In various embodiments, the UI device group 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. The storage device 724 is an external storage device (such as an external hard disk drive) or a plug-in memory (such as an SD card). The storage device 724 can be persistent and / or volatile. In some embodiments, the storage device 724 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 701 requires a large amount of storage (for example, the computer 701 locally stores and manages a large database), the storage device may be provided by a peripheral storage device designed to store a very large amount of data, such as a storage area network (SAN) shared by multiple geographically dispersed computers. The IoT sensor group 725 includes sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer and another sensor can be a motion detector.

[0093] The network module 715 is a collection of computer software, hardware, and firmware that allows the computer 701 to communicate with other computers via the WAN 702. The network module 715 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or network browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 715 are executed on the same physical hardware device. In other embodiments (such as embodiments utilizing software-defined networking (SDN)), the control function and the forwarding function of the network module 715 are executed on physically separate devices, such that the control function manages multiple different network hardware devices. The computer-readable program instructions for performing the methods of the present invention can generally be downloaded to the computer 701 from an external computer or an external storage device via a network adapter or network interface included in the network module 715.

[0094] The WAN 702 is any wide area network, such as the Internet, capable of transmitting computer data over non-local distances via any technology for transmitting computer data, whether now known or developed in the future. In some embodiments, the WAN may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area such as a Wi-Fi network. The WAN and / or LAN typically includes computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, 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 form discussed above in connection with the computer 701. The EUD 703 typically receives helpful 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 recommendation will typically be transmitted from the network module 715 of the computer 701 through the WAN 702 to the EUD 703. In this way, the EUD 703 can display or otherwise present the recommendation to the end user. In some embodiments, the EUD 703 may be a client device such as a thin client, thick client, mainframe, desktop, etc.

[0096] The remote server 704 is any computer system that provides at least some data and / or functionality to the computer 701. The remote server 704 may be controlled and used by the same entity operating the computer 701. The remote server 704 represents a machine for collecting and storing useful data for use by other computers (such as the computer 701). For example, in the hypothetical case where the computer 701 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to the computer 701 from the remote database 730 of the 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 computing capabilities, particularly data storage (cloud storage) and computing power, without the need for direct active management by the user. Cloud computing typically exploits resource sharing to achieve consistency and economies of scale. The direct active management of the computing resources of the public cloud 705 is performed by the computer hardware and / or software of the 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 make up the host physical machine group 742, which are the various physical computers within and / or available for the public cloud 705. A virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine group 743 and / or containers from the container group 744. It will be appreciated that these VCEs can be stored as images and can be transferred between individual physical machine hosts either as images or after the VCEs are instantiated. The cloud orchestration module 741 manages the transfer and storage of the images, deploys new instances of the VCEs, and manages the active instances of the VCE deployments. The gateway 740 is a collection of computer software, hardware, and firmware that allows the public cloud 705 to communicate over the WAN 702.

[0098] Some further explanation of virtualized computing environments (VCEs) will now be provided. A VCE can be stored as an "image". New active instances of a VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user space instances (called containers). From the perspective of the programs running within them, these isolated user space instances typically appear as real computers. A computer program running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of that container and the devices allocated to that container, a feature known as containerization.

[0099] A private cloud 706 is similar to the public cloud 705, except that the computing resources are only available for use by a single enterprise. Although the private cloud 706 is depicted as communicating with the WAN 702, in other embodiments, the private cloud can be completely disconnected from the Internet and only accessible through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (such as private, community, or public cloud types), typically implemented separately by different providers. Each of the multiple clouds remains an independent discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies to support orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, the public cloud 705 and the private cloud 706 are both part of a larger hybrid cloud.

[0100] It should also be mentioned that the trusted firmware for using the metadata to maintain the secure guest instance personalizes the secure guest instance 600 from the general boot image (compare Figure 6 ) can be the operating system of the computer 701 and can be attached to the internal bus system of the computer.

[0101] The terms used herein are for the purpose of describing particular embodiments only and are 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 dictates otherwise. It will also be understood that the terms "comprises" and / or "comprising", when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0102] All apparatus or steps in the following claims, plus the corresponding structures, materials, acts, and equivalents of the functional elements, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the invention has been given for purposes of illustration and description, but the description is not exhaustive or limits the invention to the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The selection and description of the embodiments are intended to best explain the principles of the invention and its practical application, and to enable those of ordinary skill in the art to understand that the invention may have various embodiments with various changes suitable for the particular purposes contemplated.

[0103] In short, the concept of the present invention can be described by the following clauses:

[0104] 1. A computer-implemented method for personalizing a secure guest instance from a general boot image using trusted firmware that maintains metadata of the secure guest instance, the method comprising:

[0105] - Transmitting a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance,

[0106] - Verifying, by the trusted firmware, the request structure and, upon success, modifying the metadata as specified by the request structure,

[0107] - Retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware, and

[0108] - The security visitor instance personalizes itself using the retrieved secret object.

[0109] 2. The method according to clause 1, wherein each request structure is integrity-protected such that the integrity of the request structure is verified by the trusted firmware.

[0110] 3. The method according to clause 1 or 2,

[0111] - wherein the request structure includes the measured value of the image of the security visitor that transmits the request structure, and

[0112] - wherein if the measured value of the boot image of the security visitor does not match the measured value of the image, the trusted firmware rejects the transmitted request structure.

[0113] 4. The method according to any one of the preceding clauses,

[0114] - wherein the request structure includes the Universally Unique Identifier (UUID) of the security visitor, and

[0115] - wherein if the UUID of the security visitor that transmits the request structure does not match the UUID in the request structure, the trusted firmware rejects the request structure.

[0116] 5. The method according to any one of the preceding clauses, wherein the request structure includes encrypted data that can only be decrypted by the trusted firmware.

[0117] 6. The method according to clause 5,

[0118] - wherein the encrypted data of the request structure includes an extended secret, and

[0119] - 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 received first request structure.

[0120] 7. The method according to clause 5, wherein the data of the request structure is encrypted, and wherein the modification of the metadata of the security visitor includes adding some of the encrypted data in the encrypted data as the secret to the metadata.

[0121] 8. The method according to any one of the preceding clauses, wherein the trusted firmware provides a cryptographic function that operates on a protected key, wherein the secret object is the protected key, and the protected key is only valid for use as a parameter of one of the cryptographic functions by the security visitor.

[0122] 9. The method according to any one of the preceding clauses, wherein the secret of the metadata to be added to the secure visitor included in the request structure can be marked as retrievable, such that the trusted firmware returns a secret object in response to a get-retrievable-secret request issued by the secure visitor only when the secret is marked as retrievable.

[0123] 10. The method according to clause 6,

[0124] - wherein, in the request structure, each retrievable secret is associated with a secret reference, and

[0125] - wherein retrieving the secret object associated with the secret reference from the trusted firmware is implemented by a retrieval interface of the trusted firmware that takes the secret reference as an input.

[0126] 11. The method according to any one of the preceding clauses, wherein the request structure includes an indication of how to modify the metadata of the secure visitor.

[0127] 12. The method according to any one of the preceding clauses, wherein the metadata includes controls for determining operations that can be performed by the secure visitor.

[0128] 13. The method according to any one of the preceding clauses, further comprising:

[0129] - creating the request structure to modify the metadata of the secure visitor instance that has been created but not yet started.

[0130] 14. A security system for personalizing a secure visitor instance from a general boot image using a trusted firmware that maintains metadata of the secure visitor instance, the system comprising:

[0131] - one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions that, when executed by the one or more processors, cause the one or more processors to be able to:

[0132] - pass a request structure from the secure visitor instance to the trusted firmware for modifying the metadata of the secure visitor instance and establishing at least one retrievable secret specific to the secure visitor instance in the metadata of the secure visitor instance,

[0133] - have the trusted firmware verify the request structure and, upon success, modify the metadata as specified by the request structure,

[0134] - The secret object derived from the retrievable secret is retrieved from the trusted firmware by the security guest instance, and

[0135] - The security guest instance personalizes itself using the retrieved secret object.

[0136] 15. The system according to clause 14, wherein each request structure is integrity protected such that the integrity of the request structure is verified by the trusted firmware.

[0137] 16. The system according to clause 14,

[0138] - wherein the request structure includes the measured value of the image of the security guest that transmits the request structure, and

[0139] - such that the one or more processors can reject the transmitted request structure by the trusted firmware when the measured value of the boot image of the security guest does not match the measured value of the image.

[0140] 17. The system according to clause 14 or 15,

[0141] - wherein the request structure includes the universally unique identifier UUID of the security guest, and

[0142] - such that the one or more processors can reject the request structure by the trusted firmware when the UUID of the security guest that transmits the request structure does not match the UUID in the request structure.

[0143] 18. The system according to any one of clauses 14 to 17, wherein the request structure includes encrypted data that can only be decrypted by the trusted firmware.

[0144] 19. The system according to any one of clauses 14 to 18,

[0145] - wherein the encrypted data of the request structure includes an extended secret, and

[0146] - such that the one or more processors can reject by the trusted firmware any request structure whose extended secret received after the first request structure does not match the extended secret of the received first request structure.

[0147] 20. The system according to clause 18, wherein the data of the request structure is encrypted, and wherein the modification of the metadata of the security guest includes adding some of the encrypted data in the encrypted data as the secret to the metadata.

[0148] 21. The system according to any one of clauses 14 to 20, wherein the trusted firmware provides a cryptographic function for operating on a protected key, wherein the secret object is the protected key, and the protected key is only valid for being used as a parameter of one of the cryptographic functions by the secure guest.

[0149] 22. The system according to any one of clauses 14 to 21, wherein the secret to be added to the metadata of the secure guest included in the request structure can be marked as retrievable, such that the trusted firmware returns the secret object in response to a get-retrievable secret request issued by the secure guest only when the secret is marked as retrievable.

[0150] 23. The system according to clause 22,

[0151] - wherein, in the request structure, each retrievable secret is associated with a secret reference, and

[0152] - wherein retrieving the secret object associated with the secret reference from the trusted firmware is implemented by a retrieval interface of the trusted firmware that takes the secret reference as an input.

[0153] 24. The method according to any one of clauses 14 to 23, wherein the metadata includes controls for determining operations that can be performed by the secure guest.

[0154] 25. A computer program product for personalizing a secure guest instance from a general boot image using a trusted firmware that maintains metadata of the secure guest instance, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to:

[0155] - pass a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance,

[0156] - have the trusted firmware verify the request structure and, upon success, modify the metadata as specified by the request structure,

[0157] - have the secure guest instance retrieve a secret object derived from the retrievable secret from the trusted firmware, and

[0158] - have the secure guest instance use the retrieved secret object to personalize the secure guest instance.

Claims

1. A computer-implemented method for personalizing a secure guest instance from a general 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 for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance, - Verifying, by the trusted firmware, the request structure and, upon success, modifying the metadata as specified by the request structure, - Retrieving, by the secure guest instance, a secret object derived from the retrievable secret from the trusted firmware, and - Personalizing, by the secure guest instance, the secure guest instance using the retrieved secret object.

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

3. The method according to claim 1 or 2, - wherein the request structure includes a measured value of the image of the secure guest that transmitted the request structure, and - Among them, if the measured value of the boot image of the secure guest does not match the measured value of the image, the trusted firmware rejects the transmitted request structure.

4. The method according to any one of claims 1 to 3, - wherein the request structure includes the Universally Unique Identifier (UUID) of the secure guest, and - Among them, if the UUID of the secure guest that transmitted the request structure does not match the UUID in the request structure, the trusted firmware rejects the request structure.

5. The method according to one of claims 1 to 4, wherein The request structure includes encrypted data that can only be decrypted by the trusted firmware.

6. The method according to claim 5, - wherein the encrypted data of the request structure includes an extended secret, and - Among them, the trusted firmware rejects any request structure received after the first request structure whose extended secret does not match the extended secret of the received first request structure.

7. The method according to claim 5, wherein, The data of the request structure is encrypted, and wherein the modification of the metadata of the secure guest includes adding some of the encrypted data in the encrypted data as the secret to the metadata.

8. The method according to any one of claims 1 to 7, wherein The trusted firmware provides a cryptographic function that operates on a protected key, wherein the secret object is the protected key, and the protected key is only valid for use as a parameter of one of the cryptographic functions by the secure guest.

9. The method according to one of claims 1 to 8, wherein, The secret to be added to the metadata of the secure guest included in the request structure can be marked as retrievable such that the trusted firmware returns the secret object in response to a get-retrievable-secret request issued by the secure guest only when the secret is marked as retrievable.

10. The method according to claim 6, - wherein, in the request structure, each retrievable secret is associated with a secret reference, and - Among them, retrieving the secret object associated with the secret reference from the trusted firmware is implemented by a retrieval interface of the trusted firmware that takes the secret reference as an input.

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

12. The method according to one of claims 1 to 11, wherein, The metadata includes controls for determining operations that can be performed by the secure guest.

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

14. A security system for personalizing a secure guest instance from a general boot image using a trusted firmware that maintains metadata of the secure guest instance, the system comprising: - one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions that, when executed by the one or more processors, cause the one or more processors to be able to: - pass a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance, - have the trusted firmware verify the request structure and, upon success, modify the metadata as specified by the request structure, - have the secure guest instance retrieve a secret object derived from the retrievable secret from the trusted firmware, and - have the secure guest instance use the retrieved secret object to personalize the secure guest instance.

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

16. The system according to claim 14, - wherein the request structure includes a measured value of an image of the secure guest that transmitted the request structure, and - Among them, causing the one or more processors to have the trusted firmware reject the transmitted request structure when the measured value of the boot image of the secure guest does not match the measured value of the image.

17. The system according to claim 14 or 15, - wherein the request structure includes a Universally Unique Identifier (UUID) of the secure guest, and - Among them, causing the one or more processors to have the trusted firmware reject the request structure when the UUID of the secure guest that transmitted the request structure does not match the UUID in the request structure.

18. The system according to one of claims 14 to 17, wherein, The request structure includes encrypted data that can only be decrypted by the trusted firmware.

19. The system according to any one of claims 14 to 18, - wherein the encrypted data of the request structure includes an extended secret, and - Among them, causing the one or more processors to have the trusted firmware reject any request structure received after a first request structure whose extended secret does not match the extended secret of the received first request structure.

20. The system according to claim 18, wherein, The data of the request structure is encrypted, and wherein the modification of the metadata of the secure guest includes adding some of the encrypted data in the encrypted data as the secret to the metadata.

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

22. The system according to one of claims 14 to 21, wherein, The secret to be added to the metadata of the secure guest included in the request structure can be marked as retrievable, such that the trusted firmware returns the secret object in response to a get-retrievable secret request issued by the secure guest only when the secret is marked as retrievable.

23. The system according to claim 22, - wherein, in the request structure, each retrievable secret is associated with a secret reference, and - Among them, retrieving the secret object associated with the secret reference from the trusted firmware is implemented by a retrieval interface of the trusted firmware that takes the secret reference as an input.

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

25. A computer program product for personalizing a secure guest instance from a general boot image using a trusted firmware that maintains metadata of the secure guest instance, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to: - pass a request structure from the secure guest instance to the trusted firmware for modifying the metadata of the secure guest instance and establishing at least one retrievable secret specific to the secure guest instance in the metadata of the secure guest instance, - have the trusted firmware verify the request structure and, upon success, modify the metadata as specified by the request structure, - have the secure guest instance retrieve a secret object derived from the retrievable secret from the trusted firmware, and - have the secure guest instance use the retrieved secret object to personalize the secure guest instance.

Images