Updating the secure guest metadata for a specific guest instance

Abstract

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

Description

[Technical Field]

[0001] The present invention relates generally 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 personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image. The present invention further relates to an associated security system and computer program product for securely modifying metadata of a secure guest instance. [Background technology]

[0002] The security of data and communication channels remains one of the top priorities for corporate IT (information technology) management. This is necessary not only due to government regulations (e.g., GDPR, EU General Data Protection Regulation), but also due to the loss of trust that companies may have if they do not consistently and reliably protect customer data, which could prevent lost sales and profits if customer data records are compromised. Additionally, depending on the country where the data is breached, fines may be required. It turns out that data protection and providing a secure computing platform are not just software challenges; 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-class computing environments, such as those used in the financial, insurance, or government industries, it is essential from a technical perspective to be able to demonstrate that data breaches can be prevented with a very high probability. This may require several additional high-tech components and supporting processes. However, the associated success in terms of data security is well worth the additional effort.

[0003] These considerations are also applicable to trusted and / or confidential computing environments in which the hypervisor or associated software management and configuration programs have substantially no access to secrets, such as cryptographic keys, used by virtual machines (also denoted guests) or software containers running on or within the hypervisor. Nevertheless, even in such computing environments, violations of basic security rules, such as the exposure of private keys or their use for secure guest images through the hypervisor, can still occur. This may also be possible in environments in which hardware security modules (HSMs) are used for significant periods of time.

[0004] Several disclosures already exist that fit the context of a computer-implemented method for personalizing a secure guest instance from a generic boot image using trusted firmware that maintains metadata for the secure guest instance. US Patent Application Publication No. 2020 / 0 076 607 A1 describes a method in which secrets are securely maintained on a virtual computer system by configuring a specialized virtual machine to manage and maintain sequents on behalf of applications. When an application requests access to a secret, the control domain, in combination with the specialized virtual machine, validates that the application is authorized to make the request and that the application has not been compromised before making the request.

[0005] Some ideas related to secure computing already exist, and US Patent Application Publication No. 2020 / 0 076 607 A1 describes a method in which secrets are securely maintained on a virtual computer system by configuring a specialized virtual machine to manage and maintain sequents on behalf of applications. When an application requests access to a secret, the control domain, in combination with the specialized virtual machine, verifies that the application is authorized to make the request and that the application has not been compromised before making the request.

[0006] Additionally, US Patent Publication No. 2020 / 0 159 940 A1 describes a method for sharing secret data among multiple containers, where in response to an initial boot process of an operating system instance of a container, a unique operating system identifier is generated for the operating system instance. A grant authority stores the unique operating system identifier in a reserved area of ​​a secure storage device. Furthermore, in response to a request from the operating system instance to access the secret data and the secure storage device, the grant authority determines whether the unique operating system identifier is stored in the secure storage device.

[0007] A problem in such confidential computing environments can be identified in the context of a secure guest image to be executed on a hypervisor. For example, a user who has gained ownership of a secure guest instance launched using a generic secure guest image provided by a software vendor wishes to modify the secure guest instance's metadata, where the metadata is accessible only by trusted firmware and is associated with the specific secure guest instance owned by the user. In such a situation, it must not be possible to steal data containing secrets and use the stolen data to add secrets to the attacker's secure guest instance; it must not be possible for the attacker to access data containing secrets known to the attacker that can be added to the vulnerable secure guest's metadata. Technologies such as openCryptoki or CCA (Common Cryptographic Architecture) have not yet been able to elegantly meet this requirement.

[0008] Therefore, it may be necessary to provide a secure method between the virtual machine running on the hypervisor and the trusted firmware so 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 may be provided for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image. The method may include launching a secure guest instance using a hypervisor based on the generic boot image, receiving user-specific data from the secure guest instance, and personalizing the secure guest instance using the user-specific data.

[0010] Further, the method may include a step of the secure guest instance receiving a request structure for modifying the metadata of the secure guest instance, the secure guest instance partially verifying the request structure using the user-specific data, and, if verification is successful, i.e., particularly if verification is partial, passing the request structure for modifying the metadata of the secure guest instance to the trusted firmware, the trusted firmware verifying the request structure, and, if successful, modifying the metadata as specified by the request structure.

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

[0012] Further, the processor may also be capable of using the secure guest instance structure to receive a request to modify the metadata of the secure guest instance, using the secure guest instance to partially validate the request structure using the user-specific data, and, particularly if the partial validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance.

[0013] Finally, the processor may also be able to use the trusted firmware to validate the request structure and, if successful, modify the metadata as specified by the request structure.

[0014] A proposed computer-implemented method for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image, may provide multiple advantages, technical effects, contributions, and / or improvements.

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

[0016] As a result, it may still be possible to modify the metadata associated with a particular secure guest instance, albeit only through that particular secure guest instance, however, after the freeze request, no one, including the particular secure guest instance, can modify the metadata of the particular secure guest instance.

[0017] This may then allow the secure guest instance startup process to be divided into two parts: (i) a first part in which metadata is modified and access to the secure guest instance is very restricted, and (ii) a second part in which metadata may be fixed but more general access to the secure guest instance may be allowed, so that attacks via more general access paths cannot modify any metadata.

[0018] This may increase the operational security of sensitive computing environments even if the virtual machine or hypervisor that provides the operating infrastructure for the secure guest instance can be corrupted. The same may apply to the communication channel between the secure guest instance and the associated metadata area of ​​the trusted firmware. If this communication channel can be compromised, it is architecturally impossible to change this metadata itself from or to another secure guest instance.

[0019] In addition, the proposed method may make it possible to ensure that the metadata of a secure guest instance can only be modified by the owner of the data used to gain ownership of the secure guest instance by requiring a cryptographic linkage between the request structure and the user data, which may in turn require the creator of the request structure and the creator of the data used to gain ownership of the secure guest instance to share a secret.

[0020] Below, additional embodiments of the inventive concepts applicable to methods and systems are described.

[0021] (2) According to an advantageous embodiment of the method, following passing one or more request structures to the trusted firmware, the secure guest instance may pass or submit a metadata freeze request, i.e., a request to freeze the metadata, to the trusted firmware, which may then reject all subsequent requests from the secure guest instance to modify its metadata. Now, any unauthorized changes to the metadata are completely unacceptable. Thus, no other virtual machine or secure guest instance can compromise the metadata of the secure guest image that initiated the initial metadata change for its own use.

[0022] (3) According to another advantageous embodiment, the method may also comprise a step of allowing general access to the secure guest instance only after the secure guest instance has passed the metadata freeze request to the trusted firmware. As a result, in particular, input / output access, for example via the network, cannot be performed before sending / receiving the freeze request. The technical result is that any unauthorized metadata modification by a user or a virtual machine, for example a hacker controlling these virtual machines, is not possible. Even if an attacker is able to traverse all secure guest instances beyond the barrier of general input / output channels, for example via the network, and even if the attacker is able to manipulate the partial integrity test program used by the request structure, it is no longer technically possible to perform such an attack.

[0023] According to a preferred embodiment of the method, launching the secure guest instance may also include the hypervisor passing the generic boot image and the protected metadata to the trusted firmware, and then the trusted firmware launching the secure guest image based on the metadata, which may be considered equivalent to building or creating the secure guest instance.

[0024] According to useful embodiments of the method, each request structure may be integrity protected, and the request structure may be fully (i.e., completely) verifiable only by trusted firmware, i.e., in the sense of the entire request structure, not just a portion. Other components may also be able to partially verify the request structure, in the sense that, for example, a guest instance may verify only a portion of the request structure. In particular, integrity protection may ensure that substitutions of user data fields within the request structure are detected by trusted firmware.

[0025] According to an advanced embodiment of the method, the request structure may include image measurements, and the method may comprise the trusted firmware rejecting the passed request structure if measurements of the boot image of the secure guest instance do not match the image measurements. In this regard, the image measurements may be any string or number sequence, or a mixture thereof, or even any digital bit string. Thus, the request structure may be used only with secure guest instances launched from a particular secure guest image that determines the personalization and partial verification procedures available to the secure guest instance.

[0026] According to an interesting embodiment of the method, the request structure may contain encrypted data that may only be decryptable by the trusted firmware. Technically, it may become very difficult, if not impossible, to attack the transmission of secrets in the encrypted part of the request structure, i.e., the act of passing it from the secure guest instance to the trusted firmware. Also, the hypervisor is excluded from learning all the contents of the request structure, even if it is architecturally located between the secure guest instance and the trusted firmware.

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

[0028] According to a further optional embodiment of the method, the request structure includes a cleartext user data field that is not interpreted by the trusted firmware, while still being subject to an integrity check of the request structure performed by the trusted firmware. Such a cleartext user data field can 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 verifying that the entity providing the data on which the secure guest instance is to be personalized and the author of the request structure share a common secret. Depending on the trust model used, this means that they trust each other or that they 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 cryptographically linked to user-specific data. Both may be the same, or the user data may be a hash value, message authentication code, or signature of the user-specific data. In this embodiment, the following feature may also be useful: the integrity tag, e.g., a digital signature, may cryptographically link the user data with data on the request structure outside the user data field. Thus, the integrity tag may be used as a signature for all fields of the request structure except the integrity tag. This may be an additional security feature, for example, for a request structure during migration from a secure guest instance to trusted firmware.

[0030] According to an enhanced embodiment of the method, the step of the secure guest instance partially verifying the request structure may include verifying a cryptographic link between the user-specific data and the user data in the request structure. This may be performed, for example, by proving that the user data is a hash value of the user-specific data. This embodiment may also include verifying a cryptographic link between the user data in the request structure and data in the request structure outside the user data field. This may be performed by proving that the integrity tag in the user data field is a signature of all fields of the request structure except for 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, a digital link exists between the user-specific data and the request structure itself. As a result, if such a link cannot be proven, the request structure should not be used with the user-specific data, which may further improve the security of the technical concept and security architecture proposed herein.

[0031] According to a further embodiment of the method, the user-specific data may include a key, which may be used in the context of trusted firmware and / or a secure guest instance. For example, the public key used may be used to verify a digital signature. This may make it possible to verify the cryptographic link between the user data and the data in the request structure outside the user data field. For this, the matching private key belonging to the signing key must belong to the creator of the user-specific data and the request structure. Using such a procedure, the secure guest instance may prove that the user-specific data and the request structure originate from the same sender or generator by verifying the integrity tag in the user data field.

[0032] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium may be any apparatus that may include means for storing, communicating, propagating or transporting a program for use by or in connection with an instruction execution system, apparatus, or device. [Brief explanation of the drawings]

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

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

[0035] Preferred embodiments of the present invention will now be described, by way of example only, and with reference to the following drawings, in which: [Figure 1] 1 illustrates a flowchart of one embodiment of a computer-implemented method of the present invention for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image. [Figure 2]1 shows a block diagram of constituents of a potential security attack scenario. [Figure 3] 1 shows a block diagram of one embodiment including instrumental components for the concepts proposed herein. [Figure 4] 1 illustrates an embodiment of an add-secret request structure according to one embodiment. [Figure 5] This shows a flowchart of a series of activities that more closely resembles an implementation of the concepts proposed here. [Figure 6] A block diagram of one embodiment of a security system of the present invention for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image, is shown. [Figure 7] 7 illustrates an embodiment of a computing system including a security system according to FIG. 6. DETAILED DESCRIPTION OF THE INVENTION

[0036] In the context of this description, the following technical phrases, terms and / or expressions may be used:

[0037] The term "trusted computing environment" may refer to a computing environment in which a hypervisor on any system management software having a user interface component does not have access to any cleartext content or other state of a virtual machine.

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

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

[0040] The term "initialization code" may refer to any string of digital bits, such as a secret key, that can transform a generic boot instance into a personalized, unique version that can be used as a bit string or string for initialization of a secure guest image.

[0041] The term "generic boot image" may refer to an image of a virtual machine or an executable software container (e.g., in the sense of a Docker container) that may be provided by a party that does not use the boot image itself. For example, a development team within an enterprise or software house may provide a boot image for general use, e.g., after download from a software repository. That is, each user may download the same generic boot image and use it to launch generic secure guests that may be personalized along the way.

[0042] The term "trusted firmware" (trusted FW or TFW) may refer to a component that is deeply embedded in the hardware of a computing (mainframe) system and is inaccessible by any other user-controlled software. Trusted firmware may have a predefined, highly secure application programming interface to protect the functionality of the trusted firmware in a broad sense. Trusted FW should not be considered a service component, but rather a deeply integrated component of the computer system. The communication channel to and from trusted firmware is usually cryptographically protected.

[0043] The term "metadata" may refer in its classical sense to information about data, and here in particular to data required to start a virtual machine. In a confidential computing environment, such information may be used by trusted firmware to start a secure virtual machine and may include, for example, integrity measures of the secure guest's image or keys needed to decrypt the secure guest's image. These metadata may include, for example, required resources, required interfaces, required performance, and possibly also which security measures are appropriate. The extension of the metadata to be used by trusted firmware, for example in terms of required control information, but more specifically in terms of secret and secret name pairs, represents one of the rationales of the proposed concept.

[0044] The term "hypervisor" may refer to 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 run in parallel without any risk of cross-referencing. An error in one virtual machine cannot cause any harm to another virtual machine. Each virtual machine may own a defined address space.

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

[0046] The term "modify metadata" may indicate that new metadata may be added to existing one for a particular secure guest image, or that existing metadata may be modified. Each request may include instructions on how to modify the metadata. This may also be valid for deleting metadata or changing existing metadata in the trusted firmware. It may also be noted that the metadata addition request structure or metadata change request structure may differ from each other in content.

[0047] The term "metadata freeze" may indicate that no changes to the metadata are technically possible after a relevant metadata freeze request from the secure guest instance to the trusted firmware of the computer system. Advantageously, such a metadata freeze request may be performed before the secure guest instance can be opened to any other general I / O.

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

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

[0050] The term "encrypted data" may refer to data that is not available in plain text but has been modified using a predefined key. Encrypted data may become readable in plain text again after a decryption process.

[0051] The term "cryptographically linked" may indicate that two pieces of data are similar and can be proven to be similar by a cryptographic link. Means for establishing such a cryptographic link may 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 along with the two pieces of data.

[0052] A detailed description of the figures is presented below. All indications in the figures are schematic. First, a block diagram of one embodiment of the inventive computer-implemented method for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image, is presented. Thereafter, further embodiments are described, as well as embodiments of an associated security system for securely modifying metadata of a secure guest instance.

[0053] 1 shows a 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, where the secure guest instance originates from a generic boot image. The complete method is supported using trusted firmware that maintains the metadata of the secure guest instance. The method is also intended to be part of a trusted computing environment as defined above.

[0054] The method 100 comprises step 102 of launching a secure guest instance using a hypervisor based on a generic boot image, and step 104 of the secure guest instance receiving user-specific data, which can be used for the next step, the next element of the method 100, step 106 of the secure guest instance personalizing the secure guest instance using the user-specific data. Thus, the secure guest instance personalizes itself.

[0055] Method 100 further comprises receiving 108, by the secure guest instance, a request structure for modifying the metadata of the secure guest instance. The request structure can be received from anywhere, for example, read from a file, received over a network connection, or similar, so no particular source of the request structure needs to be provided.

[0056] Additionally, the method 100 comprises a step 110 in which the secure guest instance partially verifies the request structure, in particular in the sense that the complete request structure does not need to be verified since the user data fields belong to the remainder of the request. For that purpose, user-specific data is used. The method 100 comprises a step 112 in which, if the partial verification is successful, the secure guest instance passes the request structure to the trusted firmware for modifying the metadata of the secure guest instance.

[0057] Finally, the method 100 comprises a step 114 in which the trusted firmware verifies the complete request structure in the sense of an integrity check immediately upon receipt. If the verification is successful, the method 100 comprises a step 116 in which the metadata is modified as specified by the request structure.

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

[0059] 2 shows a block diagram 200 of components of a potential security attack scenario. A computer system 202 may include a unified trusted firmware 204 running a hypervisor 210 that provides an operating infrastructure for secure virtual guest-1 212 and other secure virtual guest instances, such as secure virtual guest-2 218. Metadata (MD) 206 for secure guest-1 212 and metadata 208 for secure guest-2 218 are also shown.

[0060] These metadata can be modified ("allowed" 216) according to the secure requirement structure, for example, in the sense of "add," "change," or "delete." In the case of secure virtual guest-1 212, this is the secure requirement structure 214.

[0061] However, if secure virtual guest-2 218 wishes to use secure request structure 214 to attempt to modify its own metadata 208 in trusted firmware 208, this should not be allowed, as illustrated by access threat 220.

[0062] Equally, it should not be possible for secure virtual guest-1 212 to modify the metadata 206 of secure guest-1 212 using another request structure 226 secured by another key. This is also shown as not allowed 222.

[0063] FIG. 3 shows a block diagram 300 of one embodiment including the instrumental components of the concepts proposed herein. As in FIG. 2, the computer system 202, trusted firmware 204, and metadata 206 of the secure guest 212 (running on the hypervisor 210) are shown. Also shown is a generic boot image 314 used to launch 316 the secure guest instance 212. Additionally, shown is a request submission code 302 and a secure secret add request structure 304 containing user data measurements 306, a new secret to be added to the secure guest metadata 206, and user-specific data 310. The request submission code can be used to submit request structures to modify metadata (including the secret add request structure) as well as requests to freeze the metadata. Additional details regarding the secret add request structure are discussed in the context of FIG. 4.

[0064] 4 shows an embodiment of a secret addition request structure 400 according to an embodiment where the trusted firmware's metadata (see FIG. 3) needs to be changed. These initial metadata are provided as protected metadata. The request structure 400 itself contains multiple elements: a user data field 402 containing the user data 310 as well as an integrity tag 404; image measurements 306; an ephemeral public customer key 406; and key slot storage 408 containing one key for each host system.

[0065] Each one of these key slots contains a hash value of a public host key 418 and a request protection key (RPK) 416, encrypted using a public host key 418 and a private host key (not shown). The private host key is securely stored in the trusted firmware and is accessible only by the trusted firmware. A region 412 containing data about the metadata update 308 (e.g., the new secret) is encrypted with the protection request key (RPK) 416. Additionally, the secret addition request structure 400 includes an integrity tag 410, which is used for integrity checking of the complete request structure and is additionally indicated by reference numeral 414. Here, the RPK 412 is also used as a protection mechanism, for example, as an HMAC or AES-GCM key.

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

[0067] 5 shows a flowchart 500 of a series of activities that more closely resembles an implementation of the concepts proposed herein. First, a user of a secure guest instance provides some user-specific data that can be used to personalize a generic secure guest. In addition, the user of the secure guest instance may also build a secrets addition request structure 502. Next, the user data and secrets addition request structure are loaded 504 into a running instance of a generic secure guest image.

[0068] The secure guest instance then uses the user data to personalize the secure guest instance for use only by the user 506. This represents the self-personalization described above. As a next step, the secure guest instance verifies the user data in the request structure against the loaded user-specific data and partially validates the request structure based on the keying material contained in the user-specific data and the integrity tag in the user data field of the request structure 508. If the validation is successful, the request structure is passed to trusted firmware 510.

[0069] Additionally, the trusted firmware checks the integrity of the request structure and, if successful, unpacks the request structure and modifies 512 the metadata of the associated secure guest instance as defined by the request structure.

[0070] Finally, the secure guest instance issues a request to the trusted firmware (FW) to freeze the metadata of the secure guest instance before opening any general I / O channels 514. This terminates the instantiation of the secure guest instance.

[0071] FIG. 6 illustrates a block diagram of one embodiment of a security system of the present invention for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, where the secure guest instance originated from a generic boot image.

[0072] The security system comprises 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 launch, in particular via a launch module 606, a secure guest instance based on a generic boot image and using a hypervisor, e.g., a hypervisor unit 608. The processor 602 is also enabled to receive user-specific data using a receiver 610 of the secure guest instance and to personalize the secure guest instance using the user-specific data, e.g., a personalizer module 612 of the secure guest instance.

[0073] The processor 602 of the security system 600 then receives, for example using the secure guest instance receiver 610, a request structure for modifying the metadata of the secure guest instance, and is able to partially validate the request structure using the user-specific data, for example using the secure guest instance verifier 614.

[0074] If the verification is successful, the processor 602 of the secure system 600 is also able to pass a request structure to the trusted firmware 616 (see 204 in Figures 2 and 3) to modify the metadata of the secure guest instance.

[0075] Additionally, processor 602 may verify the request structure, for example, using a trusted firmware module. If the verification is successful, processor 602 may modify the metadata as specified by the request structure, for example, using modification 618.

[0076] It should also be mentioned that all functional units, modules, and functional blocks, in particular, the processor 602, memory 604, boot module 606, hypervisor unit 608, receiver 610, personalizer unit 612, verifier 614, trusted firmware module 616 (optionally including one or more processors), and modification unit 618, may be communicatively coupled to each other for signal or message exchange in a selected 1:1 manner. Alternatively, the functional units, modules, and functional blocks may be linked with a system internal bus system 620 for selective signal or message exchange.

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

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

[0079] FIG. 7 illustrates a computing environment 700 that includes an example of an environment for execution of at least a portion of the computer code involved in executing a method of the present invention, such as a computer-implemented method for securely modifying the metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance 750, where the secure guest instance originates from a generic boot image.

[0080] In addition to block 750, computing environment 700 includes, for example, a computer 701, a wide area network (WAN) 702, an end user device (EUD) 703, a remote server 704, a public cloud 705, and a private cloud 706. In this embodiment, computer 701 includes a set of processors 710 (including processing circuitry 720 and cache 721), a communications fabric 711, volatile memory 712, persistent storage 713 (including an operating system 722 and the above-identified block 750), a set of peripheral devices 714 (including a set of user interface (UI) devices 723, storage 724, and a set of Internet of Things (IoT) sensors 725), and a network module 715. Remote server 704 includes a remote database 730. 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.

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

[0082] The processor set 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, e.g., multiple tailored integrated circuit chips. The processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. The cache 721 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on the processor set 710. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, the processor set 710 may be designed to operate with qubits and perform quantum computing.

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

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

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

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

[0087] The peripheral device set 714 includes a set of peripheral devices of the computer 701. Data communication connections between the peripheral devices and other components of the computer 701 can be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertion-type connections (e.g., a secure digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 723 can 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 724 can be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 724 can be persistent and / or volatile. In some embodiments, storage 724 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 701 is required to have a large amount of storage (e.g., where computer 701 stores and manages large databases locally), this storage may then be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 725 is made up of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

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

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

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

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

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

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

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

[0095] It should also be mentioned that the security system (600, see FIG. 6) for securely modifying the metadata of a secure guest instance personalized by initialization code may be an operating subsystem of the computer 701 and may be attached to the computer's internal bus system.

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

[0097] In the following claims, the corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements are intended to include any structure, material, or acts for performing the function in combination with the elements of other claims as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described to best explain the principles and practical application of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications as suitable for the particular uses contemplated.

[0098] Briefly, the concepts of the present invention can be summarized by the following items: [Item 1] 1. A computer-implemented method for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the method comprising: booting a secure guest instance using a hypervisor based on the generic boot image; receiving user specific data from the secure guest instance; the secure guest instance personalizing the secure guest instance using the user-specific data; receiving, by the secure guest instance, a request structure to modify the metadata of the secure guest instance; the secure guest instance partially validating the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; the trusted firmware verifying the requested structure, and if successful, modifying the metadata as specified by the request structure. A method comprising: [Item 2] Following the step of passing one or more request structures to the trusted firmware, the secure guest instance passing a metadata freeze request to the trusted firmware, whereupon the trusted firmware denies all subsequent requests by the secure guest instance to modify its metadata. The method according to item 1. [Item 3] allowing general access to the secure guest instance only after the secure guest instance passes the metadata freeze request to the trusted firmware. Item 3. The method according to item 2, further comprising: [Item 4] The step of launching the secure guest instance comprises: the hypervisor passing a generic boot image and protected metadata to the trusted firmware; and the trusted firmware launching the secure guest image based on the metadata. 3. The method of any one of the preceding items, comprising: [Item 5] 10. The method of any one of the preceding items, wherein each request structure is integrity protected and the request structure is fully verifiable only by the trusted firmware. [Item 6] The requested structure includes image measurements, and the method further comprises: the trusted firmware rejecting the passed request structure if the measurements of the boot image of the secure guest instance do not match the image measurements. 10. The method of any one of the preceding items, comprising: [Item 7] 10. The method of claim 1, wherein the request structure includes encrypted data that is only decryptable by the trusted firmware. [Item 8] Item 8. The method of item 7, wherein the encrypted data in the request structure includes a secret to be added to the metadata of the secure guest instance. [Item 9] 10. The method of claim 9, wherein the request structure includes a plaintext user data field that is not interpreted by the trusted firmware, while still being subject to an integrity check of the request structure performed by the trusted firmware. [Item 10] 10. The method of claim 9, wherein the user data field in the request structure includes user data and an integrity tag, where the user data is cryptographically linked to the user specific data, and the integrity tag cryptographically links the user data to the data in the request structure outside the user data field. [Item 11] The step of the secure guest instance partially verifying the request structure includes: verifying a cryptographic link between user specific data and the user data in the request structure; and verifying the cryptographic link between user data in the request structure and the data in the request structure outside the user data field. Item 11. The method according to Item 10, comprising: [Item 12] Item 11. The method of item 10, wherein the user-specific data includes a key. [Item 13] 1. A security system for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the security system comprising: a processor; and a memory operatively coupled to the processor, wherein the memory, when executed by the processor, causes the processor to: booting a secure guest instance using a hypervisor based on the generic boot image; receiving user-specific data using the secure guest instance; using the secure guest instance to personalize the secure guest instance with the user-specific data; receiving, using the secure guest instance, a request structure to modify the metadata of the secure guest instance; using the secure guest instance to partially validate the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; verifying the requested structure using the trusted firmware, and if successful, Modifying the metadata as specified by the request structure a security system storing program code portions that enable [Item 14] Following the step of passing one or more request structures to the trusted firmware, the processor also: The secure guest instance is used to pass a metadata freeze request to the trusted firmware, which then, under control of the processor, rejects all subsequent requests by the secure guest instance to modify its metadata. Item 14. The security system according to item 13, [Item 15] allowing general access to the secure guest instance only after the secure guest instance passes the metadata freeze request to the trusted firmware. Item 15. The security system of item 14, further comprising: [Item 16] The processor also, during the launch of the secure guest instance, using the hypervisor to pass a generic boot image and protected metadata to the trusted firmware; Booting the secure guest image based on the metadata using the trusted firmware. The security system according to any one of items 13 to 15 makes it possible to: [Item 17] 17. The security system of any one of items 13 to 16, wherein each request structure is integrity protected and the request structure is fully verifiable only by the trusted firmware. [Item 18] The request structure includes image measurements, and the processor also: If the measurements of the boot image of the secure guest instance do not match the image measurements, then reject the passed request structure using the trusted firmware. The security system according to any one of items 13 to 17 makes it possible to: [Item 19] 19. The security system according to any one of items 13 to 18, wherein the request structure includes encrypted data that can only be decrypted by the trusted firmware. [Item 20] 20. The security system of claim 19, wherein the encrypted data of the request structure includes a secret to be added to the metadata of the secure guest instance. [Item 21] 21. The security system of any one of items 13 to 20, wherein the request structure includes a plaintext user data field that is not interpreted by the trusted firmware, while still being subject to an integrity check of the request structure performed by the trusted firmware. [Item 22] 22. The security system of claim 21, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is cryptographically linked to the user specific data, and the integrity tag cryptographically links the user data to the data in the request structure outside the user data field. [Item 23] While the processor is partially validating the request structure using the secure guest instance, the processor also: verifying a cryptographic link between user specific data and said user data in said request structure; verifying the cryptographic link between the user data in the request structure and the data in the request structure outside the user data field; Item 23. The security system according to item 22, [Item 24] Item 23. The security system of item 22, wherein the user-specific data includes a key. [Item 25] 1. A computer program product for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware maintaining the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions including: booting a secure guest instance using a hypervisor based on the generic boot image; using the secure guest instance to receive user-specific data; using the secure guest instance to personalize the secure guest instance with the user-specific data; receiving, using the secure guest instance, a request structure to modify the metadata of the secure guest instance; using the secure guest instance to partially validate the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; causing the trusted firmware to verify the requested structure, and if successful, Modifying the metadata as specified by the request structure a computer program product executable by said one or more computing systems or controllers to:

Claims

1. 1. A computer-implemented method for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the method comprising: booting a secure guest instance using a hypervisor based on the generic boot image; receiving user specific data from the secure guest instance; the secure guest instance personalizing the secure guest instance using the user-specific data; receiving, by the secure guest instance, a request structure to modify the metadata of the secure guest instance; the secure guest instance partially validating the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; the trusted firmware verifying the requested structure, and if successful, modifying the metadata as specified by the request structure. A method comprising:

2. Following the step of passing one or more request structures to the trusted firmware, the secure guest instance passing a metadata freeze request to the trusted firmware, whereupon the trusted firmware denies all subsequent requests by the secure guest instance to modify its metadata. The method of claim 1 , comprising:

3. allowing general access to the secure guest instance only after the secure guest instance passes the metadata freeze request to the trusted firmware. The method of claim 2 , further comprising:

4. The step of launching the secure guest instance comprises: the hypervisor passing a generic boot image and protected metadata to the trusted firmware; and the trusted firmware launching the secure guest image based on the metadata. The method according to any one of claims 1 to 3, comprising:

5. The method of any one of claims 1 to 4, wherein each request structure is integrity protected, such that said request structure is fully verifiable only by said trusted firmware.

6. The requested structure includes image measurements, and the method further comprises: the trusted firmware rejecting the passed request structure if the measurements of the boot image of the secure guest instance do not match the image measurements. The method of any one of claims 1 to 5, comprising:

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

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

9. 9. The method of claim 1, wherein the request structure includes a plaintext user data field that is not interpreted by the trusted firmware, while still being subject to the integrity check of the request structure performed by the trusted firmware.

10. 10. The method of claim 9, wherein the user data field in the request structure includes user data and an integrity tag, wherein the user data is cryptographically linked with the user specific data, and the integrity tag cryptographically links the user data with the data in the request structure outside the user data field.

11. The step of the secure guest instance partially verifying the request structure includes: verifying a cryptographic link between user specific data and the user data in the request structure; and verifying the cryptographic link between user data in the request structure and the data in the request structure outside the user data field.

11. The method of claim 10, comprising:

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

13. 1. A security system for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the security system comprising: a processor; and a memory operatively coupled to the processor, wherein the memory, when executed by the processor, causes the processor to: booting a secure guest instance using a hypervisor based on the generic boot image; receiving user-specific data using the secure guest instance; using the secure guest instance to personalize the secure guest instance with the user-specific data; receiving, using the secure guest instance, a request structure to modify the metadata of the secure guest instance; using the secure guest instance to partially validate the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; verifying the requested structure using the trusted firmware, and if successful, Modifying the metadata as specified by the request structure a security system storing program code portions that enable

14. Following the step of passing one or more request structures to the trusted firmware, the processor also: The secure guest instance is used to pass a metadata freeze request to the trusted firmware, which then, under control of the processor, rejects all subsequent requests by the secure guest instance to modify its metadata.

14. The security system of claim 13, wherein:

15. allowing general access to the secure guest instance only after the secure guest instance passes the metadata freeze request to the trusted firmware.

15. The security system of claim 14, further comprising:

16. The processor also, during the launch of the secure guest instance, using the hypervisor to pass a generic boot image and protected metadata to the trusted firmware; Booting the secure guest image based on the metadata using the trusted firmware. The security system according to any one of claims 13 to 15, wherein the security system is capable of:

17. A security system according to any one of claims 13 to 16, wherein each request structure is integrity protected, said request structure being fully verifiable only by said trusted firmware.

18. The request structure includes image measurements, and the processor also: If the measurements of the boot image of the secure guest instance do not match the image measurements, then reject the passed request structure using the trusted firmware. The security system according to any one of claims 13 to 17, wherein the security system is capable of:

19. A security system according to any one of claims 13 to 18, wherein the request structure includes encrypted data that is only decryptable by the trusted firmware.

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

21. 21. A security system as described in any one of claims 13 to 20, wherein the request structure includes a plaintext user data field that is not interpreted by the trusted firmware, while still being subject to the integrity check of the request structure performed by the trusted firmware.

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

23. While the processor is partially validating the request structure using the secure guest instance, the processor also: verifying a cryptographic link between user specific data and said user data in said request structure; verifying the cryptographic link between the user data in the request structure and the data in the request structure outside the user data field; 23. The security system of claim 22, wherein:

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

25. 1. A computer program product for securely modifying metadata of a secure guest instance personalized by initialization code using trusted firmware that maintains the metadata of the secure guest instance, wherein the secure guest instance originated from a generic boot image, the computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions including: booting a secure guest instance using a hypervisor based on the generic boot image; using the secure guest instance to receive user-specific data; using the secure guest instance to personalize the secure guest instance with the user-specific data; receiving, using the secure guest instance, a request structure to modify the metadata of the secure guest instance; using the secure guest instance to partially validate the request structure using the user-specific data, and if the validation is successful, passing the request structure to the trusted firmware to modify the metadata of the secure guest instance; causing the trusted firmware to verify the requested structure, and if successful, Modifying the metadata as specified by the request structure a computer program product executable by said one or more computing systems or controllers to:

Images