Updating secure guest metadata for specific guest instances

Abstract

A method of securely modifying metadata of a secure visitor instance using firmware that maintains the metadata of the secure visitor personalized by an initialization code is disclosed. The method includes launching a secure guest instance using a hypervisor, receiving, by the secure guest instance, user-specific data, and personalizing, by the secure guest instance, the secure guest instance using the user-specific data. The method further includes receiving, by the secure guest instance, a request structure for modifying the metadata of the secure guest instance, partially verifying, by the secure guest instance, the request structure using the user-specific data, and passing, upon successful verification, the request structure to the trusted firmware for modifying the metadata of the secure guest instance, and validating the request structure by the trusted firmware and modifying the metadata as specified by the request structure upon success.

Description

Technical Field

[0001] The present invention generally relates to a method for modifying metadata of a secure guest instance, and more particularly, to a computer-implemented method for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata of a secure guest instance personalized by initialization code, wherein the secure guest instance is derived from a general boot image. The present invention also relates to a related security system and a computer program product for secure modification of metadata of a secure guest instance. Background Art

[0002] The security of data and communication channels remains one of the top priorities in the management of enterprise IT (Information Technology). This is necessary not only due to government regulations (e.g., GDPR, EU General Data Protection Regulation), but also because companies that cannot always reliably protect customer data if customer data records are compromised lose credibility, so sales and profits can be avoided. In addition, depending on the country where the data breach occurs, fines may need to be paid. It has been proven that the provision of data protection and secure computing platforms is not just a software issue, it also involves 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-level computing environments, such as those used in the financial, insurance, or government industries, it must be possible to prove from a technical perspective that the probability of a data breach being blocked is very high. This may require some additional high-tech components and support processes. However, the associated success in terms of data security is worth the extra effort.

[0003] These ideas also apply to trusted and / or confidential computing environments, where secrets (such as encryption 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, also in such computing environments, leakage of basic security rules (such as exposure of secret keys or use of secret keys for secure guest images by the hypervisor) remains possible. This is also possible in environments where hardware security modules (HSMs) have been used for a considerable period of time.

[0004] There are already some disclosures in the context of computer-implemented methods suitable for personalizing a secure guest instance according to a general boot image using a trusted firmware that maintains metadata of the secure guest instance. Document US2020 / 0076607A1 describes how to securely maintain secrets on a virtual computer system by configuring a dedicated virtual machine to represent an application management and maintenance sequence. When an application requests access to a secret, the control domain verifies with the dedicated virtual machine that the application is authorized to make the request and that the application has not been compromised prior to the request.

[0005] There are already some concepts related to secure computing: Document US2020 / 0076607A1 describes how to securely maintain secrets on a virtual computer system by configuring a dedicated virtual machine to manage and maintain sequences on behalf of an application. When an application requests access to a secret, the control domain combines with the dedicated virtual machine to verify that the application is authorized to make the request and that the application has not been compromised before making the request.

[0006] In addition, document US2020 / 0159940A1 describes a method for sharing secret data among multiple containers. Here, in response to the initial boot of an operating system instance of a container, a unique operating system identifier is generated for the operating system instance. Authorization is given to store the unique operating system identifier in a reserved area of a secure storage device. In addition, in response to a request from the operating system instance to access secret data and the secure storage device, authorization is given to determine whether the unique operating system identifier is stored in the secure storage device.

[0007] Problems in such confidential computing environments can be identified in the context of the image of a secure guest to be executed on a hypervisor. For example, a user who has obtained ownership of a secure guest instance launched using a general secure guest image provided by a software vendor wants to modify the metadata of the secure guest instance, where the metadata can only be accessed by trusted firmware and is related to a specific secure guest instance owned by the user. In this case, it must be impossible to steal data including secrets using the stolen data and add the secrets to the attacker's secure guest instance; and the attacker must not be able to access data including secrets known to the attacker, which 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.

[0008] Therefore, it may be necessary to provide a secure method between the virtual machine executed on the hypervisor and the trusted firmware such that the virtual machine and its metadata cannot be compromised by an attacker. Summary of the Invention

[0009] According to one aspect of the present invention, a computer-implemented method can be provided for securely modifying the metadata of a secure guest instance using trusted firmware that maintains the metadata of the secure guest instance personalized by initialization code, where the secure guest instance is derived from a general boot image. The method can include starting a secure guest instance using a hypervisor based on the general boot image, receiving user-specific data by the secure guest instance, and personalizing the secure guest instance by the secure guest instance using the user-specific data.

[0010] In addition, the method may include: receiving, by the secure guest instance, a request structure for modifying metadata of the secure guest instance; partially validating, by the secure guest instance, the request structure using the user-specific data; and upon successful validation (i.e., if successfully validated, particularly partially successfully), passing the request structure to the trusted firmware for modifying the metadata of the secure guest instance, wherein the trusted firmware validates the request structure and, upon success, modifies the metadata specified by the request structure.

[0011] According to another aspect of the present invention, a security system for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata of the secure guest instance personalized by initialization code may be provided, wherein the secure guest instance is derived from a general boot image. The system may include a processor and a memory operably coupled to the processor, wherein the memory stores program code portions that, when executed by the processor, cause the processor to be able to start the secure guest instance using a hypervisor based on the general boot image, receive user-specific data using the secure guest instance, and personalize the secure guest instance using the user-specific data using the secure guest instance.

[0012] In addition, the processor may also be enabled to receive, using the secure guest instance structure, a request for modifying metadata of the secure guest instance, partially validate the request structure using user-specific data using the secure guest instance, and upon successful validation (particularly partial success), pass the request structure to the trusted firmware for modifying the metadata of the secure guest instance.

[0013] Last but not least, the processor may also be enabled to use the trusted firmware to validate the request structure and, if successful, modify the metadata specified by the request structure.

[0014] The proposed computer-implemented method for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata of the secure guest instance personalized by initialization code (wherein the secure guest instance is derived from a general boot image) may provide several advantages, technical effects, contributions, and / or improvements:

[0015] Using the techniques proposed herein, it may become nearly impossible for an unauthorized virtual guest system or instance to change metadata in the trusted firmware of a confidential computing environment. The proposed architecture generally and ultimately prohibits change requests to the metadata of another secure guest instance.

[0016] As a result, it is still possible to modify the metadata associated with a specific secure guest instance, but only through that specific secure guest instance. However, after a freeze request, no one can modify the metadata of a specific secure guest instance (including the specific secure guest instance).

[0017] This can in turn allow the startup process of a secure guest instance to be split into two parts: (i) a first part where the metadata is modified and where access to the secure guest instance is very limited, and (ii) a second part where the metadata may be fixed but more general access to the secure guest instance is allowed, such that an attack via the more general access path cannot modify any metadata.

[0018] In the case where the hypervisor that forms the operational basis of a virtual machine or secure guest instance may be compromised, this can also increase the operational security of the confidential computing environment. This can equally apply to the communication channel between a secure guest instance and the relevant metadata area of the trusted firmware. If this communication channel may be compromised, it is architecturally impossible to change these metadata from and to another secure guest instance.

[0019] Additionally, the proposed method can allow the metadata of a secure guest instance to be modified only by the owner of the data used to obtain ownership of the secure guest instance by requiring an encrypted link between the request structure and the user data, which in turn may require the creator of the request structure and the creator of the data used to obtain ownership of the secure guest instance to share a secret.

[0020] In the following, additional embodiments of the inventive concept will be described, which are applicable to methods as well as systems.

[0021] (2) According to an advantageous embodiment of the method, after passing one or more request structures to the trusted firmware, a metadata freeze request (i.e., a request to freeze the metadata) can be passed or submitted by the secure guest instance to the trusted firmware, whereupon the trusted firmware can reject all subsequent requests from the secure guest instance to modify its metadata. Now, no unauthorized changes to the metadata are accepted. Thus, no other virtual machine or secure guest instance can compromise the metadata of the secure guest image that has initiated a first metadata change for its own use.

[0022] (3) According to another advantageous embodiment, the method may further include allowing general access to the secure guest instance by the secure guest instance only after passing the freeze metadata request to the trusted firmware. Thus, in particular, input / output access (e.g., via a network) may not be performed before sending / receiving the freeze request. As a technical result, it is not possible for a user or virtual machine, such as a hacker controlling these virtual machines, to make any unauthorized metadata changes. Now, even if an attacker is able to penetrate the barrier of the general input / output channels of all secure guest instances (e.g., via a network), and even if the attacker is able to manipulate the partial integrity test program used by the request structure, it is technically impossible to perform such an attack.

[0023] According to a preferred embodiment of the method, the startup of the secure guest instance may further include the hypervisor passing the general boot image and protected metadata to the trusted firmware, and then the trusted firmware starting the secure guest image based on the metadata. This may be regarded as equivalent to constructing or generating the secure guest instance.

[0024] According to a useful embodiment of the method, each request structure may be integrity-protected, and the request structure may be fully (i.e., completely) verifiable only by the trusted firmware - that is, in the sense of the entire request structure rather than just a part. In the sense that only a part of the request structure may be verifiable, for example, by the guest instance, other components may be able to partially verify the request structure. In particular, the integrity protection may ensure that the replacement of the user data field in the request structure will be detected by the trusted firmware.

[0025] According to an advanced embodiment of the method, the request structure may include an image measurement value, and the method may include: if the measurement value of the boot image of the secure guest instance does not match the image measurement value, the trusted firmware rejecting the passed request structure. Thus, the image measurement value may be any sequence of characters or numbers or a mixture thereof, even any sequence of digital bits. Therefore, the request structure may be used only with a secure guest instance starting from a specific secure guest image, which determines the personalized process and partial verification process available to the secure guest instance.

[0026] According to an interesting embodiment of the method, the request structure may include encrypted data, which may be decrypted only by the trusted firmware. Technically, it may now be very difficult, if not impossible, to attack the transmission (i.e., passing) of the secret in the encrypted part of the request structure from the secure guest instance to the trusted firmware. In addition, even if the hypervisor is architecturally located between the secure guest instance and the trusted firmware, the hypervisor is excluded from learning all the contents of the request structure.

[0027] According to an allowed implementation of the method, the encrypted data of the request structure may include a secret of the metadata to be added to the secure guest instance. Such a secret may be used during subsequent processes executed by the secure guest instance. Such a secret may be protected against access by intruders of the secure guest instance. The firmware may use the secret in the metadata to associate a device (e.g., HSM) with the secure guest instance. Technically, this can significantly reduce the chance that an attacker can directly steal the secret from the secure guest instance.

[0028] According to another alternative embodiment of the method, the request structure may include a plaintext user data field that will not be interpreted by the trusted firmware while still undergoing an integrity check of the request structure performed by the trusted firmware. Such a plaintext user data field may be used to ensure that the author of the request structure is also the author of the user-specific data presented to the secure guest instance by ensuring that the subject of the data on which the secure guest instance will be personalized and the author of the request structure share a common secret. This depends on the trust model used meaning that they trust each other or are the same entity.

[0029] According to an additional useful embodiment of the method, the user data field in the request structure may include user data and an integrity tag, where the user data may be encryptedly linked to the user-specific data. The two may be the same, or the user data may be a hash value, a message authentication code, or a signature of the user-specific data. In this embodiment, the following feature may also be useful: the integrity tag (e.g., digital signature) may encryptly link the user data to data outside the user data field on the request structure. Thus, the integrity tag may be used as a signature for all fields of the request structure other than the integrity tag itself. This may be an additional security feature for the request structure during transformation (e.g., on the way from the secure guest instance to the trusted firmware).

[0030] According to an enhanced implementation of the method, partial verification of the request structure by the secure guest instance may include verifying the encrypted link between the user-specific data and the user data in the request structure. This may be performed, for example, by demonstrating that the user data is a hash value of the user-specific data. This embodiment may also include verifying the encrypted link between the user data in the request structure and data outside the user data field in the request structure. This may be performed by demonstrating that the integrity tag in the user data field is a signature for all fields of the request structure other than the integrity tag field itself. Thus, a link is established between the user-specific data and the use of the data and the user data with the request structure. Thus, there is a digital link between the user-specific data and the request structure itself. Thus, if such a link cannot be demonstrated, the request structure should not be used with the user-specific data, which can further increase the security of the technical concept and security architecture proposed herein.

[0031] According to an additional embodiment of the method, user-specific data may include a secret key. This may be used in the context of a trusted firmware and / or a secure guest instance. For example, the public key used may be used to verify a digital signature. This may allow verification of an encrypted link between user data and data outside the user data field in a request structure. To this end, the matching private key belonging to the signature key should belong to the creator of the user-specific data and the request structure. Using such a process, a secure guest instance may prove that the user-specific data and the request structure originate from the same sender or generator by verifying an integrity tag in the user data field.

[0032] In addition, an embodiment may take the form of a related computer program product accessible from a computer-usable or computer-readable medium that provides program code for use 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 may be any device that can contain components for storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. BRIEF DESCRIPTION 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, those skilled in the art will infer from the above and following descriptions that, unless otherwise stated, any combination between features related to different subject matters, in particular any combination between the features of method-type claims and the features of apparatus-type claims, is also considered to be disclosed within this document, in addition to any combination of features belonging to one type of subject matter.

[0034] Based on the examples of the embodiments to be described below, the above and other aspects of the present invention will be apparent and will be explained with reference to the examples of the embodiments. The present invention is not limited thereto.

[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 securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata of the secure guest instance personalized by initialization code, wherein the secure guest instance originates from a general boot image, is shown.

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

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

[0039] Figure 4 An embodiment showing an add secret request structure according to an embodiment.

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

[0041] Figure 6 A block diagram showing an embodiment of a security system of the present invention for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata of a secure guest instance personalized by initialization code, where the secure guest instance is derived from a general boot image.

[0042] Figure 7 Shows an embodiment of a computing system including a security system according to Figure 6 of. Detailed Description

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

[0044] The term "trusted computing environment" may represent a computing environment in which a hypervisor on any system management software having user interface components cannot access any plaintext content or other state of a virtual machine.

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

[0046] The term "personalize" may here represent that a secure guest instance booted from a general boot image can be changed in such a way that it may lose its general state, i.e., it can become a special or even unique executable image, e.g., by adding (TLS / ssh) signature keys and / or (volume) encryption / decryption keys, by binding it to a special user (e.g., by setting a password) or specific hardware, etc., to limit its capabilities.

[0047] The term "initialization code" can represent any sequence of digital bits (e.g., a sequence of characters such as a secret key) that can transform a generic boot instance into a personalized unique version that can be used as the bit or character sequence for initializing a secure guest image.

[0048] The term "generic boot image" can 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 can provide a boot image for general use, e.g., after downloading it from a software repository. That is, each user can download the same generic boot image and use it to start a generic secure guest that can be personalized during operation.

[0049] The term "trusted firmware" (Trusted FW or TFW) can represent a component deeply embedded in the hardware of a computing (mainframe) system that cannot be accessed by software controlled by any other user. The trusted firmware can have a predefined and highly secure application programming interface in order to protect the functions 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 protected by encryption.

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

[0051] The term "hypervisor" can represent a well - defined type of computer software or firmware that creates and runs virtual machines or software containers. Thus, multiple virtual machines / software containers can be executed in parallel without any risk of cross - reference. Errors in a virtual machine may not cause any damage to another virtual machine. Each virtual machine can have a defined address space.

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

[0053] The term "modifying 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 an indication of how to modify the metadata. This can also be effective for the deletion of metadata in the trusted firmware or the change of existing metadata. It can also be noted that the add metadata request structure or the change metadata request structure can differ from each other in terms of content.

[0054] The term "freezing metadata" can mean that it is technically impossible to change the metadata after a relevant freezing metadata request from a secure guest instance to the trusted firmware of a computer system. Advantageously, such a freezing metadata request can be executed before the secure guest instance can be opened for any other general I / O.

[0055] The term "protected by integrity" 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, measurements (e.g., the total number of bytes, cryptographic hash, message authentication code, or signature of the data structure, such as the boot image of a virtual machine) or the UUID of the data structure can be used.

[0056] The term "image measurement" can mean the measurements just mentioned in the above paragraph.

[0057] The term "encrypted data" can mean data that is not available in plain text but has been modified using a predefined key. The encrypted data can be made readable in plain text again after the decryption process.

[0058] The term "encrypted linked" can mean that two pieces of data belong together and can be proven to belong together by an encrypted link. The means to establish such an encrypted link can be a cryptographic hash, a message authentication code (MAC), or a digital signature. A typical way to link two pieces of data is to hash, MAC, or sign the concatenation of the two pieces of data and make the resulting integrity tag available with the two pieces of data.

[0059] In the following, a detailed description of the drawings will be given. All the descriptions in the figures are schematic. First, a block diagram of an embodiment of a computer-implemented method of the present invention for securely modifying the metadata of a secure guest instance using a trusted firmware that maintains the metadata personalized by initialization code is given, where the secure guest instance is derived from a general boot image. Thereafter, additional embodiments and embodiments of a related security system for securely modifying the metadata of a secure guest instance will be described.

[0060] Figure 1A block diagram of a preferred embodiment of a computer-implemented method 100 for securely modifying metadata of a secure guest instance personalized by initialization code is shown. Thus, the secure guest instance is derived from a general boot image. A trusted firmware that maintains the metadata of the secure guest instance is used to support the complete method. And the method should be part of a trusted computing environment as defined above.

[0061] Method 100 includes starting 102 a secure guest instance using a hypervisor based on a general boot image, and receiving 104 user-specific data by the secure guest instance. These can be used in the next step, i.e., the next element of method 100, i.e., personalizing 106 the secure guest instance by the secure guest instance using the user-specific data. Thus, the secure guest instance will personalize itself.

[0062] In addition, method 100 includes receiving 108 by the secure guest instance a request structure for modifying the metadata of the secure guest instance. There is no need to give a special source of the request structure as it can be received from anywhere, e.g., read from a file, received via a network connection, etc.

[0063] Furthermore, method 100 includes partially verifying 110 the request structure by the secure guest instance, particularly in the sense that it is not necessary to verify the complete request structure as the user data field belongs to the rest of the request. Thus, the user-specific data is used. After successful partial verification, method 100 includes passing 112 the request structure (particularly by the secure guest instance) to the trusted firmware to modify the metadata of the secure guest instance.

[0064] Last but not least, method 100 includes verifying 114 (in the sense of performing an integrity check directly after reception) the complete request structure by the trusted firmware. Upon successful verification, method 100 includes modifying 116 the metadata as specified by the request structure.

[0065] It can be noted that the secure guest instance performs only a partial integrity check based on an integrity check included in the user data field, while the trusted firmware performs an integrity check based on an integrity tag related to the entire request structure.

[0066] Figure 2 A block diagram 200 showing components of a potential security attack scenario is shown. A computer system 202 may include an integrated trusted firmware 204, on which a hypervisor 210 operates. The hypervisor 210 builds an operating foundation for a secure virtual guest-1 212 and other secure virtual guest instances such as a secure virtual guest-2 218. Also shown are the metadata (MD) 206 of the secure guest-1 212 and the metadata 208 of the secure guest-2 218.

[0067] These metadata can be modified ("permitted" 216) according to a security request structure (e.g., in the sense of "add", "change", "delete"). In the case of the secure virtual guest-1 212, this is the security request structure 214.

[0068] However, if the secure virtual guest-2 218 attempts to modify its own metadata 208 in the trusted firmware 208 using the security request structure 214, this should not be permitted, as indicated by the access threat 220 in the figure.

[0069] Equivalently, it should also be impossible for the secure virtual guest-1 212 to modify the metadata 206 of the secure guest-1 212 using another request structure 226 protected by another key. This is also indicated as not permitted 222.

[0070] Figure 3 A block diagram 300 of an embodiment including components facilitating the concepts presented herein is shown. As Figure 2 shown, a computer system 202, trusted firmware 204, and metadata 206 of a secure guest 212 (which is executing on the management program 210) are shown. Additionally, a general boot image 314 for launching 316 the secure guest instance 212 is shown. Also shown is a request submission code 302 and a secure add secret request structure 304, which includes a user data measurement 306 and a new secret to be added to the secure guest metadata 206, as well as user-specific data 310. The request submission code can be used to submit request structures for modifying metadata (including the add secret request structure) and requests for freezing metadata. Additional details regarding the add secret request structure will be discussed in the Figure 4 context of.

[0071] Figure 4 An embodiment of an add secret request structure 400 according to an embodiment is shown, and the metadata of the trusted firmware (compare Figure 3 ) should be changed using this add secret request structure 400. These initial metadata are provided with protected metadata. The request structure 400 itself includes multiple elements: the user data field 402 includes user data 310 and an integrity label 404; the image measurement 306; a temporary public client key 406; and a key slot memory 408, which includes one key for each host system.

[0072] Each of these key slots includes a hash value of the public host key 418 and the request protection key (RPK) 416 encrypted using the public host key 418 and a private host key (not shown). The private host key is securely stored in the trusted firmware and is only accessible by the trusted firmware. The area 412 including data (e.g., new secrets) for the metadata update 308 is encrypted by the request protection key (RPK) 416. In addition, the add secret request structure 400 includes an integrity tag 410. This is used for integrity checking of the complete request structure, denoted by the reference numeral 414. Also here, the RPK 412 is used as a protection mechanism, e.g., as an HMAC or AES-GCM key.

[0073] The inner part of the request structure (summarized by the left bracket of the two shown brackets) is integrity protected by the integrity tag 404 of the user data field 402. This inner part includes all of the request structure except for the two integrity tags 404 and 410. Thus, the request structure 400 can be partially integrity checked by the secure guest instance using the user data integrity tag 404, or can be fully integrity checked (separately from the integrity tag 410) by the trusted firmware using the integrity tag 410 of the complete request structure and the RPK 416, which can only be revealed by the trusted firmware.

[0074] Figure 5 A flowchart 500 of an activity sequence closer to an implementation of the concepts presented herein is shown. First, a user of the secure guest instance provides some user-specific data that can be used to personalize the general secure guest. In addition, the use of the secure guest instance can also construct an add secret request structure 502. Next, the user data and the add secret request structure are loaded into a running (i.e., executing) instance 504 of the general secure guest image.

[0075] Then, the secure guest instance uses the user data to personalize the secure guest instance for use only by that user 506. This represents the self-personalization described previously. As a next step, the secure guest instance authenticates the user data in the request structure against the loaded user-specific data and partially verifies the request structure based on the key material included in the user-specific data and the integrity tag in the user data field of the request structure 508. Upon successful verification, the request structure is passed to the trusted firmware 510.

[0076] In addition, the trusted firmware checks the integrity of the request structure and, if successful, unpacks the request structure and modifies the metadata of the relevant secure guest instance defined by the request structure 512.

[0077] Finally but equally importantly, the secure guest instance issues a request to the trusted firmware (FW) to freeze the metadata 514 of the secure guest instance before opening any general-purpose I / O channels. Thereby, the instantiation of the secure guest instance is completed.

[0078] Figure 6 A block diagram of an embodiment of a security system of the present invention for securely modifying the metadata of a secure guest instance using a trusted firmware that maintains the metadata of the secure guest instance personalized by initialization code is shown, where the secure guest instance is derived from a general boot image.

[0079] The security system includes a processor 602 and a memory 604 operatively coupled to the processor 602, where the memory 604 stores program code portions that, when executed by the processor 602, enable the processor 602 to start a secure guest instance (specifically, via a start module 606) based on a general boot image using a hypervisor (e.g., hypervisor unit 608). The processor 602 is also capable of receiving user-specific data using a receiver 610 of the secure guest instance and personalizing the secure guest instance using the user-specific data, for example, using a personalizer module 612 of the secure guest instance.

[0080] Then, the processor 602 of the security system 600 is enabled to receive a request structure for modifying the metadata of the secure guest instance (e.g., using the receiver 610 of the secure guest instance) and to partially verify the request structure using the user-specific data (e.g., using a validator 614 of the secure guest instance).

[0081] Upon successful verification, the processor 602 of the security system 600 is also capable of passing the request structure to the trusted firmware 616 (comparison 204, Figure 2 、 Figure 3 ), to modify the metadata of the secure guest instance.

[0082] In addition, the processor 602 is enabled to verify the request structure, for example, using a trusted firmware module. Upon successful verification, the processor 602 is enabled to modify the metadata specified by the request structure, for example, using a modification 618.

[0083] It should also be mentioned that all functional units, modules, and functional blocks (specifically, processes on 602, memory 604, start module 606, hypervisor unit 608, receiver 610, personalizer unit 612, validator 614, trusted firmware module 616 (optionally, also including one or more processors), and modification unit 618) can 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 can be linked to an internal system bus system 620 for selective signal or message exchange.

[0084] Aspects of the present disclosure are described by narrative 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 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.

[0085] A computer program product embodiment (CPP embodiment or CPP) is a term used in the present disclosure to refer to any collection of one or more storage media (also referred to as media) that are jointly included in a collection of one or more storage devices, where the one or more storage devices jointly 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 used by a computer processor. Without limitation, computer-readable storage media can be electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any suitable combination of the foregoing. Some known types of storage devices that include these media include magnetic 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, mechanical encoding devices (such as punched cards or pits / ridges formed in the main surface of a disc), or any suitable combination of the foregoing. As the term is used in the present disclosure, computer-readable storage media should not be construed as storage devices in the form of transient signals themselves (such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses transmitted through an optical fiber cable, electrical signals transmitted through a wire, and / or other transmission media). As will be understood by those skilled in the art, data typically moves at some incidental point 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 transient because the data is not transient when stored.

[0086] Figure 7 A computing environment 700 is shown that includes an environment that uses trusted firmware that maintains metadata for a secure guest instance 750 to execute at least some of the computer code involved in performing the methods of the present invention, such as computer-implemented methods for securely modifying the metadata of a secure guest instance personalized by initialization code.

[0087] In addition to the block 750, the computing environment 700 further 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 set of processors 710 (including processing circuitry 720 and cache 721), a communication fabric 711, volatile memory 712, a permanent storage device 713 (including an operating system 722 and the block 750 as described above), a set of peripheral devices 714 (including a user interface (UI), a set of devices 723, a storage device 724, and a set of Internet of Things (IoT) sensors 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 set of host physical machines 742, a set of virtual machines 743, and a set of containers 744.

[0088] 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 now known or to be developed in the future that is capable of running programs, accessing a network, or querying a database such as the remote database 730. As is well understood in the computer technology field and depending on the technology, the execution of computer-implemented methods may be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 700, the discussion focuses 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, even if it is not shown in the Figure 7 cloud in the figure. On the other hand, the computer 701 is not required to be in the cloud, except to the extent that may be affirmatively indicated.

[0089] The set of processors 710 includes one or more computer processors of any type now known or to be developed in the future. The processing circuitry 720 may be distributed across multiple packages, for example, multiple coordinated integrated circuit chips. The processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. The cache 721 is a memory located in the (one or more) processor chip packages and is generally used for data or code that should be made available for quick access by threads or cores running on the set of processors 710. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the set of processors may be located "off-chip". In some computing environments, the set of processors 710 may be designed to work with qubits and perform quantum computing.

[0090] Computer-readable program instructions are typically loaded onto a computer 701 so that a set of processors 710 of the computer 701 execute a series of operational steps to implement a computer-implemented method such that the instructions so executed will instantiate the method specified in the flowchart and / or narrative description of the computer-implemented method included 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 set of processors 710 to control and direct the execution of the method of the present invention. In computing environment 700, at least some of the instructions for executing the method of the present invention may be stored in block 750 in a permanent storage device 713.

[0091] The communication structure 711 is a signal conduction path that allows the various components of the computer 701 to communicate with each other. Typically, this structure is made up of switches and conductive paths (such as 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.

[0092] The volatile memory 712 is any type of volatile memory known now 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, but alternatively or additionally, the volatile memory can be distributed across multiple packages and / or be located external to the computer 701.

[0093] The permanent storage device 713 is any form of non-volatile storage device for a computer known now or developed in the future. The non-volatility of this storage device means that the stored data is retained whether or not power is supplied to the computer 701 and / or directly to the permanent storage device 713. The permanent storage device 713 can be a read-only memory (ROM), but typically at least a portion of the permanent storage device allows data to be written, deleted, and rewritten. Some common forms of permanent storage devices include magnetic disks and solid-state storage devices. The 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 included in block 750 typically includes at least some of the computer code involved in executing the method of the present invention.

[0094] The peripheral device set 714 includes the peripheral device set 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 a Bluetooth connection, a near field communication (NFC) connection, a connection by a cable (such as a universal serial bus (USB) type cable), a plug-in connection (e.g., a secure digital (SD) card), a connection through a local communication network, and even a connection through a wide area network such as the Internet. In various embodiments, the UI device set 723 may include components such as a display screen, a speaker, a microphone, wearable devices (such as goggles and smart watches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage device 724 is an external storage device (such as an external hard disk drive) or a plug-in storage device (such as an SD card). The storage device 724 can be permanent 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 needs to have a large amount of storage (e.g., in the case of locally storing and managing a large database on the computer 701), the storage can 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 distributed computers). The IoT sensor set 725 consists of 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.

[0095] The network module 715 is a collection of computer software, hardware, and firmware that allows the computer 701 to communicate with other computers through 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 web 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 (e.g., 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 several 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 through a network adapter card or a network interface included in the network module 715.

[0096] The WAN 702 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances via any technology, now known or hereafter developed, for transmitting computer data. In some embodiments, the WAN may be replaced and / or supplemented by a local area network (LAN) (such as a Wi-Fi network) designed to transmit data between devices located in a local area. 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.

[0097] 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 an end user, the recommendation will typically be delivered from the network module 715 of the computer 701 to the EUD 703 via the WAN 702. 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, heavy client, mainframe computer, desktop computer, etc.

[0098] 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 the machine(s) that collect and store helpful and 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.

[0099] A public cloud 705 is any computer system that can be used by multiple entities, which provides on-demand availability of computer system resources and / or other computing capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically utilizes the sharing of resources to achieve consistency and economies of scale. The direct and 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 set of host physical machines 742, which is the totality of physical computers in and / or available for the public cloud 705. The virtual computing environment (VCE) typically takes the form of virtual machines from the set of virtual machines 743 and / or containers from the set of containers 744. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after the instantiation of the VCE. The cloud orchestration module 741 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages the active instantiations of the VCE deployment. The gateway 740 is a collection of computer software, hardware, and firmware that allows the public cloud 705 to communicate via the WAN 702.

[0100] Some further explanations of the virtualized computing environment (VCE) will now be provided. The VCE can be stored as an "image". A new active instance of the VCE can be instantiated from the image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to the operating system feature where the kernel allows for 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 the resources of that computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of the container and the devices allocated to the container, which is a feature known as containerization.

[0101] The private cloud 706 is similar to the public cloud 705, except that the computing resources are only available for 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 (e.g., private, community, or public cloud types) that are typically implemented by different providers. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable 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 the larger hybrid cloud.

[0102] It should also be mentioned that the security system (600, contrast Figure 6 ) for the secure modification of the metadata of the secure guest instance personalized by the initialization code can be the operating subsystem of the computer 701 and can be attached to the internal bus system of the computer.

[0103] 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 intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that when used in this specification, the terms "comprises" and / or "comprising" 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 groups thereof.

[0104] All apparatus or steps in the appended 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 presented for purposes of illustration and description, but is not intended to be exhaustive or to limit 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 embodiments were chosen and described in order to best explain the principles of the invention and its practical application, and to enable others of ordinary skill in the art to understand the invention with various modifications as are suited to the particular use contemplated.

[0105] In short, the concept of the present invention can be summarized in the following clauses:

[0106] 1. A computer-implemented method for securely modifying metadata of a secure guest instance whose metadata is personalized by initialization code using a trusted firmware, wherein the secure guest instance is derived from a general boot image, the method comprising

[0107] - Starting a secure guest instance using a hypervisor based on the general boot image,

[0108] - Receiving user-specific data by the secure guest instance,

[0109] - Personalizing the secure guest instance by the secure guest instance using the user-specific data,

[0110] - Receiving a request structure for modifying the metadata of the secure guest instance by the secure guest instance,

[0111] - Partially validating the request structure by the secure guest instance using the user-specific data and, upon successful validation

[0112] - Passing the request structure to the trusted firmware for modifying the metadata of the secure guest instance,

[0113] - Validating the request structure by the trusted firmware and, upon success

[0114] - Modifying the metadata specified by the request structure.

[0115] 2. The method according to clause 1, wherein after passing one or more request structures to the trusted firmware

[0116] - Passing a metadata freeze request from the secure guest instance to the trusted firmware, whereupon the trusted firmware rejects all subsequent requests from the secure guest instance to modify its metadata.

[0117] 3. The method according to clause 2, further comprising

[0118] - Allowing general access to the secure guest instance by the secure guest instance only after passing a freeze metadata request to the trusted firmware.

[0119] 4. The method according to any of the preceding clauses, wherein the start of the secure guest instance comprises

[0120] - Passing the general boot image and protected metadata by the hypervisor to the trusted firmware, and

[0121] - Starting a secure guest image by the trusted firmware based on the metadata.

[0122] 5. The method according to any one of the preceding clauses, wherein each request structure is integrity protected and wherein the request structure can only be fully verified by the trusted firmware.

[0123] 6. The method according to any one of the preceding clauses, wherein the request structure includes an image measurement value and wherein the method includes

[0124] If the measurement value of the boot image of the secure guest instance does not match the image measurement value, the transmitted request structure is rejected by the trusted firmware.

[0125] 7. 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.

[0126] 8. The method according to clause 7, wherein the encrypted data of the request structure includes a secret to be added to the metadata of the secure guest instance.

[0127] 9. The method according to any one of the preceding clauses, wherein the request structure includes a plaintext user data field that will not be interpreted by the trusted firmware while still undergoing the integrity check of the request structure performed by the trusted firmware.

[0128] 10. The method according to clause 9, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is encryptedly linked to the user-specific data and wherein the integrity tag is encryptedly linked to the user data and the data outside the user data field in the request structure.

[0129] 11. The method according to clause 10, wherein partially verifying the request structure by the secure guest instance includes

[0130] - verifying the encrypted link between the user-specific data and the user data in the request structure, and

[0131] - verifying the encrypted link between the user data in the request structure and the data outside the user data field in the request structure.

[0132] 12. The method according to clause 10, wherein the user-specific data includes a key.

[0133] 13. A security system for securely modifying the metadata of a secure guest instance using a trusted firmware that maintains the metadata of the secure guest instance personalized by initialization code, wherein the secure guest instance is derived from a general boot image, the security system includes

[0134] - A processor and a memory operably coupled to the processor, wherein the memory stores program code portions that, when executed by the processor, enable the processor to

[0135] - Start a secure guest instance using a hypervisor based on the general boot image,

[0136] - Use the secure guest instance to receive user-specific data,

[0137] - Use the secure guest instance to personalize the secure guest instance using the user-specific data,

[0138] - Use the secure guest instance to receive a request structure for modifying the metadata of the secure guest instance,

[0139] - Use the secure guest instance to partially verify the request structure using the user-specific data portion, and upon successful verification

[0140] - Pass the request structure to the trusted firmware for modifying the metadata of the secure guest instance,

[0141] - Use the trusted firmware to verify the request structure, and upon success

[0142] - Modify the metadata specified by the request structure.

[0143] 14. The security system according to clause 13, wherein after passing one or more request structures to the trusted firmware, the processor is further enabled to

[0144] - Use the secure guest instance to pass a metadata freeze request to the trusted firmware, whereupon the trusted firmware, under the control of the processor, rejects all subsequent requests from the secure guest instance to modify its metadata.

[0145] 15. The security system according to clause 14, further comprising

[0146] - Allow general access to the secure guest instance only after passing a freeze metadata request to the trusted firmware.

[0147] 16. The security system according to any one of clauses 13 to 15, wherein during startup of the secure guest instance, the processor is further enabled to:

[0148] - Use the hypervisor to pass a general boot image and protected metadata to the trusted firmware, and

[0149] - Use the trusted firmware to start a secure guest image based on the metadata.

[0150] 17. The security system according to any one of clauses 13 to 16, wherein each request structure is integrity-protected and wherein the request structure can only be fully verified by the trusted firmware.

[0151] 18. The security system according to any one of clauses 13 to 17, wherein the request structure includes an image measurement value, and wherein the processor is also enabled to

[0152] Use the trusted firmware to reject the transmitted request structure when the measurement value of the boot image of the secure guest instance does not match the image measurement value.

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

[0154] 20. The security system according to clause 19, wherein the encrypted data of the request structure includes a secret to be added to the metadata of the secure guest instance.

[0155] 21. The security system according to any one of clauses 13 to 20, wherein the request structure includes a plaintext user data field that will not be interpreted by the trusted firmware while still undergoing the integrity check of the request structure performed by the trusted firmware.

[0156] 22. The security system according to clause 21, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is encryptedly linked to the user-specific data, and wherein the integrity tag is encryptedly linked to the user data and the data outside the user data field in the request structure.

[0157] 23. The security system according to clause 22, wherein during partial verification of the request structure by the processor using the secure guest instance, the processor is also enabled to:

[0158] - Verify the encrypted link between the user-specific data and the user data in the request structure, and

[0159] - Verify the encrypted link between the user data in the request structure and the data outside the user data field in the request structure.

[0160] 24. The security system according to clause 22, wherein the user-specific data includes a key.

[0161] 25. A computer program product for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata personalized by initialization code, wherein the secure guest instance is derived from a common boot image, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems

[0162] - Start the secure guest instance using a hypervisor based on the common boot image,

[0163] - Use the secure guest instance to receive user-specific data,

[0164] - Use the secure guest instance to personalize the secure guest instance using the user-specific data,

[0165] - Use the secure guest instance to receive a request structure for modifying the metadata of the secure guest instance,

[0166] - Use the secure guest instance to partially verify the request structure using the user-specific data and, upon successful verification

[0167] - Pass the request structure to the trusted firmware for modifying the metadata of the secure guest instance,

[0168] - Use the trusted firmware to verify the request structure and, upon success

[0169] - Modify the metadata specified by the request structure.

Claims

1. A computer-implemented method for securely modifying metadata of a secure guest instance whose metadata is personalized by initialization code using a trusted firmware, wherein the secure guest instance is derived from a general boot image, the method comprising - starting a secure guest instance using a hypervisor based on the general boot image, - receiving user-specific data by the secure guest instance, - personalizing the secure guest instance by the secure guest instance using the user-specific data, - receiving a request structure for modifying the metadata of the secure guest instance by the secure guest instance, - partially validating the request structure by the secure guest instance using the user-specific data and, upon successful validation - passing the request structure to the trusted firmware for modifying the metadata of the secure guest instance, - validating the request structure by the trusted firmware and, upon success - modifying the metadata specified by the request structure.

2. The method according to claim 1, comprising, after passing one or more request structures to the trusted firmware - passing a metadata freeze request from the secure guest instance to the trusted firmware, whereupon the trusted firmware rejects all subsequent requests by the secure guest instance to modify its metadata.

3. The method according to claim 2, further comprising - allowing general access to the secure guest instance by the secure guest instance only after passing a freeze metadata request to the trusted firmware.

4. The method according to any one of claims 1 to 3, wherein the starting of the secure guest instance comprises - passing a general boot image and protected metadata from the hypervisor to the trusted firmware, and - starting a secure guest image by the trusted firmware based on the metadata.

5. The method according to any one of claims 1 to 4, wherein each request structure is integrity-protected and wherein the request structure can only be fully validated by the trusted firmware.

6. The method according to any one of claims 1 to 5, wherein the request structure includes an image measurement value and wherein the method comprises rejecting the passed request structure by the trusted firmware if the measurement value of the boot image of the secure guest instance does not match the image measurement value.

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

8. The method according to claim 7, wherein the encrypted data of the request structure includes a secret to be added to the metadata of the secure guest instance.

9. The method according to any one of claims 1 to 8, wherein the request structure includes a plaintext user data field that will not be interpreted by the trusted firmware while still undergoing an integrity check of the request structure performed by the trusted firmware.

10. The method according to claim 9, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is encryptedly linked to the user-specific data, and wherein the integrity tag is encryptedly linked to the user data and the data outside the user data field in the request structure.

11. The method according to claim 10, wherein the partial verification of the request structure by the secure guest instance includes - verifying the encrypted link between the user-specific data and the user data in the request structure, and - verifying the encrypted link between the user data in the request structure and the data outside the user data field in the request structure.

12. The method according to claim 10, wherein the user-specific data includes a key.

13. A security system for securely modifying metadata of a secure guest instance using a trusted firmware that maintains metadata personalized by initialization code, wherein the secure guest instance is derived from a general boot image, the security system includes - a processor and a memory operatively coupled to the processor, wherein the memory stores program code portions that, when executed by the processor, cause the processor to be able to - start a secure guest instance using a hypervisor based on the general boot image, - receive user-specific data using the secure guest instance, - personalize the secure guest instance using the user-specific data using the secure guest instance, - receive a request structure for modifying the metadata of the secure guest instance using the secure guest instance, - partially verify the request structure using the user-specific data using the secure guest instance, and upon successful verification - pass the request structure to the trusted firmware for modifying the metadata of the secure guest instance, - verify the request structure using the trusted firmware, and upon success - modify the metadata specified by the request structure.

14. The security system according to claim 13, wherein after passing one or more request structures to the trusted firmware, the processor is further enabled to - pass a metadata freeze request to the trusted firmware using the secure guest instance, whereupon the trusted firmware rejects all subsequent requests by the secure guest instance to modify its metadata under the control of the processor.

15. The security system according to claim 14, further including - allowing general access to the secure guest instance by the secure guest instance only after passing a freeze metadata request to the trusted firmware.

16. The security system according to any one of claims 13 to 15, wherein during startup of the secure guest instance, the processor is further enabled to: - pass the general boot image and protected metadata to the trusted firmware using the hypervisor, and - start a secure guest image based on the metadata using the trusted firmware.

17. The security system according to any one of claims 13 to 16, wherein each request structure is integrity-protected and wherein the request structure can only be fully verified by the trusted firmware.

18. The security system according to any one of claims 13 to 17, wherein the request structure includes a measurement value of an image, and wherein the processor is further enabled to use the trusted firmware to reject the transmitted request structure when the measurement value of the boot image of the secure guest instance does not match the measurement value of the image.

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

20. The security system according to claim 19, wherein the encrypted data of the request structure includes a secret to be added to the metadata of the secure guest instance.

21. The security system according to any one of claims 13 to 20, wherein the request structure includes a plaintext user data field that will not be interpreted by the trusted firmware while still undergoing the integrity check of the request structure performed by the trusted firmware.

22. The security system according to claim 21, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is encryptedly linked to the user-specific data, and wherein the integrity tag is encryptedly linked to the user data and the data outside the user data field in the request structure.

23. The security system according to claim 22, wherein during partial verification of the request structure by the processor using the secure guest instance, the processor is further enabled to: - verify the encrypted link between the user-specific data and the user data in the request structure, and - verify the encrypted link between the user data in the request structure and the data outside the user data field in the request structure.

24. The security system according to claim 22, wherein the user-specific data includes a key.

25. A computer program product for securely modifying the metadata of a secure guest instance using a trusted firmware that maintains the metadata of the secure guest instance personalized by initialization code, wherein the secure guest instance is derived from a general boot image, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems - start the secure guest instance using a hypervisor based on the general boot image, - use the secure guest instance to receive user-specific data, - use the secure guest instance to personalize the secure guest instance using the user-specific data, - use the secure guest instance to receive a request structure for modifying the metadata of the secure guest instance, - use the secure guest instance to partially verify the request structure using the user-specific data and, upon successful verification - Pass the request structure to the trusted firmware for modifying the metadata of the secure guest instance, - Use the trusted firmware to verify the request structure, and upon success - Modify the metadata specified by the request structure.

Images